Health1st AI Logo
The Platform

Every healthcare format, translated — in days, not quarters.

Health1st translates HL7 v2, FHIR, C-CDA, X12 and NCPDP in both directions — with AI agents that draft the mappings, normalize the codes and validate against US Core, so your team reviews instead of hand-building. Your HL7 backlog is measured in months. Ours in days.

  • HL7 v2.x ↔ FHIR R4/R4B/R5 at the core — round-trip fidelity
  • US Core, Da Vinci & IPS conformance, with exportable reports
  • Built for CMS-0057-F: four FHIR APIs due January 1, 2027
  • Deploy in cloud, VPC or on-prem — you control the data
HL7 v2.5.1 · ADT^A01inbound
MSH|^~\&|EPIC|HOSP|H1ST|DST|202601..||ADT^A01|
PID|1||MRN12345^^^HOSP^MR||DOE^JOHN^A||
    19701225|M|||123 MAIN ST^^AUSTIN^TX
PV1|1|I|ICU^101^A|||...admit...
DG1|1|I10|E11.9^Type 2 diabetes mellitus
PIDPatient
PV1Encounter
DG1Condition
AIMapping
Agent
validate · normalize · map
FHIR R4 · Bundleoutbound
{ "resourceType": "Patient",
  "identifier": [{ "value": "MRN12345" }],
  "name": [{ "family": "Doe",
             "given": ["John","A"] }],
  "gender": "male",
  "birthDate": "1970-12-25" }

{ "resourceType": "Condition",
  "code": { "coding": [{
    "system": "…/icd-10-cm",
    "code": "E11.9" }] } }
US CoreR4.0.1validated
An inbound HL7 v2.5.1 ADT^A01 admission message is parsed segment by segment — PID maps to a FHIR Patient, PV1 to an Encounter, and the DG1 diagnosis segment (ICD-10 E11.9, Type 2 diabetes) to a FHIR Condition — by the AI Mapping Agent, validated against US Core and FHIR R4.0.1. The reverse direction (FHIR back to HL7 v2) is also supported.

In short

Health1st is an AI-native, bidirectional, multi-protocol interoperability platform. It converts healthcare data between formats — with HL7 v2 ↔ FHIR at the core, plus C-CDA, X12 EDI, NCPDP, DICOM, IHE, Direct and Bulk FHIR — where a fleet of specialized AI agents does the heavy lifting of mapping, terminology translation and validation, with human-in-the-loop review. The pipeline is simple to describe and hard to fake: ingest → AI-map → validate → deliver. It exists because the 21st Century Cures Act and CMS-0057-F push every payer, provider and HIE toward FHIR while their operational reality is still HL7 v2 — and bidirectional translation is the bridge that gap requires.
4 APIs
CMS-0057-F FHIR APIs
due Jan 1, 2027
~43% / 47%
payers / providers not started
WEDI, Oct 2025
12
AI agents in the fleet
orchestrated, human-reviewed
Days
to a first interface
not weeks of consulting
Why this exists

Must expose FHIR. Still runs HL7 v2.

That single gap — created by the Cures Act and sharpened by CMS-0057-F — is where interface teams drown. Every point-to-point interface is hand-built, brittle, and measured in weeks.

A backlog measured in months

Each new interface is a manual mapping-and-testing project. Scarce, expensive HL7 analysts become the bottleneck for every integration.

A hard 2027 deadline

CMS-0057-F forces impacted payers to stand up four FHIR APIs by January 1, 2027 — and as of October 2025, roughly 43% of payers had not started.

Incumbent engines cost a fortune

Legacy engines run from six figures to $10M+/year at mega scale, and stay consultant-heavy long after the contract is signed.

Clinical errors are unacceptable

A mis-mapped diagnosis or dose is a patient-safety event, not a bug ticket. Speed can't come at the cost of accuracy or auditability.

How it works

Ingest → AI-map → validate → deliver

One pipeline runs every transformation. AI agents draft and normalize; your team reviews; the engine validates and delivers with full audit.

  1. 1

    Ingest

    Accept any source — HL7 v2 over MLLP, FHIR REST, C-CDA XML, X12 EDI, NCPDP, flat files or a custom API. Real-time, batch or streaming, with guaranteed delivery and replay.

  2. 2

    AI-map

    The Mapping and Terminology agents draft field- and segment-level mappings, normalize codes (ICD-10, SNOMED, LOINC, RxNorm↔NDC), and explain every decision in plain English for human review.

  3. 3

    Validate

    The Validation agent checks output against US Core, Da Vinci and IPS profiles — cardinality, bindings, must-support — and produces the conformance report procurement and auditors ask for.

  4. 4

    Deliver

    The Transformation and Orchestration agents serialize, route and reliably deliver the result — a FHIR bundle, an X12 278, an NCPDP SCRIPT message — with round-trip fidelity and full audit.

HL7 v2.5.1 · ADT^A01inbound
MSH|^~\&|EPIC|HOSP|H1ST|DST|202601..||ADT^A01|
PID|1||MRN12345^^^HOSP^MR||DOE^JOHN^A||
    19701225|M|||123 MAIN ST^^AUSTIN^TX
PV1|1|I|ICU^101^A|||...admit...
DG1|1|I10|E11.9^Type 2 diabetes mellitus
PIDPatient
PV1Encounter
DG1Condition
AIMapping
Agent
validate · normalize · map
FHIR R4 · Bundleoutbound
{ "resourceType": "Patient",
  "identifier": [{ "value": "MRN12345" }],
  "name": [{ "family": "Doe",
             "given": ["John","A"] }],
  "gender": "male",
  "birthDate": "1970-12-25" }

{ "resourceType": "Condition",
  "code": { "coding": [{
    "system": "…/icd-10-cm",
    "code": "E11.9" }] } }
US CoreR4.0.1validated
An inbound HL7 v2.5.1 ADT^A01 admission message is parsed segment by segment — PID maps to a FHIR Patient, PV1 to an Encounter, and the DG1 diagnosis segment (ICD-10 E11.9, Type 2 diabetes) to a FHIR Condition — by the AI Mapping Agent, validated against US Core and FHIR R4.0.1. The reverse direction (FHIR back to HL7 v2) is also supported.

A live example: an inbound HL7 v2.5.1 ADT^A01 admission maps segment-by-segment into a validated FHIR R4 bundle — PID → Patient, PV1 → Encounter, DG1 (ICD-10 E11.9, Type 2 diabetes) → Condition — and back again.

Standards coverage

The protocol & format matrix

Bidirectional support across the clinical, payer/administrative and pharmacy domains — plus the terminology systems that make a mapping actually correct.

Standard / formatVersions & variantsDomainDirection
HL7 v2.x2.1 – 2.9 · ADT, ORM, ORU, SIU, MDM, DFT, VXUClinical / real-timeBidirectional
HL7 FHIRDSTU2, STU3, R4 (4.0.1), R4B, R5Clinical / APIBidirectional
US Core / USCDIUS Core STU 3.1.1+, USCDI data classesConformance profileProfile / validation
HL7 CDA / C-CDAR2.1 — CCD, Discharge, Referral, Progress NoteClinical documentsBidirectional
X12 EDI270/271, 276/277, 278, 834, 835, 837 P/I/D, 820, 999/TA1Payer / administrativeBidirectional (↔ Da Vinci)
NCPDP SCRIPTv2023011 (HTI-4), 10.6 — NewRx, Renewal, Change, CancelRx, RxFillPharmacy / e-RxBidirectional
NCPDP Telecom / RTPB / F&BTelecom D.0 · RTPB v13 · Formulary & BenefitPharmacy benefit / claimsBidirectional (↔ CARIN RTPBC)
DICOMMetadata, SR, DICOMwebImaging→ FHIR ImagingStudy
IHE profilesXDS.b, MHD, PIX/PDQ, XCA, ATNADocument / registry exchangeCross-community
Direct / DirectTrustS/MIME secure messagingSecure clinical messagingProvider-to-provider
Bulk FHIR (Flat FHIR)$export · NDJSON · Bulk Data STU 1Payer / analytics / populationExport
Flat & custom formatsCSV, JSON, XML, delimited, fixed-width, Z-segments, custom APIsAny / legacy feedsAI-assisted reverse mapping

Terminology & code systems (translation + normalization)

ICD-10-CM/PCSSNOMED CTLOINCCPT / HCPCSRxNormNDCUCUMCVXRxTermsICD-11US Core value setsUSCDI

Crosswalks such as ICD-10 E11.9 ↔ SNOMED, and RxNorm ↔ NDC (e.g. ATORVASTATIN CALCIUM, NDC 59651-608) are handled by the Terminology agent with a confidence score on every match.

What you get

Engine capability, without the consulting tax

Everything a legacy engine does — plus AI mapping, conformance reporting and deployment flexibility that API networks and hyperscaler stores don't give you.

Bidirectional by design

Not a one-way FHIR façade. Every meaningful pairing runs both directions — v2→FHIR for API and patient access, FHIR→v2 to feed the systems that still speak HL7 v2.

AI mapping, human review

Agents propose mappings; your team approves them. Every mapping is versioned with diff and one-click rollback, and every field carries a plain-English explanation.

Conformance you can hand to procurement

Validation against US Core, Da Vinci and IPS profiles produces exportable conformance reports — the artifact buyers require before they integrate.

Real-time, batch & streaming

MLLP feeds, REST APIs, nightly batch and Bulk FHIR $export all run on the same engine, with guaranteed delivery, retry and replay.

Deploy where your data lives

Cloud, single-tenant VPC or on-prem. Control data residency and keep PHI inside your boundary — a control API networks can't offer.

Days, not months

The Onboarding agent learns a partner's format from sample messages and bootstraps the first interfaces — collapsing weeks-long interface builds into days.

Security & Compliance

Enterprise-grade trust, stated honestly

Protecting PHI is non-negotiable. Here's exactly where our certifications stand — no overclaiming.

HIPAAActive

Compliant · BAAs available

SOC 2 Type IIIn Progress

Audit in progress

HITRUST CSFOn Roadmap

On roadmap

HL7 · FHIRCore

Native, by design

AWS HIPAA-eligible infrastructure · Business Associate Agreements (BAAs) · Encryption in transit & at rest · See our security details →

Frequently asked questions

Ready to turn months of interface work into days?

See a live HL7 v2 ↔ FHIR translation on your own message types. No obligation.

Talk to our team