Building a Unified Patient Platform with FHIR & EMPI Integration
Patient data lived in disconnected systems with no shared identity layer. Ideas2IT built the FHIR and EMPI foundation, then layered a unified web and mobile experience for appointments, records, payments, and care coordination on top of it.
Client
Multi-specialty healthcare
Industry
Healthcare
Service
App Development
App Modernization
Engagement
Greenfield build
Location
Illinois, USA
01 Challenge
The practice ran primary care, behavioral health, cardiology, and hospital medicine through separate tools with no shared patient identity. Appointment booking, records access, billing, and immunization reporting each required a different system, and none of them talked to each other.
02 Solution
Ideas2IT built the platform on a FHIR-native data layer, using Aidbox to store clinical and immunization data and an EMPI to resolve one patient identity across every touchpoint. HL7 v2 feeds from hospital systems were transformed into FHIR resources, with React web and React Native mobile apps built on top as the patient-facing surface.
03 Outcome
Patients now book appointments, access records, and pay for services through one application instead of several. Immunization data flows directly into Illinois's I-CARE registry, and identity resolution runs automatically across every integrated system.
Phase 01
Before the front end, the data had to resolve to one identity
Turning Fragmented HL7 Records Into One Resolvable Patient Identity
The first decision was structural: nothing else could be built until patient data resolved to a single identity across systems that had never shared one. Ideas2IT stood up Aidbox as the canonical FHIR data store and built a transformation pipeline converting incoming HL7 v2 feeds from the practice's existing hospital and EHR systems into FHIR resources.
An EMPI layer sat on top, matching patient records across every source system so that one patient looked like one patient everywhere, not a different record in every tool. EHR APIs were integrated directly into this foundation, giving every downstream feature, from appointment booking to immunization reporting, one data layer to build against instead of five.
This Phase Produced
- FHIR-native data store (Aidbox)
- HL7 v2-to-FHIR transformation pipeline
- EMPI patient identity resolution
- EHR API integration layer
Phase 02
Turning the data foundation into what patients and staff use daily
Operational Optimization: Mobile Apps, Payments, and Admin Tooling Built on One Data Layer
With identity resolution and FHIR data in place, the second phase built what patients and staff actually touch. React Native mobile apps for iOS and Android and a companion admin interface were built on top of the FHIR and EMPI foundation, giving patients appointment booking and giving staff a single place to manage service pricing and transactions.
Stripe was integrated directly against the practice's service catalog, so pricing changes and payment status updates flowed through one system instead of a manual reconciliation process across separate billing and scheduling tools. Workflow automation replaced several of the manual steps that had previously required staff to move information between systems by hand.
This Phase Produced
- React Native iOS and Android apps
- Admin service management interface
- Stripe payment gateway integration
- Service pricing and transaction management
- Workflow automation
Phase 03
Extending the platform to new services without touching the foundation
Service Expansion and Coordination: Adding Imaging, Home Care, and Transportation Without Rebuilding the Core
Because the identity and data layer had been built first, new service lines could be added without re-architecting anything underneath them. Ideas2IT extended the platform to cover imaging, home care, and transportation, integrating custom booking software into the same transaction and workflow systems built in Phase 2.
The platform also integrated with Illinois's I-CARE registry, so immunization records from the practice's vaccination programs synchronized directly into the state system instead of requiring separate manual reporting. Each new service plugged into the same EMPI and FHIR foundation, extending identity and data continuity across a wider set of care types rather than starting over for each one.
This Phase Produced
- Imaging, home care, and transportation service integration
- Custom booking software integration
- I-CARE Registry immunization sync
- Extended EMPI and FHIR coverage across new service lines
Phase 04
Designing for the services not yet on the roadmap
Scalable and Future-Ready: An Architecture Built to Take on the Next Service Line
The platform was not built to be finished. Every architectural decision, from the FHIR-native data layer to the modular integration pattern used for imaging, home care, and transportation, was made so the next service line could be added the same way as the last, without a platform rewrite.
The application layer runs on Azure with Kubernetes orchestration, giving the platform room to scale infrastructure independently of the services running on top of it. That separation between the data foundation, the service layer, and the infrastructure is what lets the practice keep adding capabilities without accumulating the fragmentation that made the previous set of tools unworkable in the first place.
This Phase Produced
- Azure and Kubernetes infrastructure
- Modular service integration pattern
- Scalable architecture for future service lines
The Outcome
One Platform Where the Practice Used to Run Five
The platform holds together because identity resolution came first. Every service added after the EMPI and FHIR foundation, from mobile booking to home care scheduling, inherited one patient record instead of creating another one. That sequencing, data layer before feature layer, is what let four service categories launch on one platform instead of becoming four more disconnected tools.