CASE STUDY · HEALTHCARE INTEROPERABILITY & DATA EXCHANGE
Building an HL7/FHIR data exchange layer for a hospital network.
- 66 interfaces consolidated behind a shared layer
- 18,000About 18,000 messages a month
- 99.9%99.9% availability in a 90-day pilot with 2 minor incidents
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised hospital network. Name withheld under confidentiality.
A central exchange layer with retry, audit logging and monitoring. The six interfaces now run behind it.
- 1Six point-to-point interfaces, each fragile and unmonitored, with an audit coming.
- 2Each feed had been built at a different time, by different people, and few staff understood all of them.
- 3When one failed, the first sign was a clinician asking why a result had not arrived.
- 4Nobody could show an auditor a clear record of what had moved where.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01One of the older interfaces sent messages that did not follow the format its documentation described
Our validation rejected them, and a result feed stalled. We caught it quickly because of the alerting, and fixed it by agreeing a tolerant parser for that sender with a log entry for each deviation, rather than loosening validation everywhere. We then added a sample-based test for each interface, built from real message shapes, to catch this before cutover.
- PROBLEM 02We then added a sample-based test for each interface, built from real message shapes, to catch this before cutover
03 · THE PROCESS
How we ran it.
- 01Inventory
We documented all six interfaces: sender, receiver, message types, volumes, owners and failure history.
- 02Design
We agreed a common message pipeline and a shared error-handling policy with the network's integration team.
- 03Migration
One interface at a time. Each ran in parallel with the old feed until outputs matched, then cut over with a rollback plan.
- 04Pilot
A 90-day run under monitoring, with weekly reviews of incidents and message volumes.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
The team sees one dashboard of interface health, not six silent feeds.
- NOW 02
Failed messages are queued and reviewed, not lost.
- NOW 03
Audit questions are answered from logs rather than from memory.
- NOW 04
Changes to an interface go through review and test, with a rollback path.
- 6
6 interfaces consolidated behind a shared layer
- 18,000
About 18,000 messages a month
- 99.9%
99.9% availability in a 90-day pilot with 2 minor incidents
05 · WHAT WE BUILT
How it works.
- A central engine receives, validates, transforms and routes HL7 and FHIR messages.
- Every message is stored with its status.Failed deliveries retry with back-off, and messages that still fail go to a dead-letter queue for review.
- Audit logging records each message's path, time and outcome, without exposing more patient data in logs than needed.
- Monitoring covers queue depth, latency, error rates and endpoint health, with alerts to the on-call engineer.
- Configuration is version-controlled, so each interface change is reviewed and reversible.
- Access to the engine and logs is role-based.
- Controls and handover
- Access to the engine, the message store and the logs is limited to named staff, and changes to configuration need a second reviewer. Logs hold message metadata and identifiers only where needed, and message content is retained for a limited period set by the network's own policy. We ran a failover test in a quiet window before the pilot ended, so the team had seen a restart with their own eyes.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Six point-to-point interfaces, each fragile and unmonitored, with an audit coming. Each feed had been built at a different time, by different people, and few staff understood all of them. When one failed, the first sign was a clinician asking why a result had not arrived. Nobody could show an auditor a clear record of what had moved where.
- What did Brandsmashers build?
- A central exchange layer with retry, audit logging and monitoring. The six interfaces now run behind it.
- What were the results?
- 6 interfaces consolidated behind a shared layer; about 18,000 messages a month; 99.9% availability in a 90-day pilot with 2 minor incidents.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
