Healthcare integration rarely fails because two systems cannot technically exchange a message.
It fails in the gaps around that exchange: the wrong data arriving at the wrong point in the workflow, unclear system ownership, identifiers that do not reconcile, exceptions nobody designed for, an API that worked perfectly in a sandbox but does not solve the production use case, or an interface that is technically green while the clinical process around it remains broken.
I advise health systems and health-tech companies on the architecture behind those problems: FHIR, HL7, APIs, clinical data flows and the operating workflows they are meant to support.
Technology-agnostic. Architecture first. Implementation grounded in what actually has to work on a live clinical floor.
Years of point-to-point integrations can leave an organisation with something that technically works but is increasingly difficult to understand, govern and change.
A new digital platform gets added. Then a mobile application. Then a national exchange. Then AI. Each project solves its own connectivity problem and the architecture becomes the accumulated result of individual decisions.
The question is not simply whether FHIR or HL7 is available.
It is how information should move across the organisation, which platform owns it, which workflow consumes it, how failures are handled, and what should happen next when the data arrives.
An EHR exposing FHIR APIs does not mean the organisation has an interoperability strategy.
The useful questions are which resources are available, what the vendor implementation actually supports, how authentication and context will work, what needs to remain HL7, what requires another integration pattern, and whether the API supports the workflow being designed.
A standards-compliant architecture can still be operationally wrong.
HL7 remains embedded across hospital environments for good reason.
Laboratory, radiology, pharmacy, ADT, orders, results, billing and device workflows often depend on it. Reliability is not simply message delivery. It is understanding acknowledgements, sequencing, transformations, retries, exception handling and what happens clinically when the expected event does not occur.
The most important architecture diagram is sometimes the one showing what the clinician, patient or operational team is trying to do.
The data flow comes after that.
Assess the current integration landscape, data flows, interface patterns, dependencies and ownership boundaries.
The objective is to identify where complexity is necessary, where it is accidental, and which integration decisions are creating operational risk or blocking future digital programmes.
Outcome: A clear current state and a prioritised architecture roadmap.
Map the use case to the actual API capability rather than starting with the standard.
That includes resource and endpoint assessment, data ownership, authentication approach, patient and encounter context, workflow fit, integration boundaries and where FHIR should or should not be the chosen pattern.
Outcome: An implementation design developers can work from, with fewer surprises between sandbox and production.
Review interface patterns across clinical and operational systems, identify failure points, map message and acknowledgement flows, and establish where reliability or data-quality problems originate.
The work can cover laboratory, radiology, pharmacy, medical devices, revenue cycle and other clinical interfaces.
Outcome: The underlying problem identified before another workaround is added.
Map what happens beyond the interface.
Where does the information originate? Who owns it? Which system is authoritative? What action should it trigger? What happens if it is late, incomplete or wrong? Who knows that something has failed?
Those questions turn integration from plumbing into operating architecture.
For organisations with multiple digital programmes competing for integration capacity.
Prioritise the architecture, establish patterns, define ownership, sequence dependencies and create a roadmap that internal teams and implementation partners can execute.
The aim is not to centralise every technical decision. It is to stop every project making a new one independently.
A FHIR-enabled digital platform can look like a patient-experience project.
Operationally, it touches identity, scheduling, clinical data, CRM, contact centre, patient access and the EHR.
In one live environment, a FHIR-enabled digital platform contributed to an AED 3M+ monthly increase in bookings without replacing the underlying EMR.
The value did not come from FHIR itself.
It came from designing the workflow around what the integration made possible.
That distinction matters.
The work has included integration architecture across Oracle Health environments, HL7 clinical interfaces, FHIR APIs, laboratory systems, PACS and radiology, pharmacy workflows, medical devices and digital patient platforms.
It also includes sitting on the hospital side when these integrations fail.
That changes the questions.
Not only: did the message send?
But: did the result arrive in the right workflow, did anyone act on it, can we see when it fails, and can the organisation operate safely when one part of the architecture is unavailable?
For organisations running Oracle Health / Cerner Millennium, the platform-specific integration depth remains on the Oracle Health advisory side of the practice.
That includes Oracle Health HL7 architecture, FHIR endpoint mapping, laboratory, PACS, pharmacy and medical-device integration strategy.
The interoperability advisory here is broader: the architecture between systems regardless of which EMR sits at the centre.
A product can have a clean FHIR implementation and still be difficult for a hospital to deploy.
Security review, identity, workflow, EHR constraints, interface capacity, clinical governance and ownership all sit around the technical integration.
For health-tech companies, I can review the proposed integration architecture from the hospital side before the hospital has to explain why it will not work in its current form.
The startup advisory practice takes that further into deployment and enterprise scaling.
I design integration architecture, map data flows, identify endpoints, challenge implementation patterns and troubleshoot where failures are coming from.
Your developers, integration team or implementation partner can then execute against that architecture. Where needed, I can work alongside them or bring in specialist implementation capability.
That boundary is intentional.
It keeps the recommendation independent of how many interfaces somebody gets paid to build.
Whether you are designing a new interoperability architecture, trying to make sense of an existing one, bringing a digital product into the clinical environment or working through a FHIR or HL7 problem that has stopped being purely technical, let's have a conversation.
Thank you. Your message has been sent.
You will hear back directly, usually within a couple of days.
Prefer email? rajiv.ganapathy@nirvaanadvisory.com