Nalashaa partnered with a mid-size EHR vendor specializing in ambulatory care across the Southeastern United States. Their platform supported a network of independent practices built around strong clinical workflows, practice management, and billing integration. With the ONC patient access API requirements coming into effect, the engineering team needed to add FHIR R4 capability to a platform that had no existing FHIR infrastructure, within a fixed compliance timeline.
The client's integration architecture was built entirely on HL7 v2. It was production-stable and well-maintained, but not aligned with the RESTful, API-first data exchange model that ONC compliance required. The platform had no FHIR R4 server, no patient access endpoint, and no SMART on FHIR authentication layer.
The requirement was a fully ONC-compliant FHIR R4 patient access API, delivered within the compliance window, with no disruption to the HL7 v2 infrastructure in production.
The platform had no existing FHIR server, no patient-facing API endpoints, and no OAuth2 or SMART on FHIR authentication layer configured. Building these from scratch within the compliance window required specialist experience the internal team did not have.
All clinical data exchanges were handled through HL7 v2 message feeds. These feeds were reliable, but the data they carried needed to be transformed into FHIR R4 resources to meet the patient access API specification.
The ONC deadline was not movable. Under the 21st Century Cures Act, missing the patient access API requirement exposes health IT developers to information blocking penalties and puts practice networks at risk. Rebuilding architecture from scratch was not viable.
Nalashaa's interoperability team began with a structured discovery of the client's existing data architecture and HL7 v2 message types in production. The key finding shaped the entire approach: the existing HL7 infrastructure did not need to be replaced. A FHIR layer built on top of it was the right path.
01Azure API for FHIR was selected as the FHIR server for its managed infrastructure, built-in HIPAA-aligned data controls, and native SMART on FHIR support. It could be provisioned and configured significantly faster than a self-hosted alternative.
The client's existing ADT, ORU, and ORM message feeds were mapped to FHIR R4 resources covering Patient, Encounter, Observation, Practitioner, and Condition using Mirth Connect channels. This was built in parallel with server setup to stay on schedule.
OAuth2 with SMART on FHIR scopes was configured and validated before API endpoint development began, removing a common source of last-minute rework in FHIR projects.
Endpoints were validated against the Inferno FHIR test suite before deployment. Post-launch monitoring was configured through Azure Monitor to catch anomalies before clinical or operational impact.
The diagram above shows how six weeks was actually distributed. A few decisions drove the timeline:
Server setup and translation layer build ran in parallel from Week 1, the biggest lever on FHIR project timelines.
SMART on FHIR authentication was configured and tested before API endpoint development began.
The translation layer carried the most complexity, and API development was straightforward once mapping logic was validated.
The solution delivered a fully ONC-compliant patient access API built on the client's existing HL7 v2 infrastructure, with no disruption to live workflows.
Authentication was handled through SMART on FHIR from day one, enabling third-party consumer applications to connect in line with ONC requirements.
The translation layer gave the client a maintainable, configurable bridge between existing HL7 feeds and the FHIR API layer.
Configurations, mapping logic, and transformation rules were documented throughout delivery for long-term client independence.
In healthcare IT, where long-term vendor dependency is a common concern, this was a deliberate part of the delivery model.
Delivered within the compliance window, with all practices covered at launch and no information blocking exposure.
No changes were required to production message feeds, interface configurations, or practice-facing workflows.
Onboarding reduced from two to three days of HL7 configuration to approximately one day of credential setup and testing.
The FHIR infrastructure enabled an API access tier for enterprise clients that the platform could not previously support.
The most significant decision in this engagement was recognizing that the client did not need to replace their integration infrastructure. They needed a compliant layer built on top of it. That distinction kept the project on schedule and ensured delivery did not disrupt practices depending on the platform.
FHIR enablement does not have to mean starting over. For EHR vendors with stable HL7 v2 infrastructure, the right approach is to build forward from what works.
Cookies help us deliver our services. By using our services, you agree to our use of cookies Privacy Policy.
