Health Data Portability Is a Clinical Problem, Not an IT Problem
Health Data Portability Is a Clinical Problem, Not an IT Problem
Health Data Portability Is a Clinical Problem, Not an IT Problem
We have spent two decades building interoperability standards for health data. HL7v2 has been in use since the 1990s. C-CDA was supposed to give us structured, portable clinical documents. FHIR R4 promises RESTful APIs that let systems exchange discrete data elements. On paper, the problem is solved.
In practice, a patient transferring from an Epic hospital to a MEDITECH hospital in the same city will lose clinically relevant information. We have both seen this happen, and the reasons are worth examining.
Where the standards break down
FHIR R4 defines resources: Patient, Condition, MedicationRequest, Observation, and dozens more. Each resource has required fields and optional fields. The optional fields are where the problems start. One system records a medication's route of administration. Another does not. One codes a diagnosis with ICD-10-CA and includes the date of onset. Another codes it with SNOMED CT and omits the onset date. Both are FHIR-compliant. Neither is complete from the other's perspective.
C-CDA documents have a related problem. The standard permits enormous variability in how sections are populated. A discharge summary from Epic might include a detailed medication reconciliation section. The same document type from an older MEDITECH installation might include only a free-text medication list with no structured coding. The receiving system gets what the sender chose to include, which is often less than what a clinician needs.
HL7v2 messages, still the backbone of lab and ADT feeds in Canadian hospitals, were designed for point-to-point interfaces. Every interface is custom-built by an integration analyst mapping fields between systems. When a hospital replaces its lab information system, dozens of HL7v2 interfaces break. This is routine, expensive, and clinically disruptive.
Two provincial examples
Ontario's ConnectingOntario Clinical Viewer aggregates data from hospitals, community labs, and some primary care EMRs into a read-only viewer. It works reasonably well. A physician in an Ontario ED can pull up recent lab results and discharge summaries from other facilities. The limitation is that it is view-only. The data cannot be imported into the local EMR as discrete, structured information. A physician still has to manually re-enter a medication list or copy-paste a diagnosis.
BC's CareConnect, operated by Provincial Health Services Authority, pulls data from health authority systems into a provincial view. Coverage is inconsistent. Community-based specialists and private clinics are unevenly represented. A patient who sees a psychiatrist in private practice and then presents to a Fraser Health ED may have no psychiatric history visible in CareConnect at all.
The clinical cost
Medication reconciliation at transitions of care is where data portability failures cause direct harm. Almanasreh et al. (2022) found that medication discrepancies at hospital admission occurred in over 50% of patients, and roughly a third were clinically significant. The root cause was usually incomplete or inaccessible medication data from other providers.
We think the framing of interoperability as an IT project is part of why progress has been slow. When the problem sits with the CIO's office, solutions get evaluated on technical compliance: "Does our system support FHIR R4? Yes. Check." The question that matters clinically is different: "When a patient arrives at our ED from another facility, can the treating physician access a complete, structured medication list within five minutes?" In most Canadian settings, the answer is no.
Solving this requires clinical leadership at the standards-setting level. Physicians and pharmacists need to define the minimum viable data set for safe care transitions, and that data set needs to be mandatory in whatever standard carries it. FHIR R4 is flexible enough. The missing piece is governance that compels systems to populate the fields that matter.