FHIR & Interoperability

TietAI is built on FHIR R4 as its core data standard. This page documents how TietAI uses FHIR, which resource types are supported, how other health data standards (HL7 v2, DICOM, X12, EHDS) are handled, and how to access the FHIR API directly.

---

FHIR R4 as the core data standard

FHIR (Fast Healthcare Interoperability Resources) R4 is an international standard for exchanging healthcare information electronically. In TietAI:

• Every patient record is stored as a set of FHIR R4 resources
• Data fetched from connected EHRs is normalized into FHIR R4 before being stored
• Data written back to EHRs from workflows is constructed as FHIR R4 resources
• The TietAI FHIR API exposes your organization's data using the standard FHIR REST API

This means your data is portable, standards-compliant, and can be exported, validated, or queried using any FHIR-compatible tool.

---

Supported FHIR resource types

Clinical resources

Resource	Description	Common use in TietAI
Patient	Patient demographics and identifiers	Core record; synced from EHR on every patient sync
Practitioner	Clinician demographics and credentials	Care team members; referenced in encounters and notes
Organization	Healthcare organizations and departments	Linked to Patient and Practitioner resources
Condition	Diagnoses and health problems	Pulled from EHR; shown in the Conditions tab
Observation	Lab results, vital signs, device readings	Lab values, wearable data, device monitoring
MedicationRequest	Prescribed medications	Shown in the Medications tab; ingested from EHR
AllergyIntolerance	Documented allergies and adverse reactions	Shown in the Allergies tab
Procedure	Surgical and clinical procedures	Historical procedures from EHR
Encounter	Hospital visits, outpatient appointments	Shown in the patient timeline
DiagnosticReport	Lab reports, imaging reports	Linked to Observations; includes narrative content
DocumentReference	Clinical documents (notes, discharge summaries)	Attached documents from EHR
MedicationAdministration	Recorded medication administrations	Inpatient medication tracking
ServiceRequest	Orders for tests, procedures, referrals	Order tracking from EHR
CarePlan	Longitudinal care plans	Care coordination workflows

Infrastructure resources

Resource	Use
Bundle	Container for multiple resources; used in batch writes and API responses
OperationOutcome	Error and validation responses from the FHIR API
CapabilityStatement	Describes what the FHIR server supports (queried during connector testing)
AuditEvent	FHIR-format audit log entries

---

HL7 v2 support

HL7 v2 is the legacy messaging standard used by most hospital information systems, labs, and radiology systems. TietAI handles HL7 v2 via the TietAI Connect service, which listens for inbound MLLP connections and routes messages into your workflows.

Supported message types

Message type	Name	Common source system
ADT	Admit, Discharge, Transfer	HIS / hospital systems
ORU	Observation Result (lab results)	Laboratory systems, LIS
ORM	Order Message	Order entry systems
SIU	Scheduling Information Unsolicited	Scheduling systems
MDM	Medical Document Management	Document management systems
DFT	Detailed Financial Transaction	Billing systems

When an HL7 v2 message arrives via MLLP, the HL7 to FHIR node in your workflow converts it to the appropriate FHIR R4 resources. For example, an ADT^A01 (admit) message creates or updates a FHIR Patient resource and creates a FHIR Encounter resource.

For setup instructions, see Connect Your EHR — HL7 v2 section.

---

DICOM

DICOM (Digital Imaging and Communications in Medicine) is the standard for medical imaging data — X-rays, MRIs, CT scans, ultrasounds.

TietAI supports DICOMweb (WADO-RS, STOW-RS, QIDO-RS) for accessing imaging data from PACS systems.

Supported operations:

• Query (QIDO-RS) — Search for imaging studies by patient, date, modality, or study instance UID
• Retrieve (WADO-RS) — Download DICOM instances from a PACS
• Store (STOW-RS) — Upload DICOM instances to a connected PACS

Use the DICOM Query, DICOM Retrieve, and DICOM Store nodes in Hydra Builder workflows. Imaging studies can be linked to patient FHIR records as ImagingStudy resources.

Contact TietAI support to configure a DICOMweb connector for your PACS or VNA.

---

X12 EDI

X12 is the American standard for administrative and financial healthcare transactions — insurance eligibility checks, claims submission, prior authorization, and remittance.

TietAI's Connect service handles X12 transaction processing.

Supported transaction types

Transaction set	Name	Use
270 / 271	Eligibility Inquiry / Response	Check patient insurance coverage
276 / 277	Claim Status Inquiry / Response	Track submitted claim status
278	Prior Authorization Request	Request prior auth from payer
835	Electronic Remittance Advice	Process payment explanations
837P / 837I	Professional / Institutional Claim	Submit claims to payers

X12 nodes in Hydra Builder allow workflows to check eligibility before scheduling, submit claims after encounters, or process remittance files automatically.

---

FHIR Bulk Data Access

TietAI's FHIR server implements the FHIR Bulk Data Access IG for large-scale data exports. This is useful when you need to extract a full dataset — for analytics, data warehousing, population health, or regulatory reporting.

Export scopes

Scope	Endpoint	Description
System-level	GET /$export	Exports all resources across the organization
Patient-level	GET /Patient/$export	Exports all patient-compartment resources

Supported parameters

Parameter	Description
_type	Comma-separated list of resource types to include in the export (e.g., _type=Patient,Condition,Observation)
_since	RFC 3339 timestamp — only resources modified after this date are included (e.g., _since=2026-01-01T00:00:00Z)

Supported resource types for export

Patient, Observation, Condition, Procedure, DiagnosticReport, MedicationRequest, AllergyIntolerance, Encounter, Appointment, DocumentReference, Coverage, Claim, ExplanationOfBenefit.

Output format

All exported data is delivered in NDJSON (Newline Delimited JSON) format — one FHIR resource per line.

Async workflow

Bulk exports are asynchronous. The workflow is:

1. Kick off the export — POST /$export (or /Patient/$export) with the desired parameters. The server returns a 202 Accepted response with a Content-Location header pointing to the status endpoint.
2. Poll for completion — GET /bulkdata/status/{processId}. Returns 202 while in progress and 200 with a manifest of downloadable files when complete.
3. Download the files — GET /bulkdata/download/{exportId}/{filename} for each file listed in the manifest.

All exports are scoped to the calling organization via the X-Organization-ID header.

---

IHE Profiles

TietAI supports IHE (Integrating the Healthcare Enterprise) profiles for standardized document sharing and patient demographics.

IHE MHD — Mobile access to Health Documents

MHD enables standardized document sharing workflows — submit, find, and retrieve clinical documents using FHIR DocumentReference and Binary resources. This is useful for cross-organizational document exchange, such as sharing discharge summaries or referral letters between facilities.

IHE PDQm — Patient Demographics Query for Mobile

PDQm provides a standardized FHIR-based patient demographics search. This is useful for master patient index (MPI) lookups and cross-referencing patients across systems — for example, finding a patient in another organization's registry before requesting their records.

Both profiles are available on the standard FHIR endpoint and validated against IHE conformance rules.

---

EHDS — European Health Data Space

The European Health Data Space (EHDS) regulation mandates that health data be accessible across EU member states in standardized formats for both primary use (patient care) and secondary use (research, policy).

TietAI's EHDS support includes:

• FHIR R4 compliance for all primary patient data (a core EHDS requirement)
• IPS (International Patient Summary) generation — TietAI can produce an IPS bundle from any patient record, which is the cross-border format required by EHDS
• Audit logging in FHIR AuditEvent format — Required for EHDS data access logging
• Consent management — Workflow nodes for capturing and validating patient consent in FHIR Consent resources

note

EHDS compliance is a shared responsibility. TietAI provides the technical infrastructure, but your organization must configure appropriate consent workflows and data governance policies. Consult your DPO (Data Protection Officer) for guidance.

---

Accessing the FHIR API directly

Your organization's FHIR store is accessible via a standard FHIR R4 REST API.

Base URL format:

https://api.tiet.ai/fhir/r4/<your-org-id>/

Your org ID is visible in the URL when you are logged in to TietAI, or under Settings → Organization → API Access.

Authentication: All FHIR API requests require a bearer token. Generate an API key under Settings → Security → API Keys.

Include the key in request headers:

Authorization: Bearer <your-api-key>
X-Organization-ID: <your-org-id>

All requests require the X-Organization-ID header for multi-tenant isolation. This ensures your queries only return data belonging to your organization.

Pagination and advanced queries: Results support the _count parameter to control page size, plus _sort, _include, and _revinclude for advanced queries. For example, ?_count=50&_sort=-date returns the 50 most recent results.

Example: Fetch all patients

GET https://api.tiet.ai/fhir/r4/<org-id>/Patient
Authorization: Bearer <your-api-key>

Example: Fetch a specific patient by ID

GET https://api.tiet.ai/fhir/r4/<org-id>/Patient/12345
Authorization: Bearer <your-api-key>

Example: Search patients by name

GET https://api.tiet.ai/fhir/r4/<org-id>/Patient?name=Smith
Authorization: Bearer <your-api-key>

The API returns standard FHIR JSON. For a full list of supported operations, request the capability statement:

GET https://api.tiet.ai/fhir/r4/<org-id>/metadata

For API key management and scope configuration, see Administration — API access management.