Interoperability is usually scoped as an integration project: connect to the other system, map the fields, move the data. That framing treats the hard part as solved once the connection works.
The hard part starts afterwards. Two systems now hold overlapping information about the same person, recorded at different times, by different people, under different assumptions. What the product does with that disagreement is a design decision, and users experience it directly.
Identity is the first problem, not a detail
The same person appears under different identifiers in different systems, with names spelled differently, dates of birth transposed and addresses years out of date. Matching them is probabilistic, and probabilistic matching has two failure modes with very different consequences: failing to link records that belong together, and merging records that do not.
Decide who owns each fact
When two systems hold a different address, one of them is authoritative for that field — or the product must present both with their provenance. What does not work is silently picking the most recent value and displaying it without context, because users will make decisions on it without knowing there was a conflict.
Ownership is usually per field rather than per record. A scheduling system may own appointments while a registration system owns demographics. Writing that down is unglamorous and prevents a category of incident.
Late and out-of-order data is normal
Results arrive after the encounter they belong to. Amendments arrive after the original. A system that assumes ordered arrival will eventually display a superseded value as current. Model event time separately from arrival time, and design what the interface does when something arrives that changes a conclusion someone already acted on.
Surface uncertainty rather than hiding it
The instinct is to present a clean, unified view — one record, one truth. That is the right goal when the data supports it and a misleading one when it does not. Where information is unconfirmed, conflicting, or from an external source that has not been reconciled, say so. Clinicians and administrators are experienced at working with incomplete information; they are poorly served by software that hides which parts are uncertain.
- Show the source and the timestamp for externally supplied information
- Mark conflicts visibly instead of silently resolving them
- Distinguish "no data" from "data not yet received" from "confirmed absent"
- Make reconciliation an ordinary workflow with a clear owner, not an exception process
Standards help; they do not decide
Standards-based exchange gives you shared structure and vocabulary, which is real value. It does not tell you which system wins a conflict, how confident a match must be before it is applied, or what a user sees when the record is incomplete. Those remain product decisions, and they are the ones users actually notice.
Test the messy middle
Integration test suites tend to cover well-formed messages. The valuable tests are the other ones: duplicate identities, partial records, contradictory updates, out-of-order arrival, missing mandatory fields, and the upstream system returning success while doing nothing. Those are the conditions that determine whether the product is trusted.