Why can't the hospital just change the system?
Outside healthcare, integration difficulty is mostly technical: protocols, formats, throughput, error handling.
Inside a hospital those are the easy part. The binding constraint is organisational. The system holding the data you need has been through validation, or certification, or a procurement that specified exactly what it does. Changing it means change control, sign off, possibly retesting, and a queue that was full before you arrived. At the end of that queue sits a person who will be answerable if a clinical system misbehaves after a change they approved.
This is not obstruction but the correct behaviour for an organisation running clinical systems, and a supplier who treats it as an obstacle to argue around will lose slowly.
The productive response is to design so that you ask for as little change as possible, (obviously, ideally none).
Quality teams look at the same problem from the other side, through the question of what does and does not sit inside a validated boundary. This article is the engineering half of that conversation.
Where does the seam fall?
Before choosing a pattern, answer one question precisely: what does this integration require the source system to do differently?
The top two rows are where you want to be. Most teams do not start there, because they design the integration they want and discover the price afterwards.
Which of the five patterns should you use?
1. Consume only, from what already flows
What it is? Basicaly, you subscribe to an interface the source already produces, such as an existing message feed, export or replica.
Footprint: none.
When it works? More often than teams expect. Hospitals typically emit more than outsiders assume, because another system needed that data before you arrived.
But there are some limitation eg. you get what the feed carries. If your requirement is not in it, this pattern does not stretch.
Most of what you will find is HL7 v2, FHIR or DICOM, and it is worth knowing what each of those standards is actually for before you ask which one a hospital supports.
2. Adjacent service
The new capability lives beside the source system rather than inside it, with users moving between the two and sharing identity where possible.
Footprint: identity integration at most.
Best to use it when the capability is genuinely separable, such as a new pathway, a new user group, or a workflow that did not previously exist.
As always there are limitations for example two systems in the user's day. In a clinical setting that friction is not a rounding error, and it shows up in adoption numbers.
It is still usually the better trade than the alternative, since replacing the incumbent system tends to fail for reasons that have nothing to do with your software.
3. Translation boundary
It's a layer of your own that converts the source's model into yours, absorbing local variation, missing fields and inconsistencies.
Footprint: none on the source, substantial in your own codebase, deliberately.
When it works best? It's always worth it when the source has an upgrade cycle you do not control, which is every hospital system.
This is real engineering that delivers no visible feature. Budget for it explicitly or it will be cut.
4. Staging location
What it is? The source writes to somewhere it already has permission to write, such as a staging table, file drop or outbox, and you read from there.
Footprint: small, and of a kind that clears approval more easily than changing behaviour.
When it is usually used? When a small addition is achievable but modification is not, which is a common shape of the constraint.
Customers rarely offer this, because from where they sit it does not look like an integration option. Ask for it by name.
5. The interface engine as the seam
It's when the hospital's integration engine already sits between systems, so changes land there instead of in the clinical system.
Footprint: on the engine, not on the validated system, which is frequently the difference between an operational change and a project.
Limitation we can spot here: neither fact is visible from outside. Establish both early, because they move your estimate considerably.
What goes wrong later?
Building against an interface the customer then changes
You do not control their upgrade cycle. Version your expectations, detect drift, and fail loudly rather than silently.
Assuming a new feed is available
"Can you add these three fields" sounds small and can take two quarters, because it was never an engineering question. Design the first version against what exists and treat additional fields as a later increment. This is one of the main reasons integration estimates in regulated environments vary so widely.
Silent coupling
The source is upgraded, a field starts arriving empty instead of absent, nothing errors, and your data degrades quietly for weeks. Validate at the boundary and alert on shape changes, not only on failures.
The temporary direct database read
It is quick, it works, and it becomes permanent. It also couples you to an internal schema nobody promised to keep stable, and it is the arrangement most likely to be shut down once someone with authority notices.
What should you ask in the first conversation?
Four questions, before any architecture:
- What interfaces does this system already produce, and who consumes them today?
- Is there an integration engine, and who owns it?
- What is your change control process for this system, and what is the realistic timeline?
- What has a previous supplier asked for that you had to refuse?
The fourth is the one almost nobody asks. It gives you the shape of the constraint immediately, in the customer's own words, without anyone having to dig out a policy document.
What this means in practice
Design the first release against what already flows, even when it is less than you wanted. Ship that, then negotiate additions from a position where something is running and the customer can see it.
The alternative puts your timeline inside somebody else's change control queue before you have demonstrated anything.
That is how a single hospital deployment grew into more than two hundred on a platform we still run five years later, and it is the approach behind connecting QMS, ERP and EHR without replacing what is already in place.
