Loading field map
Health data standards are the formal agreements, specifications, and conventions that determine how health information is structured, encoded, transmitted, and interpreted between systems, organizations, and over time. The subfield of health data standards sits within health informatics, the discipline concerned with the acquisition, storage, retrieval, and use of information in healthcare. Its central task is not merely to create technical formats, but to solve a fundamental coordination problem: healthcare is delivered by many independent actors—clinicians, laboratories, pharmacies, insurers, public health agencies, and patients—who must share information accurately despite using different software, vocabularies, and workflows. Without shared standards, a laboratory result, a medication order, or a diagnosis recorded in one system may be meaningless, ambiguous, or dangerously misinterpreted in another.
The stakes are high. Errors in data exchange can lead to wrong treatments, duplicate testing, or missed allergies. Inefficient exchange wastes time and money. And the absence of interoperable data blocks the large-scale analyses needed for research, quality improvement, and public health surveillance. Health data standards are therefore not a purely technical niche; they are the infrastructure that makes a learning health system possible, where data generated in care can be reused for knowledge and fed back into better care.
To understand the field, one must first distinguish two related but distinct challenges. Syntactic interoperability concerns the format and structure of messages—whether a system can parse the data at all. Semantic interoperability concerns meaning—whether the receiving system interprets the data the same way the sending system intended. A standard that defines a message format but not the meaning of its contents achieves only the first. A standard that defines meanings but not how to package them achieves only the second. Most of the field's history can be read as a progressive realization that both are necessary, and that the harder problem is semantic.
A related distinction is between structure and content. Structure standards define the organization of data—the fields, sections, and relationships among them. Content standards define the allowable values, codes, or terms that can fill those fields. For example, a structure standard might specify that a medication order must include a drug name, dose, route, and frequency. A content standard specifies that the drug name must be drawn from a particular vocabulary, such as RxNorm, and that the dose must be expressed in a particular unit system. Both are needed; a well-structured message full of ambiguous codes is as useless as a well-coded message in an unparseable format.
The field is not organized around a single paradigm but around several distinct traditions that emerged at different times to solve different problems. These traditions now coexist and increasingly converge, though each retains its own logic, standards bodies, and legacy systems.
The oldest and most established tradition centers on the exchange of discrete messages between systems. Its origins lie in the 1970s and 1980s, when hospitals and laboratories began computerizing and needed to send results, orders, and billing information to each other. The dominant standard in this tradition is Health Level Seven (HL7), whose name refers to the seventh layer of the Open Systems Interconnection model—the application layer, where meaning is negotiated. The first HL7 standard, known as HL7 Version 2 (HL7 v2), was developed in the late 1980s and became the de facto standard for clinical messaging in North America and much of the world.
HL7 v2 is a pipe-and-caret-delimited text format that defines message types (such as admission, discharge, transfer, or laboratory result) and segments within those messages. Its great virtue is simplicity and flexibility: it is easy to implement, and it allows local customization through "Z-segments" and user-defined tables. Its great vice is that this flexibility undermines interoperability. Two systems may both claim HL7 v2 compliance yet use different local codes for the same concept, or place data in different optional fields. The standard guarantees a common envelope, not a common meaning.
The successor, HL7 Version 3 (HL7 v3), was an ambitious attempt to fix this by building messages from a rigorous Reference Information Model (RIM)—a large object-oriented model of the healthcare domain—and by requiring the use of standardized vocabularies. The theory was that if every message was derived from the same underlying model and used the same codes, semantic interoperability would follow. In practice, HL7 v3 proved extremely complex, slow to develop, and difficult to implement. It achieved significant adoption in some national programs, notably in the Netherlands and Canada, but never displaced v2 in the broader market. Its most important legacy is not the standard itself but the lesson it taught: that formal modeling alone does not solve the human and organizational problems of interoperability.
A more recent development in this tradition is Fast Healthcare Interoperability Resources (FHIR), also from HL7. FHIR, first published in the early 2010s, combines elements of its predecessors with modern web technologies. It defines discrete "resources" (such as Patient, Observation, MedicationRequest) that can be exchanged as JSON or XML and accessed via RESTful web services. FHIR is deliberately modular: implementers can use only the resources they need, and the standard provides extension mechanisms for local needs. It has gained rapid adoption because it is easier to implement than v3, more modern than v2, and well suited to mobile apps and web-based platforms. FHIR does not, by itself, solve semantic interoperability—it still relies on external vocabularies and profiles to constrain meaning—but it provides a much more flexible and accessible foundation than its predecessors.
A second tradition, historically separate from messaging, concerns the standardization of clinical meaning itself. This tradition has its roots in nosology—the classification of diseases—which dates back to the 18th century. The modern era began with the International Classification of Diseases (ICD), first published in 1893 as the International List of Causes of Death and later expanded to include morbidity. ICD is maintained by the World Health Organization and is used worldwide for mortality statistics, morbidity coding, and, crucially, for reimbursement in many countries. Its codes are hierarchical: chapters for body systems, then blocks, then three-character categories, then optional fourth and fifth characters for detail.
ICD's strength is its global reach and its fit for statistical and administrative purposes. Its weakness is clinical granularity. A code like "E11.9" (Type 2 diabetes mellitus without complications) tells a statistician what it needs but tells a clinician almost nothing about the patient's actual condition. This gap led to the development of clinical terminologies designed for point-of-care documentation.
The most influential of these is the Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT), which grew out of the College of American Pathologists' SNOMED and was merged with the UK's Clinical Terms (Read Codes) in the early 2000s. SNOMED CT is a large, polyhierarchical ontology of clinical concepts—over 300,000 active concepts—linked by relationships such as "is a," "finding site," and "causative agent." Its design goal is to represent clinical meaning with enough precision to support decision support, research, and care documentation. Unlike ICD, SNOMED CT is not organized for counting; it is organized for describing.
The relationship between ICD and SNOMED CT illustrates a key tension in the field. They serve different purposes—one for statistics and payment, the other for clinical care—and they are not interchangeable. A diagnosis recorded in SNOMED CT must be mapped to ICD for billing or public health reporting, and these mappings are imperfect. The field has developed a whole sub-specialty of terminology mapping and cross-walking, with its own standards and tools, precisely because no single terminology serves all purposes.
Other important terminologies address specific domains. LOINC (Logical Observation Identifiers Names and Codes) provides codes for laboratory tests and clinical observations, distinguishing, for example, a serum glucose measured in mg/dL from one measured in mmol/L. RxNorm, from the U.S. National Library of Medicine, normalizes drug names to their active ingredients, strengths, and dose forms. The International Classification of Functioning, Disability and Health (ICF) covers function and disability. Each of these fills a niche that general-purpose terminologies do not cover well.
A third tradition focuses not on discrete messages or individual concepts but on the structure of clinical documents as wholes. Its central standard is the Clinical Document Architecture (CDA), also from HL7. CDA specifies the structure of a clinical document—such as a discharge summary, progress note, or lab report—as a header containing metadata (patient, author, encounter, purpose) and a body containing the clinical content. The body can be structured to varying degrees, from free text to fully coded entries.
CDA's key innovation is its "levels" of structure. A Level 1 document is essentially a human-readable text with a standardized header. A Level 2 document adds section-level structure, so that, for example, the "Medications" section can be identified and processed. A Level 3 document encodes individual entries within sections, such as each medication with its codes and attributes. This graduated approach allows implementers to choose how much structure they need, and it acknowledges a reality of healthcare documentation: much clinical information is inherently narrative and resists full codification.
The document tradition also includes the Continuity of Care Document (CCD), a CDA-based format for summarizing a patient's health status, and the Continuity of Care Record (CCR), an earlier standard from a different body that CCD largely absorbed. These summary documents are central to care transitions—when a patient moves from hospital to home, or from one provider to another—because they package the essential information in a single exchangeable artifact.
A fourth tradition, less visible in operational systems but influential in research and in some national programs, focuses on defining stable data models that can accommodate local variation. The most prominent expression is the openEHR approach, developed from the work of the European GEHR (Good European Health Record) project in the 1990s. openEHR separates the reference model—a small, stable set of classes that define the basic types of data (entries, compositions, sections) and their attributes—from archetypes, which are formal, machine-readable definitions of the structure of specific clinical concepts, such as a blood pressure measurement or a medication order.
The insight of this approach is that the reference model can remain stable while archetypes evolve to capture new clinical knowledge. Clinicians and domain experts can author archetypes without needing to understand the underlying model, and different systems can exchange data if they share the same archetypes. This is a fundamentally different strategy from HL7 v3, which tried to model the entire domain in advance. openEHR accepts that clinical knowledge changes and distributes the modeling task to the community. Its influence has grown in recent years, particularly in national health record programs in Europe and Latin America, though it remains less widely deployed than HL7 standards.
These four traditions are not rivals in the way that competing scientific theories are rivals. They solve different problems, and a complete health data infrastructure typically uses several of them together. A typical hospital might use HL7 v2 or FHIR to exchange messages with its laboratory, SNOMED CT to code diagnoses in the electronic health record, LOINC to code the lab tests themselves, ICD-10 to generate billing codes, and CDA or FHIR documents to send discharge summaries to primary care. The traditions are complementary layers in a stack, and much of the field's practical work is about integrating them.
There are, however, genuine disagreements about the best path forward. The most active debate concerns the relationship between FHIR and the older standards. Some see FHIR as the eventual successor to both HL7 v2 and CDA, a single modern standard that can handle messaging, documents, and APIs. Others argue that FHIR's flexibility recreates the semantic interoperability problem of v2—that by allowing so many options, it permits systems to be "FHIR-compliant" while meaning different things. The response to this concern has been the development of FHIR profiles and implementation guides, which constrain the base standard for specific use cases. Whether this constraint mechanism will be sufficient is an open question.
A second debate concerns the role of formal ontologies. The SNOMED CT approach assumes that a large, centrally maintained terminology can represent clinical meaning adequately. Critics point out that clinical language is inherently context-dependent and that no fixed terminology can capture all the nuances of patient care. Some advocate for more flexible, natural-language-based approaches, while others argue for even more formal logic-based ontologies. This debate is unlikely to be resolved; it reflects a fundamental tension between the need for standardization and the complexity of clinical reality.
Several features of the current landscape are likely to persist. First, the field is increasingly international, but not uniform. Different countries have made different choices: the United States has promoted FHIR through federal regulation, the United Kingdom has invested heavily in SNOMED CT, Germany has pursued a national health record infrastructure based on HL7 and FHIR, and several Nordic countries have adopted openEHR-based national records. These national choices create path dependencies that shape what is possible for years.
Second, the rise of application programming interfaces (APIs) and the FHIR standard has shifted the field's center of gravity from message-based exchange to service-based access. The U.S. information-blocking rules, which require certified health IT to expose FHIR APIs, have made API-based interoperability a legal requirement in that country. This shift matters because APIs enable a different model of data sharing: instead of sending copies of data, systems can query other systems in real time, which changes the security, consent, and data-governance landscape.
Third, the field is grappling with new kinds of data that do not fit neatly into traditional structures. Genomic data, patient-generated data from wearables, social determinants of health, and free-text clinical notes all resist the tidy categories of terminologies and message formats. The field is responding with new standards for genomics (such as HL7 FHIR Genomics), with efforts to standardize patient-reported outcomes, and with increasing attention to natural language processing as a complement to structured coding.
Fourth, the governance of standards has become more complex. Standards are developed by multiple bodies—HL7 International, the International Organization for Standardization (ISO), the World Health Organization, national standards organizations, and increasingly by private consortia and open-source communities. The relationships among these bodies are sometimes cooperative, sometimes competitive, and sometimes duplicative. The result is a landscape in which no single authority can mandate interoperability, and progress depends on negotiation, market pressure, and regulation.
Finally, the field's ultimate test is not technical but practical. A standard is only as good as its implementation, and the history of health data standards is full of well-designed standards that failed because they were too complex, too rigid, or too disconnected from clinical workflows. The durable lesson of the field is that interoperability is a sociotechnical problem: it requires not only good technical specifications but also training, governance, incentives, and a willingness to compromise. The standards that endure are those that respect the messy realities of healthcare while still pushing toward the goal of making information flow reliably and meaningfully.