Skip to content
Let’s Talk(678) 203-0800 Partner ProgramDocumentationDocsBlogContact
Solutions  /  HL7 & FHIR Platform

The HL7 and FHIR integration platform that runs in your own Azure tenant.

HL7 v2.x messaging and FHIR R4 resources on one Azure-native runtime, deployed into your own Azure subscription. PHI stays inside your cloud boundary, and the version question — R4 today, R6 later — is answered by the mapping layer rather than by rebuilding your interfaces.

Your Azure subscription HIPAA-aligned controls Microsoft Solutions Partner

In short

Art2link ESB is an Azure-native HL7 and FHIR integration platform that deploys into the customer’s own Azure subscription, so PHI never leaves their cloud boundary. It handles HL7 v2.x messaging and FHIR R4 resources on one runtime, with the v2-to-FHIR mapping held in a versioned layer so an estate can move to FHIR R6 without rebuilding its interfaces. Built by Cerebrum City, integration specialists with two decades of Microsoft BizTalk Server delivery and 500+ enterprise deployments.

Which FHIR release — and what happens at the next one.

Every integration vendor says it supports FHIR. Almost none of them say which release, or what a version change costs you. Here is the honest version.

FHIR R4

4.0.1 · 2019

Production baseline
What it is
The first release with normative content. It is the default for production use and the release that regulatory and certification programmes reference.
What it means for your estate
This is what you build to today. New consumers, payer APIs and certification work all assume R4.
Where Art2link sits
Full production support. R4 is the target for every FHIR interface Art2link publishes.

FHIR R5

5.0.0 · 2023

Largely skipped
What it is
Substantial modelling improvements, but breaking changes alongside them, and limited adoption in the field.
What it means for your estate
Most estates skipped it. Building to R5 now buys little and leaves forward compatibility uncertain.
Where Art2link sits
Supported where a specific counterparty requires it. Not recommended as an estate-wide target.

FHIR R6

6.0.0-ballot3 · in ballot

Plan for it, do not wait for it
What it is
The release expected to move most clinical and administrative resources to normative. Final publication is anticipated in late 2026.
What it means for your estate
Broad production support is unlikely before late 2027. Your R4 interfaces will be running throughout that window.
Where Art2link sits
Absorbed in the mapping layer. When R6 lands you change mappings, not endpoints, transports or routing.

The promise this makes: your HL7 v2 feeds land on R4 today, and the mapping layer — not your interfaces — absorbs R6 when it arrives.

Version status per Health Samurai’s FHIR R6 readiness analysis and Metriport’s FHIR R4 specification guide.

HL7 v2 in, FHIR resources out.

The translations that carry most production traffic. Each one is a mapping you can inspect, version and roll back — not a black box inside a connector.

HL7 version 2 message types and the FHIR R4 resources Art2link maps them to
HL7 v2 message maps to FHIR R4 resource What it carries
ADT A01, A04, A08, A31 Patient · Encounter Registration, admission, transfer and demographic updates.
ORU^R01 Observation result Observation · DiagnosticReport Results delivery from ancillary systems to the record.
ORM / OMP Order message ServiceRequest · MedicationRequest Orders for services, procedures and medications.
SIU S12, S14, S15, S26 Appointment · Schedule Scheduling, rescheduling and cancellation events.
DFT P03 ChargeItem · Account Detailed financial transactions posted to billing.
MDM T02, T06 DocumentReference Clinical document notification and content transfer.

PHI does not leave your cloud boundary.

Art2link ESB is single-tenant by construction. It deploys from the Microsoft Marketplace into your own Azure subscription, in the region you nominate, under your own Microsoft Entra ID tenant. There is no vendor-hosted environment holding clinical messages, because there is no vendor-hosted environment at all.

That is the whole deployment argument in three sentences. The long version — the three-model comparison, key ownership, residency and what Cerebrum City can and cannot see — lives on Deployment.

Your Azure subscription, your region, your billing
Message content and audit records rest inside your tenant
Entra ID identity, RBAC, TLS 1.3, AES-256, BAA available
No shared multi-tenant runtime holding clinical data

Standards coverage.

Healthcare integration spans two standards bodies, not one. Art2link carries both sides of that boundary on the same runtime.

Health Level Seven International

Clinical messaging and documents

The HL7 family: legacy v2 pipe-delimited messaging that still moves most production traffic, and the FHIR resource model that new consumers expect.

HL7 v2.3 HL7 v2.3.1 HL7 v2.4 HL7 v2.5 HL7 v2.5.1 HL7 v2.6 FHIR R4 CDA / C-CDA MLLP
Accredited Standards Committee X12

Payer and revenue-cycle transactions

The administrative side of healthcare runs on X12, not HL7. Claims, remittance and eligibility move as HIPAA-mandated 5010 transaction sets.

837P / 837I 835 270 / 271 276 / 277 834 AS2
A distinction worth keeping straight: X12 5010 is an ASC X12 standard, not an HL7 one. Vendors conflate the two constantly. Clinical data moves in HL7; payer transactions move in X12; a healthcare integration platform has to speak both, and know the difference.

Two healthcare answers, deliberately separate.

Reference laboratories have a different integration problem to health systems. We wrote each of them their own page rather than one that half-serves both.

You run a reference lab

Analyzers, LIS and accession workflow.

Instrument interfaces, discipline-by-discipline vendor coverage, order and result flow from the floor to the ordering EHR, and the operational view a lab CTO actually needs.

HL7 / FHIR for laboratories →
You are leaving BizTalk

What actually changes in a v2-to-FHIR programme.

The migration question, written for teams whose HL7 interfaces currently run on BizTalk Server: what carries forward, what has to be re-thought, and what the sequencing looks like.

Read the migration analysis →

The questions integration architects actually ask.

Seven answers, written to be checked rather than admired.

Does Art2link ESB support FHIR R4 or R5?

FHIR R4 is the production baseline. R4 (2019) was the first release with normative content and remains the release regulators and certification programmes reference, so it is what Art2link targets for production interfaces. R5 (2023) introduced breaking changes alongside its improvements and has seen limited adoption — most estates skipped it. Art2link supports R5 where a specific counterparty requires it, but does not recommend it as an estate-wide target.

What happens to our interfaces when FHIR R6 is published?

Your interfaces do not change. The HL7 v2 to FHIR translation lives in a versioned mapping layer, held separately from endpoints, transports and routing rules. Moving a consumer from R4 to R6 is a change to that layer, not a rebuild of the estate. R6 is currently in ballot (6.0.0-ballot3); final publication is expected in late 2026, and broad production support is unlikely before late 2027.

Where does PHI live when we use Art2link?

Inside your own Azure subscription. Art2link ESB deploys from the Microsoft Marketplace into your Azure tenant, in the region you choose. Message content, mappings and audit records rest inside that boundary rather than in a vendor-hosted multi-tenant environment. The deployment model is documented in full on Deployment.

Can we keep our HL7 v2 feeds and expose FHIR at the same time?

Yes — that is the normal configuration, not a transitional state. One runtime carries both: existing HL7 v2.x interfaces over MLLP continue unchanged while the same messages are translated to FHIR R4 for consumers that expect them. There is no cutover event, and no requirement to retire v2 in order to start publishing FHIR.

Do we need a separate FHIR server?

Not for integration. Art2link produces and consumes FHIR R4 resources and translates between HL7 v2 and FHIR at runtime. If your architecture also requires a persistent, queryable FHIR repository of record, Art2link integrates with one rather than replacing it — the platform is the interface engine, not the clinical data store.

How does this differ from Azure Health Data Services?

Azure Health Data Services provides managed FHIR and DICOM services — the data plane. Art2link is the integration layer above it: HL7 v2 transport and acknowledgements, validation, transformation, routing, error handling, replay and per-message audit across an estate of interfaces. They are complementary, and Art2link runs in the same Azure subscription.

Is Art2link HIPAA-ready?

Art2link ships HIPAA-aligned controls: TLS 1.3 in transit, AES-256 at rest, identity through Microsoft Entra ID, role-based access control and immutable audit logging. Because the runtime sits in your own Azure subscription under your own governance, the controls you already operate apply to it. A BAA is available. The full control set is on Security & Governance.

Put the version question to an architect.

Bring your interface inventory and your FHIR roadmap. You will get a senior integration architect — not an SDR — and a straight answer on what carries forward, within one business day.