Healthcare interoperability: connecting data to the care pathway

For a piece of data to change anything in patient care, five questions need an answer, from the system that sends it to the one that receives it.

The first three are a matter of standards and frameworks. The last two are often overlooked: provenance, which tells you how much to trust the value, and workflow, which tells you who reads it and how quickly. A project that stops at the first three delivers a technically correct feed that nobody uses.

A project should not start with “implement FHIR” but with a situation: retrieving a discharge summary after a hospital stay, updating the medication list, sending a measurement to the clinician in charge of follow-up, gathering the documents for a second medical opinion.

For each one, describe the people involved, the triggering events, the minimum data set, the time frames and the expected decisions. This mapping shows what is essential and which exceptions to plan for. Above all, it keeps you from building a rich feed that nobody can use.

With MyTwin for clinicians, the patient’s digital twin is built from the medical record, test results, imaging and treatments, and a practice can either use the MyTwin follow-up app or embed the modules it chooses in its own tools. The same scenarios then apply: creating the patient, importing documents, matching identities, raising an alert, writing back to the source system. MyTwin makes recommendations; the clinical decision stays with the clinician.

Accurate data attached to the wrong person becomes dangerous. Identity matching has to handle duplicates, people with the same name, changes of legal name and incomplete records.

Some countries settle this with a national reference identity. In France, since 1 January 2021, every patient must be referenced by their national health identity (Identité nationale de santé, INS), which combines an identification number with five identity attributes: birth surname, first name(s) at birth, date of birth, sex and place of birth, as the Hauts-de-France regional health agency explains. Wherever you operate, the principle holds: a system that joins the care pathway should receive, keep and pass on the reference identity your health system defines, rather than rebuild one from a name and a date of birth.

Provenance is what makes data trustworthy

Every piece of information should keep its author, source system, date, version, method and status. A value reported by the patient, a reading from a wearable and a result validated by a laboratory do not carry the same level of confidence. Merging them without labels takes away what lets clinicians weigh them.

The number “5” means nothing without a unit, a type of measurement and a context. Terminologies, value sets and profiles form the shared grammar that gives it meaning. That is what national frameworks such as the French CI-SIS do: they gather the specifications for the information to exchange, name the most suitable standard for each exchange and the vocabulary to code it with, building on the international work of IHE, HL7 and DICOM.

HL7 FHIR is a standard for exchanging healthcare data, organized into resources and usable through APIs, among other approaches. It does not solve everything on its own, and the French agency states it plainly: FHIR is not interoperable out of the box. Designed for as many use cases as possible, it makes almost no field mandatory, places almost no constraint on terminologies and allows extensions. Hence national profiles, FR Core in France, and implementation guides per use case, which the ANS requires FHIR developments in France to build on.

Two FHIR implementations can therefore choose different versions, profiles or extensions. Implementation guides and conformance testing remain essential, wherever you deploy.

A bulk integration can flood the record with duplicates, results unrelated to the clinical question and notifications. Set a selection policy: which data, for what use, how often, kept for how long?

With health wearables, storing every heartbeat is rarely necessary. A summary can be enough, as long as the source measurement remains accessible when something needs investigating. It is the principle behind our article on real-world data: value comes from the decision the data informs, not from its volume.

A technically successful feed fails if nobody knows who should look at it. Before going live, define:

• the role that receives it;
• the time frame for acting on it;
• the escalation criteria;
• the trace left in the record;
• what happens during an outage;
• how the patient can report an error.

The alert chain itself, from thresholds to the team’s response, is covered in our guide to remote patient monitoring. Then test the unusual cases: unknown patient, missing code, unexpected unit, corrected document, revoked access, merged duplicates. These tests involve end users, not just technical teams.

Governance and security

Map out data controllers, processors, purposes and retention periods. Check access rights, logging, encryption, service continuity, reversibility and incident management. Interoperability multiplies data flows: it should also make them more visible.

In Europe, the framework is also becoming shared. The European Health Data Space regulation, in force since 26 March 2025, phases in cross-border exchange: patient summaries and ePrescriptions from March 2029, then medical images, lab results and hospital discharge reports from March 2031. The ANS states that this European framework will be incorporated into the CI-SIS. Track these deadlines rather than assume every capability is available today.

Track indicators tied to the care pathway, not just to transport:

• the rate of correct automatic identity matches;
• duplicates created and messages rejected;
• data received without a unit;
• how long information takes to arrive;
• documents corrected after the fact;
• undelivered alerts;
• time saved, or added, for the team.

A target of “100% of messages delivered” is not enough. You need to check that the information is understandable, visible in the right place and used when the protocol calls for it.