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. AI agents 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, and you control the data
See the translation engine
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
PID → Patient
PV1 → Encounter
DG1 → Condition
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
The AI Mapping Agent parses an inbound HL7 v2.5.1 ADT^A01 admission message 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. Output is 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. A fleet of specialized AI agents drafts the mappings, translates terminology and validates output, 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. Bidirectional translation is the bridge that gap requires.
0 APIs
CMS-0057-F FHIR APIs
due Jan 1, 2027
~43% / 47%
payers / providers not started
WEDI, Oct 2025
0
AI agents in the fleet
orchestrated, human-reviewed
Days
to a first interface
without 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. 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. 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
PID → Patient
PV1 → Encounter
DG1 → Condition
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
The AI Mapping Agent parses an inbound HL7 v2.5.1 ADT^A01 admission message 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. Output is 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, then 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

Every meaningful pairing runs both directions. v2→FHIR powers APIs and patient access; FHIR→v2 keeps feeding 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. That is 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. That is a control API networks can't offer.

First interface in days

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

The AI agent fleet

Twelve specialists, one orchestrator

Each agent owns a domain (mapping, terminology, validation, prior-auth, pharmacy and more) and operates with human-in-the-loop review and full audit.

Mapping Agent

codename “Cartos”

Generates and refines field/schema mappings between any two formats.

HL7 v2.xFHIR R4/R4B/R5C-CDA

Terminology Agent

codename “Lexid”

Translates and normalizes codes across clinical & billing code systems.

ICD-10-CM/PCSSNOMED CTLOINC

Transformation Agent

codename “Morphi”

Converts every message in both directions without losing meaning.

HL7 v2.xFHIRC-CDA

Validation Agent

codename “Conforma”

Guarantees output conforms to the correct profile / implementation guide.

US CoreDa Vinci IGsIPS

Prior-Auth Agent

codename “Authra”

Runs end-to-end electronic prior authorization.

CMS-0057-FDa Vinci PAS/CRD/DTRX12 278

Pharmacy Agent

codename “Rxena”

Owns the drug-industry interoperability surface.

NCPDP SCRIPT v2023011NCPDP RTPB v13CARIN RTPBC

Agent codenames are working names pending trademark & domain clearance. Functional names describe what each agent does.

Explore all 12 agents
Go deeper

Explore the platform

Each surface has its own deep dive, from the core translation engine to prior authorization, pharmacy and security.

HL7 v2 ↔ FHIR Engine

The core translation engine: every message type (ADT, ORU, SIU, MDM...) to the right FHIR resource, both directions, with round-trip fidelity.

Learn more

Medical Coding & Terminology

AI code translation across ICD-10, SNOMED CT, LOINC, CPT, RxNorm and NDC. Value-set binding and local-code reconciliation, with confidence scoring.

Learn more

Prior Authorization (CMS-0057-F)

The PARDD API, Da Vinci PAS/CRD/DTR and X12 278 ↔ FHIR. Automated documentation assembly for the January 2027 deadline.

Learn more

Pharmacy & e-Prescribing

NCPDP SCRIPT, EPCS, electronic prior auth, Real-Time Prescription Benefit and RxNorm↔NDC, connecting EHRs, pharmacies, PBMs and pharma.

Learn more

The AI Agent Fleet

Twelve specialized agents (mapping, terminology, validation, prior-auth, pharmacy and more), coordinated by an orchestrator with human-in-the-loop review.

Learn more

Security & Compliance

HIPAA with BAAs today, SOC 2 Type II in progress, HITRUST on the roadmap. Runs on AWS HIPAA-eligible infrastructure, with SMART on FHIR, RBAC and immutable audit.

Learn more

Security & Compliance

Where our compliance actually stands

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