Loading field map
Every time a patient moves from a clinic to a hospital to a pharmacy, their clinical data must travel with them—but the systems that hold that data rarely speak the same language. Health data standards are the agreements that make such exchange possible: shared vocabularies, message formats, document structures, and integration patterns that allow one system to interpret another's output. Since the 1960s, the field has developed five major frameworks, each responding to a specific limitation in what came before. The result is not a simple succession of replacements but a layered ecosystem in which older standards continue to serve alongside newer ones, each optimized for a different kind of interoperability.
The earliest health data standards were classification systems designed to bring order to medical records for statistical and administrative purposes. The International Classification of Diseases (ICD) provided a hierarchical set of codes for diagnoses and procedures, enabling mortality tracking and later hospital reimbursement. SNOMED CT, by contrast, offered a far more granular vocabulary for clinical concepts, supporting detailed documentation rather than aggregation. The tension between these two goals—aggregation for counting versus precision for clinical care—remains a defining feature of the field. Unlike later messaging standards that focus on how to send data, classification systems focus on what the data means, assigning codes so that information can be compared across institutions and over time. They continue to underpin billing, epidemiology, and quality reporting, even as newer frameworks handle the mechanics of exchange.
Where classification systems define vocabularies, messaging standards define how to package and transmit those codes between systems. Health Level Seven (HL7) version 2, introduced in the late 1980s, became the de facto standard for hospital data exchange. Its pragmatic, pipe-delimited format allowed rapid adoption, but its flexibility also led to inconsistent implementations—the same message type could be interpreted differently by different vendors. HL7 version 3 attempted to solve this by imposing a rigorous Reference Information Model (RIM) that forced all messages to conform to a single logical structure. The ambition was admirable, but the complexity proved overwhelming; v3 was difficult to implement and never achieved widespread adoption. This failure became a cautionary tale for the entire field, demonstrating that a standard too rigid to deploy can be as problematic as one too loose to guarantee interoperability. The lesson directly influenced the design of later frameworks, which sought a middle ground between rigor and deployability.
The document-centric approach emerged from the recognition that clinical data is often best understood as a narrative document—a discharge summary, a lab report, a progress note—rather than a stream of discrete messages. The HL7 Clinical Document Architecture (CDA) wrapped clinical content in XML headers for metadata (patient, author, encounter) while leaving the body flexible, allowing free text or structured entries. This was a compromise between the rigidity of v3 messaging and the unstructured nature of paper records. Around the same time, the openEHR specification took a different path: two-level modeling that separated a stable reference model (the fixed framework of data types and structures) from flexible archetypes (clinician-defined templates for specific clinical concepts). openEHR's archetype mechanism was a direct response to the inflexibility of HL7 v3's single-model approach, allowing clinical knowledge to evolve without breaking the underlying system. Both CDA and openEHR remain in use, with CDA favored for legal records and summaries in many countries, and openEHR adopted in national health systems such as those of the UK and Brazil.
Even when standards like HL7 v2 and CDA existed, vendors implemented them differently, so systems still could not reliably talk to each other. IHE addressed this coordination problem not by inventing new standards but by orchestrating existing ones into integration profiles. Each profile specifies exactly which standards to use, in which order, and with which constraints for a particular clinical workflow—such as sharing a radiology image or reconciling a medication list. The Connectathon events, where vendors test their implementations against each other in a controlled setting, became a hallmark of IHE's approach. IHE thus acts as a meta-standard, layering process agreements on top of the earlier messaging and document frameworks. It does not replace them; rather, it makes them work together in practice. Later, IHE profiles began incorporating FHIR as a transport layer, demonstrating how the coordination framework adapts to newer standards.
FHIR represents a fundamental shift from document- and message-based exchange to discrete, web-friendly resources. Each clinical concept—a patient, an observation, a medication—is modeled as a resource with a standard JSON or XML representation, accessible via RESTful APIs. FHIR learned from the failures of HL7 v3 by keeping the core model simple and allowing extensions and profiles for local needs, much like openEHR's archetypes but with a lighter, more developer-friendly touch. The framework also embraced modern web technologies (HTTP, OAuth, JSON) that lowered the barrier for software developers outside the traditional health IT world. Government mandates, such as the US 21st Century Cures Act, accelerated FHIR adoption by requiring healthcare providers to offer API access to patient data. Today, FHIR is the leading framework for patient-facing apps, health information exchanges, and interoperability initiatives worldwide. It does not, however, render earlier frameworks obsolete; classification systems still feed its coding fields, messaging standards still carry legacy traffic, and IHE profiles often specify FHIR as the transport for new workflows.
All five frameworks remain active today, each serving a distinct role. Classification and coding systems provide the semantic foundation for billing, analytics, and clinical decision support. Messaging standards still handle the bulk of real-time hospital-to-hospital transactions. Document-centric standards preserve the clinical narrative for legal and summary purposes. IHE profiles coordinate these standards into reliable workflows. FHIR leads the way for modern, web-based interoperability, especially where patient access and app integration are priorities. The major unresolved tension is between document-level and discrete-data approaches: CDA and openEHR preserve the richness of the clinical narrative, while FHIR favors granular, queryable data that can be recomposed on the fly. The field continues to grapple with the trade-off between rigor and flexibility that has driven every new standard since the 1960s. What the leading frameworks agree on is that no single standard can do everything; the future lies in understanding how they complement each other.