Skip to main content

Key Concepts

This page explains the core building blocks of TietAI. Understanding these concepts will help you navigate the platform, talk to your team about what you are building, and make better decisions when designing workflows.


Workflows / Pipelines

A workflow (also called a pipeline) is an ordered series of connected steps that process clinical data. Think of it like an assembly line in a hospital: a patient chart enters at one end, passes through a sequence of processing stations — each doing a specific job — and exits as an enriched result, a notification, or an updated record.

Workflows are built visually in Hydra Builder using a drag-and-drop canvas. You do not write code; you place nodes on the canvas and draw connections between them. The Hydra Copilot AI assistant can generate pipelines from plain-language descriptions and automatically fix execution errors.

When to use a workflow:

  • Pulling patient data from an EHR on a schedule
  • Running an AI model over clinical notes and writing results back to a FHIR server
  • Receiving an HL7 ADT message, transforming it, and routing it to the right system
  • Generating a weekly executive report from aggregated patient outcomes

Workflows have a Draft state while you are building them and transition through Running, Paused, Completed, and Failed states during execution.


Nodes

A node is a single processing unit inside a workflow. Each node has:

  • Input ports (left side) — where data enters the node
  • Output ports (right side) — where the node's result leaves and flows to the next step
  • Configuration — settings specific to that node type, opened by double-clicking

Nodes are grouped into categories in the palette:

CategoryWhat these nodes do
HealthcareFetch and write EHR data (Epic, Cerner, FHIR)
AI / MLRun language models, classifiers, summarizers, reasoning agents
DataTransform, filter, merge, validate, and route data
OutputWrite results — reports, notifications, FHIR resources, API calls
ControlBranch logic, loops, parallel execution, scheduling

Port types

Ports are typed — a node's output type must be compatible with the next node's expected input type. You cannot connect incompatible ports; the canvas will prevent the connection. Common port types:

Port typeWhat it carries
textPlain text strings — prompts, notes, summaries
jsonArbitrary structured data
fhir-bundleA FHIR Bundle containing multiple resources
fhir-resourceA single FHIR resource (Patient, Observation, etc.)
trigger-eventA signal that starts a downstream node, carrying event metadata
hl7-messageA raw HL7 v2 message

Connectors

A connector is a configured link between TietAI and an external system — your Epic instance, a Cerner FHIR endpoint, an HL7 MLLP server, or a third-party FHIR server.

Key facts about connectors:

  • Organization-scoped — Once an admin configures a connector, every workflow in the organization can use it. You do not reconfigure credentials in each workflow.
  • Tested at configuration time — When you save a connector, TietAI performs a live connection test. A green checkmark means the credentials and endpoint are valid.
  • Referenced by name inside nodes — When configuring an Epic Patient List node, you select the connector by name (e.g., "Epic Production" or "Cerner Test"). The credentials never appear in the workflow itself.

Examples of connector types: Epic FHIR, Cerner FHIR, athenahealth FHIR, Generic FHIR R4, HL7 MLLP listener, Allscripts.


Executions

An execution is a single run of a workflow. Every time you click Run (or a scheduled trigger fires), TietAI creates an execution record that captures:

  • Status — the overall outcome of the run
  • Per-node status — which nodes succeeded, which failed, and how long each took
  • Data snapshots — the input and output of each node (useful for debugging)
  • Logs — detailed logs for each node, including any error messages

Execution lifecycle

Loading diagram…
  • Pending — The execution has been queued and is waiting to start.
  • Running — Nodes are executing; the canvas highlights the active node in real time.
  • Completed — All nodes finished successfully.
  • Failed — One or more nodes encountered an unrecoverable error. The execution stops at the failing node.
  • Timed out — The execution exceeded the configured timeout limit (default: 30 minutes).

Failed executions are never silently swallowed — the execution panel shows exactly which node failed and why.


Organizations

TietAI is multi-tenant. Your organization is an isolated workspace that contains:

  • Your users and their role assignments
  • Your connector configurations
  • Your workflows and pipeline definitions
  • Your patient FHIR store
  • Your audit logs

Data is never shared between organizations. A clinician in Organization A cannot see the patients, workflows, or connectors of Organization B, even if both organizations use the same TietAI deployment. This isolation is enforced at the database level, not just the UI.


AI Agents

An AI agent node is a special node type that wraps a large language model (LLM) with a clinical prompt, tools, and context. Unlike a simple data transformation node, an agent can:

  • Receive clinical text and produce a structured summary
  • Use tools (such as a FHIR query or a drug database lookup) to answer a question
  • Reason over multiple inputs before producing an output
  • Run sub-agents in parallel and aggregate their results

Agent nodes are configured with a prompt (what the agent is asked to do), model parameters (temperature, max tokens), and optionally a set of tools the agent is allowed to call.

The distinction from a regular node: a standard node performs a deterministic operation (fetch these patients, transform this FHIR bundle). An agent node applies LLM-based reasoning and may call tools autonomously to complete its task.


The assembly line analogy

A workflow is like a hospital assembly line:

  1. Trigger / Input node — A patient chart arrives, an HL7 message is received, or a scheduled time fires. This is the raw material entering the line.
  2. Processing nodes — The data passes through stations: an EHR fetch node retrieves clinical history, a FHIR transform validates the data, an AI agent summarizes the findings.
  3. Output node — The finished result exits: a FHIR resource is written back to the EHR, a notification is sent to the care team, or a report is saved to the dashboard.

Each station (node) does one job well and passes its output to the next. If a station fails, the line stops and the problem is logged — you know exactly where to look.


Further reading