Ã… skape fremragende programvare
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
Nunzio Giugliano
jun 01, 2026 • 15 min read
European Health Data Space rollout. US CMS payer-access mandates. ONC certification updates. The rise of clinical AI that actually needs structured patient context. Four forces have collided in 2026, and the standard underneath every one of them is HL7 FHIR. If you build healthcare software and you have not made hard decisions about FHIR integration yet, the next twelve months will make them for you.
FHIR is the de facto standard for healthcare data interoperability across providers, payers, regulators and AI systems, and HL7 FHIR healthcare integration is now the default modern path for new clinical and administrative software. The FHIR standard for healthcare data is now mandated or recommended in the US, the EU, the UK, Australia and a growing list of other markets.
FHIR is the modern REST + JSON evolution of HL7v2 and is now mandated or recommended in the US, EU, UK and Australia. A production FHIR integration combines: a FHIR server choice (HAPI, Azure, Google, AWS, or commercial), the FHIR resource model with the right profiles (US Core, IPS, national), SMART on FHIR for authorisation, terminology binding to LOINC/SNOMED CT/RxNorm/ICD-10, and a strangler-fig migration plan to keep HL7v2 alive in parallel. Most of the engineering effort goes into terminology, not into the API mechanics.
This guide is for engineering leaders who have to build software that interoperates with hospitals, EHR vendors, payers, regulators, and increasingly with AI systems. It assumes you can read JSON and have heard the words "Patient" and "Observation" in some technical context. Everything else, we build up from there.
Starting a FHIR project? Jump to the FHIR server choices eller HL7v2 migration plan, or book a FHIR architecture review.
FHIR (Fast Healthcare Interoperability Resources, pronounced fire) is an open healthcare data standard maintained by HL7 International. It defines a set of resources - things like Patient, Encounter, Observation, MedicationRequest, Claim, Coverage - and a REST API for reading, writing, searching and subscribing to them.
Three things made FHIR different from earlier HL7 standards:
The combination matters because it makes FHIR finally usable for the people actually building software - and makes serious FHIR integration finally something an engineering team can own end-to-end, not outsource to specialists.
The FHIR vs HL7 comparison is one of the first questions engineering teams ask when starting a healthcare project. The short answer: FHIR is the modern REST + JSON evolution of the older HL7v2 messaging standard, and the two will coexist for years.
Most healthcare estates still run a great deal of HL7v2. The two standards coexist and will keep coexisting for a long time. Understanding the practical differences is critical for any team building new integrations.
| Aspect | HL7v2 | HL7 FHIR |
|---|---|---|
| Format | Pipe-delimited segments (MSH|^~\&|...). Hard to read, harder to debug. | JSON or XML. Readable, debuggable, tool-friendly. |
| Transport | MLLP / TCP. Often inside the hospital perimeter only. | HTTPS REST. Works anywhere the web works. |
| Interaction model | Asynchronous messages (event-driven). | Synchronous REST + subscriptions / FHIR Messaging when needed. |
| Schema rigour | Loose. Optional fields used inconsistently across vendors. | Strongly typed resources with profiles and validation. |
| Extension model | Z-segments - vendor-specific, fragile. | Formal extensions with canonical URLs and conformance. |
| Developer experience | Specialist integration engineers only. | Any modern software engineer can be productive. |
| Best for | Legacy ADT, lab order/result, document delivery inside hospitals. | New apps, AI products, patient access, payer-provider exchange, regulator reporting. |
FHIR R5 defines around 150 resources, but most production integrations rely on a much smaller core set. The goal is not to memorise the full specification: it is to understand which resources appear in almost every real healthcare workflow, how they relate to each other, and where profiles such as US Core or IPS add mandatory constraints.For engineering teams, the most useful way to read the FHIR resource model is by domain: administrative data, clinical facts, medications, financial flows, workflow objects, documents and infrastructure resources for audit, consent and eventing.
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
Patient, Practitioner, PractitionerRole, Organization, Lokasjon, Encounter, Appointment.
Patient is the anchor of almost every workflow - every encounter, observation or claim ultimately references it. Getting Patient identity, matching and merge logic right early is the foundation everything else sits on.
Observation, Condition, Procedure, AllergyIntolerance, Immunization, DiagnosticReport, ImagingStudy.
In most clinical integrations, Observation carries much of the operational weight: lab values, vital signs, scores and device-generated measurements often end up there. Getting Observation profiles and terminology bindings right early prevents expensive rework later.
MedicationRequest, MedicationDispense, MedicationAdministration, MedicationStatement.
MedicationRequest is the entry point for most prescribing workflows, while MedicationAdministration captures what was actually given. Confusing the two - especially in EHR-to-pharmacy integrations - is one of the most common modelling mistakes in early FHIR projects.
Coverage, Claim, ExplanationOfBenefit, Account, Invoice.
Coverage and Claim drive most payer-provider exchange, especially in the US under CMS Patient Access and Payer-to-Payer rules. Modelling them correctly upfront is non-negotiable for anything touching insurance eligibility, billing or claims adjudication.
Fra idé til lansering lager vi skalerbar programvare som er skreddersydd til dine forretningsbehov.
Samarbeid med oss for å akselerere veksten din.
Task, ServiceRequest, CarePlan, Goal.
Task is the orchestration backbone for clinical workflows - anything assigned, tracked or escalated maps to it. Underused in early implementations, but indispensable once a workflow scales beyond a single user or department.
DocumentReference, Bundle, Composition, Binary.
Bundle is the most-used resource in this group despite being infrastructure rather than a document it self - every multi-resource exchange (search response, transaction, batch) is wrapped in one. DocumentReference handles the unstructured artefacts (PDFs, scans, signed reports) that still need to coexist with structured data.
Subscription, Provenance, AuditEvent, Consent.
AuditEvent and Consent carry the compliance weight - any system serving regulated workflows must emit AuditEvent for every meaningful access and respect Consent decisions including withdrawal. Subscription is what makes real-time event-driven integrations possible without polling the server.
Each resource has a defined schema, identifiers, references to other resources and an extension mechanism. In production, however, teams rarely work with isolated resources. They work with Bundle resources, profile constraints, terminology bindings and validation rules that determine whether the data is actually usable across systems.
This is where FHIR integration becomes more than API development. The resource model gives you the structure, but profiles and terminology determine whether two systems can interpret the same patient, observation or medication in the same way.
Vi designer og bygger digitale produkter av høy kvalitet som skiller seg ut.
PÃ¥litelighet, ytelse og innovasjon i alle ledd.
A FHIR server exposes a small set of REST interactions per resource:
// Read a single Patient
GET /Patient/12345
// Search by criteria
GET /Patient?family=Rossi&birthdate=1972-03-14
// Create a new Encounter
POST /Encounter
Content-Type: application/fhir+json
// Conditional update
PUT /Patient?identifier=urn:org:hospital|MRN-12345
// Batch / transaction
POST /
Content-Type: application/fhir+json
{ "resourceType": "Bundle", "type": "transaction", "entry": [ ... ] }
Every FHIR resource defines its own search parameters. Learning how to combine them correctly is one of the fastest ways to make an integration useful, because most real workflows start with finding the right Patient, Encounter, Observation or Claim before doing anything else.
_include og _revinclude_include and _revinclude behave like controlled server-side joins. They let you retrieve related resources - for example a Patient and their Encounters - in a single request, avoiding unnecessary N+1 round trips.
Transaction Bundles allow multiple resource changes to be submitted as one atomic operation. They are essential when creating related resources together, such as a Patient, Encounter and Observation that must either all be written successfully or all be rejected.
Conditional operations are the practical answer to duplicate prevention. When source systems do not provide stable identifiers, conditional create and update rules let the FHIR server decide whether to create a new resource or update an existing one.
Subscriptions allow downstream systems to react when relevant resources change, instead of polling the FHIR server repeatedly. For clinical alerts, analytics pipelines and AI services, this event-driven model is usually more reliable and less expensive than scheduled polling.
$everything, $expand, $match)Server-defined RPC-style endpoints for things that do not fit pure REST.
Provenance and AuditEvent make data lineage and access history explicit. In regulated healthcare environments, they are not optional metadata: they are part of the evidence trail needed for audit, consent management and incident investigation.
Taken together, these patterns are what separate a demo FHIR API from a production integration. A demo can read and write resources; a production system must search consistently, avoid duplicate records, preserve audit trails, handle consent and keep downstream systems synchronised.
You will not get far in real-world FHIR without SMART on FHIR. It is the OAuth 2.0 / OpenID Connect profile that defines how third-party applications launch and authorise against a FHIR server - and it is the only sensible answer for healthcare authorisation.
The reason is simple: healthcare integration is not only about moving data. It is about proving who is requesting that data, which patient or user context they are operating in, what scope of access they have, and whether that access can be audited or revoked.
The architectural points that matter:
patient/*.read is dramatically broader than patient/Observation.read. Design scopes to be as narrow as the use case allows.
EHR-launch reuses the EHR's session and provides context (patient, encounter) via the launch token. Standalone-launch starts cold and asks for context.
For server-to-server integration, the SMART Backend Services profile uses signed JWTs and asymmetric keys instead of user authentication. This is how AI services, registries and analytics platforms should integrate.
A real implementation handles refresh tokens cleanly and respects the consent withdrawal flow.
We have shipped SMART on FHIR launches into Epic, Cerner, Meditech and several European EHRs. The pattern is mature; the gotchas are vendor-specific quirks in scope handling and launch parameter passing.
FHIR integration with major EHR vendors in 2026 means SMART on FHIR for most new connections, with a long tail of HL7v2 and proprietary APIs for the cases SMART does not yet cover. EHR integration services built today are SMART-first, with v2 bridges only where they are still unavoidable.
Vendor-specific notes from production work:
App Orchard / Showroom for clinical apps. SMART on FHIR is well supported but rate limits are aggressive and Epic-specific scopes / extensions exist. Read access is generally smooth; bulk and write access require careful planning.
SMART on FHIR through the code.cerner.com developer portal. R4 well supported. Bulk Data Export available for analytics and AI use cases.
Expanse supports SMART. Older deployments may require HL7v2 bridges.
Strong FHIR R4 support for ambulatory practices.
FHIR adoption is highly variable across Cerner DE, InterSystems, Dedalus and regional public-health systems. National profiles (e.g. Germany's gematik specifications, Italy's FSE) often layer additional requirements.
The non-obvious lesson from running EHR integrations: most of the engineering effort goes into terminology binding (mapping local codes to LOINC, SNOMED CT, RxNorm, ICD-10), not into the FHIR API mechanics. Reserve a senior clinical informaticist budget line for any non-trivial project.
Most teams do not build their own FHIR server. They pick one and customise it.
Open-source Java FHIR server (hapifhir.io). Self-host or use vendor-managed distributions. Maximum control. Heavy lift for compliance, scaling and security.
Managed Azure Health Data Services (FHIR service) with strong Azure integration, AI/analytics tie-ins, and DICOM/MedTech extensions. Good fit for organisations already on Azure.
Google Cloud Healthcare API - managed FHIR, HL7v2, DICOM and Consent stores. Strong de-identification and AI / Vertex integration.
AWS HealthLake - managed FHIR store with integrated NLP and ML capabilities. Good fit on AWS-heavy estates.
Firely Server, Smile CDR and InterSystems IRIS for Health are commercial FHIR platforms with terminology, profiling and integration features that the hyperscalers do not bundle.
The right choice depends on data residency, terminology requirements, existing cloud footprint and the depth of FHIR-specific tooling you need. For most EU-based FHIR integration programmes, data residency and EHDS readiness are the deciding factors.
For brownfield environments, the realistic migration is incremental:
This is essentially the strangler-fig pattern applied to messaging - the same pattern we describe in our legacy system modernization guide for mainframe and core-system migration. It is the only realistic path; big-bang HL7v2 → FHIR migrations of a hospital estate are not a thing that ships.
CTA - Building a FHIR application or migrating off HL7v2?
Our healthcare engineering team can plug in at architecture, build, or continuous-engineering level. Request a FHIR architecture review →
FHIR is being pulled into production by regulation almost as much as by technology. Building healthcare interoperability software in 2026 means designing for EHDS, CMS, ONC and HIPAA compliance from day one.
EHDS was finalised in 2024 and rolls out through 2026–2030. Mandates cross-border patient data exchange and secondary use of health data - both built on FHIR.
US CMS Interoperability and Patient Access rules mandate FHIR-based payer APIs (Patient Access, Provider Directory, Payer-to-Payer Data Exchange).
US ONC certification requires certified EHRs to expose USCDI data via FHIR.
Cross-cut everything. Consent, access control, audit, de-identification and breach notification all apply to FHIR endpoints exactly as they apply to any other healthcare system.
For digital health products serving EU financial-services-adjacent use cases, operational resilience requirements increasingly affect health-tech vendors with financial-services parent companies or partners.
The implication for engineering teams is straightforward: build FHIR integration with audit, provenance, consent, access control and de-identification as first-class citizens, not as afterthoughts.
We build healthcare software for European providers, payers, health-tech startups and clinical AI products - and FHIR integration is the layer underneath almost all of it. Lasting Dynamics is a European healthcare software development company that has shipped FHIR integrations across the EU. Our FHIR implementation guide is the document above, plus the work we do not put on a public blog: terminology mapping playbooks, conformance test suites, EHR-specific quirks, and the deployment patterns we have validated under audit.
If your team is starting a FHIR project - a new patient app, an EHR integration, a clinical AI product that needs structured access to records, or a migration off HL7v2 - we can plug in at any of three layers:
We are ISO 9001 and PCI DSS 4 certified, and we have shipped FHIR integrations in production for clients across the EU at Lasting Dynamics.
CTA - Starting a FHIR programme?
Book a 30-min architecture review - we will look at your target EHR(s), your FHIR server choice and your terminology binding plan, and tell you the three things to lock down first. Get a FHIR integration assessment →
This guide was written by Nunzio Giugliano, Marketing Specialist at Lasting Dynamics - an EU-based healthcare software development company that has shipped FHIR integrations, SMART on FHIR launches and EHR connectivity for providers, payers and health-tech firms across the EU. We are ISO 9001 and PCI DSS 4 certified. References to specific EHRs (Epic, Oracle Health / Cerner, Meditech, athenahealth, Dedalus, InterSystems) reflect public vendor documentation and our own integration experience; regulatory references (EHDS, CMS rules, ONC USCDI, HIPAA, GDPR, DORA) reflect publicly available regulatory texts. Where vendor specifics change frequently (Epic App Orchard naming, FHIR R5 subscription syntax), confirm against current vendor documentation before final architecture decisions.
FHIR integration is the practice of connecting a piece of healthcare software - an EHR, a clinical AI tool, a patient app, a payer system, a registry - to other healthcare systems using the HL7 FHIR standard. Concretely, that means exchanging data as FHIR resources (Patient, Observation, MedicationRequest, etc.) over a RESTful API, authenticated using OAuth 2.0 profiles like SMART on FHIR. It is the modern standard for moving clinical and administrative healthcare data between systems, and it is mandated or recommended in the US, the EU, the UK, Australia and a growing list of other markets.
HL7 is the standards-development organisation. It has published several standards over decades - most importantly HL7 v2 (the pipe-delimited messaging standard still used inside most hospitals), HL7 v3 / CDA (document-oriented, widely used in some regions), and HL7 FHIR (the modern REST + JSON standard). When people say 'HL7' they usually mean HL7 v2; when they say 'FHIR' they mean the modern standard. FHIR replaces the messaging format of v2 with a RESTful resource model, and is dramatically easier for modern software teams to integrate with.
SMART on FHIR is an open standard that defines how third-party applications authenticate, authorise and launch against a FHIR server using OAuth 2.0 and OpenID Connect. It supports two main flows: EHR launch, where an app is launched from inside an EHR with patient and user context already established, and standalone launch, where the user authenticates against the EHR's authorisation server from outside. SMART defines a set of scopes - like patient/Observation.read or user/MedicationRequest.write - that constrain what the app can access. It is supported by every major EHR (Epic, Cerner / Oracle Health, Meditech, athenahealth, AllScripts) and is the de facto standard for clinical app authorisation.
Building a FHIR-compliant application means four things in sequence: (1) pick a FHIR server (HAPI, Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake, or a commercial platform like Firely or Smile CDR) and the right FHIR version (R4 is the production baseline; R5 where supported); (2) model your domain using the standard FHIR resources and apply the relevant profile (US Core, UK Core, IPS, or a national profile like gematik or FSE); (3) implement SMART on FHIR for authorisation - EHR launch for clinical apps, Backend Services for server-to-server; (4) bind your terminology to LOINC, SNOMED CT, RxNorm and ICD-10, and wire up Provenance, AuditEvent and Consent from day one. Treat audit, consent and de-identification as first-class concerns, not afterthoughts.
FHIR R5 defines around 150 resources, but production work runs on 20–30. Start with the high-frequency administrative ones (Patient, Practitioner, Organization, Location, Encounter), then the clinical core (Observation, Condition, Procedure, AllergyIntolerance, DiagnosticReport), the medication chain (MedicationRequest, MedicationDispense, MedicationAdministration), and the financial set (Coverage, Claim, ExplanationOfBenefit) if you touch payers. Above that, you need Bundle (collections sent or returned together), Subscription (real-time push), and the infrastructure resources (Provenance, AuditEvent, Consent) that regulators care about.
In 2026, almost every new EHR integration uses SMART on FHIR, with HL7v2 and proprietary APIs covering the long tail. Epic exposes FHIR through App Orchard / Showroom with aggressive rate limits and Epic-specific scopes; Oracle Health (Cerner) integrates through code.cerner.com with strong R4 support and Bulk Data Export; Meditech Expanse supports SMART while older deployments may need an HL7v2 bridge; athenahealth has solid FHIR R4 for ambulatory practices. European EHRs (Dedalus, InterSystems, regional public-health systems) are far more variable and usually add national profile requirements. The non-obvious lesson: most of the engineering effort goes into terminology binding (mapping local codes to LOINC, SNOMED CT, RxNorm, ICD-10), not into the FHIR API itself.
The right FHIR server depends on data residency, terminology requirements, existing cloud footprint and how much FHIR-specific tooling you need. HAPI FHIR (open-source Java) gives maximum control but a heavy compliance and scaling lift. Azure Health Data Services is the natural fit on Azure with strong AI and DICOM tie-ins. Google Cloud Healthcare API bundles FHIR, HL7v2, DICOM and Consent stores with strong de-identification and Vertex AI integration. AWS HealthLake combines a managed FHIR store with built-in NLP and ML. For deeper FHIR-native features - terminology services, profiling, conformance - commercial platforms like Firely Server, Smile CDR and InterSystems IRIS for Health typically outperform the hyperscalers. For EU clients, data residency and EHDS readiness are usually the deciding factors.
The realistic migration is incremental, not big-bang - the strangler-fig pattern applied to messaging. Step 1: stand up a FHIR façade (FHIR server + a translation layer in your integration engine - Mirth Connect, Rhapsody or Iguana - that converts existing ADT, ORU, ORM and SIU v2 messages into FHIR resources). Step 2: route any new app, partner or AI service to the FHIR endpoints, not v2. Step 3: implement bidirectional sync so FHIR-created resources propagate back into the v2 layer for legacy consumers. Step 4: retire v2 endpoints one at a time as their consumers move to FHIR. At hospital scale this is a multi-year programme; big-bang HL7v2 → FHIR migrations of an entire estate are not a thing that ships.
Forvandle dristige ideer til kraftfulle applikasjoner.
Let’s create software that makes an impact together.
Nunzio Giugliano
Nunzio Giugliano is a Marketing Specialist at Lasting Dynamics, where he works on SEO strategy, technical content and B2B research across AI, enterprise software and digital transformation topics. His work focuses on making complex technology subjects clear, useful and accessible for CTOs, founders, decision makers and technical teams.
