Healthcare interoperability: build a measurable business case
How to choose an integration project, establish a baseline and measure operational value without assuming generic returns.
Ala Ben Aicha
Start with one workflow and its cost
Disconnected clinical systems can require staff to re-enter information, search for prior results or reconcile conflicting identifiers. Connecting them may help, but an interface alone does not establish a financial return or a clinical benefit. Build the case around a named workflow, an accountable owner and a measurable baseline.
For example, consider sending a laboratory result from the laboratory system into the receiving clinical record. Define when the result is ready, how the patient and order are identified, where the result appears and who handles an unmatched result. Measure this complete path before proposing a larger integration programme.
Record the baseline before implementation
| Question | Evidence to collect | What to avoid |
|---|---|---|
| How much manual work occurs? | Observed handling time and number of cases over a defined period | Treating all staff time as cash savings |
| Where do failures occur? | Rejected messages, unmatched identifiers and unresolved exceptions | Counting successful HTTP responses as completed clinical workflows |
| How quickly is information available? | Time between source approval and availability in the receiving workflow | Comparing different case types without adjustment |
| What is the operational cost? | Engineering, licences, support, hosting and staff review | Omitting ongoing maintenance |
| Who benefits? | Feedback from the people using and supporting the workflow | Assuming patient outcomes from technical uptime |
Keep operational measurements separate from clinical outcomes. Any clinical evaluation needs an appropriate protocol, governance and qualified reviewers.
Choose the smallest useful integration
Prioritize a workflow with a clear source of truth, stable identifiers and a receiving team willing to validate the result. A useful first delivery might be a single laboratory feed, admission event or document exchange. It need not replace the hospital's existing systems.
The HL7/FHIR integration guide describes capability and authorization checks. The ADT mapping guide shows why a patient identifier and a visit identifier require separate namespaces.
Define acceptance criteria before implementation: expected message types, mapping rules, acknowledgement behaviour, rejected-record handling, replay controls and the rollback procedure. Include the receiving application's behaviour, not just the middleware response.
Calculate value using local assumptions
Estimate the annual volume multiplied by the measured change in handling time. Report the assumptions and uncertainty. Released capacity is not automatically a budget reduction: it may instead support faster processing or a different allocation of work.
Subtract implementation and recurring costs. Test more than one scenario for message volume, exception rate and support effort. Do not use generic percentages for fewer duplicate tests, shorter stays or better clinical outcomes as if they were results of your project.
Treat regulatory work as a separate requirement
In the European Union, the EHDS introduces phased requirements for health-data access, exchange and relevant EHR systems. Applicability, priority data categories and implementation dates must be checked against the regulation and subsequent specifications. An implementation of FHIR alone does not establish EHDS conformity. Use the EHDS readiness guide to organize the evidence questions.
National rules, the organization's role and its data-processing arrangements still matter. A regulation should inform the requirements register; it should not be used to promise automatic product certification.
Review after release
Compare like-for-like periods and workflow groups. Review exception handling, support load and user feedback alongside throughput. Document adverse effects such as new reconciliation work or difficult recovery paths. Expand only after the first workflow is stable and its value is understood.
For a scoped integration review, discuss a project. Bring a workflow description, the systems involved and any baseline measurements already available.