FHIR and HL7 interface development
Digital Scientists builds FHIR R4 APIs and gateways, SMART on FHIR apps and HL7 v2 interfaces for health tech companies and providers. We built a FHIR R4 gateway for NeverAlone on the open-source HAPI FHIR stack, tested end to end against emulators and waiting on a partner's production credentials. In production, we match patients across PointClickCare and Netsmart (GEHRIMED) data on platforms we run. HL7 v2 and SMART on FHIR are capability work, and we label them that way. Most projects start with a week-one check of access, data and vendor terms.
Updated
Gateway we built on HAPI FHIR, tested end to end
Patients on NeverAlone, a platform we integrate and run
Recovered to date on CommuniCare's MDS platform, built on PointClickCare data
NeverAlone live and run by us since
Where do you stand on FHIR and HL7?
We've built a FHIR R4 gateway, tested Epic in a sandbox, and run production data integrations with PointClickCare and Netsmart (GEHRIMED). We have no HL7 v2 production interfaces on record. The tiles show which is which.
FHIR (Fast Healthcare Interoperability Resources) is the API standard for health data: records served as web resources such as Patient, Encounter and Observation. HL7 v2 is the older message standard that hospitals and labs still run every day. Most organizations end up needing both.
Buyers of FHIR integration services deserve a straight status report, so here's ours. The gateway runs on HAPI FHIR and is waiting on a partner's production credentials. On the platforms we run, we match the same patient across PointClickCare and Netsmart (GEHRIMED) data. HL7 v2 feeds and SMART on FHIR apps are capability: we know the standards and build to them, and we say so up front. This page is one part of our healthcare integration services.
FHIR R4 gateway: built
HAPI FHIR, tested against emulators; waiting on production credentials
PointClickCare: production
EHR data on platforms we run
Netsmart (GEHRIMED): production
Patients matched across both EHRs
Epic: sandbox
A test patient pulled from Epic's FHIR sandbox
SMART on FHIR: capability
Apps that launch inside the EHR
HL7 v2: capability
ADT, ORM and ORU feeds
Can you put a FHIR API in front of a system that doesn't speak FHIR?
Yes. That's what a FHIR gateway does: it accepts standard FHIR R4 requests and translates them into calls the backend already understands. We built one for NeverAlone on HAPI FHIR.
A FHIR server stores and serves FHIR resources. A gateway is lighter: your data stays where it lives, and a resource service maps each FHIR request to the backend's own API or database. One request for a patient's full record, the standard $everything operation, can turn into several backend calls stitched into a single response.
On NeverAlone we connected the gateway to the platform's backend and built purpose-made connectors around the open-source Java HAPI FHIR stack. No live source was available yet, so we built emulators of the EHRs on the other end and ran the FHIR R4 workflow end to end against them. The partner's production credentials are the remaining dependency. That's normal. Partner programs set the calendar more often than code does.
The same pattern fits a product that has to expose its data as FHIR to customers, payers or a certification test.
The version the gateway serves
The open-source Java stack underneath
Tested against emulators; waiting on production credentials
How does a SMART on FHIR app launch inside an EHR?
The EHR opens your app, hands it the patient and user in context, and grants a scoped token, so the clinician never logs in twice. SMART on FHIR app development is capability work for us: we build to the published spec and test in the vendor's sandbox first.
Register
The app is registered in the EHR vendor's developer program with its redirect address and the scopes it needs, such as read access to a patient's observations.
Launch
The clinician opens the app from inside the chart. The EHR sends a launch token and the address of its FHIR server.
Authorize
The app trades the launch token for an OAuth 2.0 access token scoped to that patient and user. OpenID Connect tells the app who the user is.
Read and write
The app calls the EHR's FHIR API for that patient only, and writes back where the vendor and the provider allow it.
Distribute
For one health system, its own EHR team approves the app. For a product many systems will buy, the vendor's marketplace review sets the timeline, so it goes in the plan from day one.
What do HL7 v2 ADT, ORM and ORU messages carry?
ADT carries patient movement, ORM carries orders and ORU carries results. They're the event feeds most hospitals and labs still run, usually through an interface engine.
HL7 v2 messages are pipe-delimited text built from segments: MSH for the header, PID for the patient, PV1 for the visit, OBR and OBX for orders and results. Every sender bends the standard a little, so each feed gets its own mapping, tested with sample messages from the real source.
HL7 integration is capability work for us; we have no HL7 v2 production interfaces on record. If you already run an interface engine, we connect to it and work with the team that owns it. If you don't, we build listeners in code on queues with acknowledgments, retries and monitoring, inside your cloud account.
Common HL7 v2 message types and what they carry
| Message | Example events | What it carries | Typical use |
|---|---|---|---|
| ADT | A01 admit, A03 discharge, A04 register, A08 update | Demographics, visit, location and attending provider | Keep a patient list current; start work on admission or discharge |
| ORM | O01 new or changed order | The order, ordering provider, priority and test codes | Send lab and imaging orders to the system that performs them |
| ORU | R01 result | Results in OBX segments with LOINC codes, units, reference ranges and abnormal flags | Bring lab results back into the chart or your product |
| SIU | S12 new appointment, S14 change | Scheduling events | Keep appointments in step with a scheduling system |
| ACK | Acknowledgment | Accepted, rejected or error | Confirm each message arrived, so none is lost silently |
Status for every HL7 v2 message type: capability. Newer lab systems often send OML in place of ORM for lab orders.
What do ONC (g)(10) and US Core require of a FHIR API?
ONC criterion (g)(10) requires certified health IT to offer a standardized FHIR API for single-patient and population data. US Core defines what each FHIR resource has to contain. We build to both as capability work and test with Inferno, ONC's test kit.
We've also stood up OpenEMR, an open-source ONC-certified EHR with a FHIR API, as a test bed.
US Core profiles
The US Core Implementation Guide constrains FHIR R4 resources to the USCDI data classes: patients, problems, medications, allergies, labs, vital signs, notes and more. Each version tracks a USCDI version, so we confirm which one you're targeting.
SMART App Launch
(g)(10) requires both EHR and standalone launch, OAuth 2.0 with granular scopes, and refresh tokens for patients who come back.
Bulk FHIR
Population-level export through the Bulk Data $export operation, for payers, ACOs and analytics.
Inferno testing
We run the Inferno tests early and on every release, so failures show up in development, not at the test lab.
The test lab
Certification runs through an ONC-Authorized Testing Lab and Certification Body. We prepare the evidence; your company holds the certification.
Where does a FHIR or HL7 project start?
With a week-one check of access, data and vendor terms. Partner programs and production credentials set most of the calendar, so we start those requests on day one.
These are common starting points, not rules. Larger builds often begin with a Blueprint that maps the data, access and risk before the build.
- You need to expose data as FHIR. We map your data model to US Core resources, then stand up a gateway or a FHIR server, depending on whether the data should move.
- You need an app inside the EHR. We scope the SMART launch, the scopes and the vendor program first, then build against the sandbox.
- You need an HL7 v2 feed. We get sample messages and the interface spec from the sending system before writing a mapping.
- You need certification. We run Inferno against what you have, list the gaps and plan the fixes.
Access, real data and vendor terms checked
Signed before we touch patient data
Support on the platforms we built
Related work in production
NeverAlone · CommuniCare
30,000 patients across six states
A 24/7 virtual care platform with PointClickCare and Netsmart (GEHRIMED) data and patients matched across both EHRs. Our FHIR R4 gateway connects to its backend.
See the work
CommuniCare MDS · PointClickCare
$10M+ recovered to date; $24M+ forecast PDPM revenue
AI recommendations for MDS coordinators built on PointClickCare data from April 2024, then handed to CommuniCare's own team. The data mapping is the same work a FHIR gateway runs on.
See the work
Duke Health
Siloed partner data in one research platform
Data modeling and API architecture that brought SDOH datasets and partner data from across Duke into one platform. Related work: the same source-by-source mapping FHIR and HL7 projects need.
See the workTrusted by healthcare leaders.
“I have worked with many technology teams during my career, and Digital Scientists is one of the best. They take the time to understand the customers' needs, deliver innovative solutions, are always professional, and work with your team as a true partner to achieve success.”
Amy Severino
Chief Innovation Officer, NeverAlone
“Digital Scientists provided immense value to our plan administrators, providers, and patients. The team was able to come in and understand our core needs, while remaining product agnostic. They helped identify the technical debt and pitfalls, and to get us to a point of stabilization and growth.”
Robert Hager
CEO, CommuniCare Advantage
Related integration work
Healthcare integrations
EHR, FHIR, labs, payers, claims and HIPAA cloud.
Healthcare integrations →EHR integration
PointClickCare and Netsmart (GEHRIMED) in production.
EHR integration →Payer APIs and prior authorization
Eligibility, CMS payer FHIR APIs and electronic prior auth.
Payer APIs and prior authorization →Lab integration
Orders, results and LOINC codes.
Lab integration →Behavioral health EHR integration
Integrations for behavioral health and SUD providers.
Behavioral health EHR integration →Latest thinking on healthcare interoperability
Questions about FHIR and HL7
Do you use HAPI FHIR?
Yes. Our FHIR R4 gateway runs on the open-source Java HAPI FHIR stack, with connectors we built around it and a resource service that maps FHIR requests to backend calls. It's tested end to end against emulators and waiting on a partner's production credentials. When a managed FHIR service inside your own cloud account fits better, we'll say so in the week-one check.
Can you expose our data as FHIR?
Yes. We map your data model to FHIR R4 resources, usually US Core profiles, and serve them through a gateway that reads your existing system or a FHIR server that holds a copy. A gateway keeps one source of truth. A server is faster to query and simpler to certify. The mapping is most of the work, so we start with a sample of your real data under a BAA.
Can you pass ONC certification tests?
We haven't taken a product through ONC certification yet, so we won't promise a pass. We know the criteria, (g)(10) and US Core in particular, and we run Inferno, the test kit the labs use, from the first sprint so gaps surface early. Certification itself runs through an ONC-Authorized Testing Lab and Certification Body, and your company holds it.
Do you build HL7 v2 interfaces?
Yes, as capability work. We have no HL7 v2 production interfaces on record, and we tell anyone who asks. We build ADT, ORM and ORU feeds to the sending system's own spec, tested with its sample messages. If you run an interface engine, we work with the team that owns it.
Have you integrated with Epic?
In a sandbox. We've pulled patient data from Epic's FHIR sandbox, and we don't have an Epic production interface on record. For one health system, the fastest route is usually the interface its Epic team already supports. For a product many Epic sites will buy, it's a SMART on FHIR app through Epic's developer program.
Do we need FHIR or HL7 v2?
Often both. FHIR suits apps, APIs and anything a payer or certification rule requires. HL7 v2 is still how most hospitals and labs push real-time events such as admissions and results. We choose per system based on what the vendor actually supports, and we confirm that in week one.
Talk it over
Tell us what you are trying to do. A senior person from our Atlanta team replies within one business day, and you can book a 30-minute call right after you send this.
- We tell you if we're the right fit, and if we're not, who is.
- Most work starts small, so you see how we work before you commit to more.
- We sign a BAA before we touch patient data.