Efficient healthcare data management relies on two fundamental components: terminology and information models. Although distinct in their functions, these elements work together to organize and structure healthcare data, enabling seamless communication, decision-making, and interoperability across healthcare systems.
Terminologies, such as SNOMED CT and other classifications, serve as standardized vocabularies for representing medical concepts and entities. They excel at answering questions related to "What, how, and why?" by precisely defining and categorizing types (classes) of diseases, symptoms, signs, procedures, body structures, morphologies, substances, drugs, devices, organisms, and objects. By providing a common language for healthcare professionals, terminologies ensure semantic consistency and support accurate documentation and retrieval of patient information.
Information models, such as HL7 FHIR and openEHR, provide the structural framework for organizing and representing healthcare data. They focus on addressing questions related to "Who, when, and where?" by capturing temporal aspects (dates, times, durations), quantities, textual information, and about specific individual instances of people, organizations, and places involved in healthcare processes. Information models define the relationships, constraints, and attributes of data entities, enabling interoperability, data exchange, and integration across diverse healthcare systems and settings.
While terminology and information models serve distinct purposes, there is significant overlap in their functionalities, particularly in the representation of clinical situations and contexts. Some terminologies like SNOMED CT and many information models capture clinical statuses, such as the presence, absence, or uncertainty of medical conditions, as well as document family history, past medical history, and the status of requested, planned, or completed procedures.
However, managing the complexity of overlapping data representations can present challenges. Inconsistent mapping between terminologies and information models, variations in data interpretation, and discrepancies in data capture practices can lead to semantic interoperability issues and hinder the seamless exchange and integration of healthcare data.
Addressing these challenges through standardized approaches, semantic mapping, and interoperability initiatives is essential for healthcare organizations to ensure interoperability and effectively leverage the full potential of healthcare data.
Electronic Health Records (EHRs) use diverse data entry models to support various clinical use cases. Each model has specific terminology and information structure requirements. To ensure the captured information is interoperable and meaningful beyond its initial use, it is essential to design a comprehensive context representation model.
Accurate interpretation depends on how each sentence is phrased.
Ignoring any part of the text may lead to misinterpretation.
Computerized processing may be possible using Natural Language Processing (NLP), sometimes generating structured coded data for reporting and analysis.
Note after investigation
Interpretation depends on section headings and terms/phrases under each heading.
Computerized interpretation possible if section meanings and entries are coded.
Depends on section heading, question/data label, and values entered.
Computerized interpretation is possible with appropriate codes and values.
An EHR may emulate traditional paper-based structures for data entry and display. However, unlike paper records, electronic systems store data in a common logical structure, independent of UI format. This allows for flexible display, reporting, and analysis.
Different entry techniques suit different clinical situations—e.g., a checklist for common history items or a detailed form for a specific diagnosis. Paper records may differ structurally but contain similar information. In contrast, EHRs can map diverse UI formats to a unified structure, as illustrated in the diagram below.
Accurate interpretation of data from various input methods requires systems to capture and consistently apply context—e.g., differentiating between confirmed vs. possible diagnoses, or personal vs. family history.
Example of Mapping from Different User Interface Examples to a Common Data Structure
Acute 161972006 | central chest pain (finding)|.
No past history of 56265001 | heart disease (disorder)| or 50043002 | Disorder of respiratory system (disorder)|.
Hiatus hernia 84089009 | hiatus hernia| was diagnosed 5 years ago.
Treats 162031009 | indigestion (finding)| with 3402011000001103 | Generic Gaviscon 500mg chewable tablets sugar free (product)|.
Father died of myocardial infarction at age 57. 160274005 | No family history diabetes (situation)|.
Says their cousin has chest problems but is not sure if this is Asthma.
Working diagnosis: possible myocardial infarction but maybe reflux gastritis.Diagnosis of myocardial infarction.Acute central chest painNo known heart or lung disease
Hiatus herniaFather: Myocardial infarction (died at 57)
No family history of diabetes mellitus
Uncertainty about family history of asthmaMyocardial infarction
Reflux esophagitisMyocardial infarctionHeart disease: Yes No
Lung disease: Yes No
Gastrointestinal disease: Yes No
Hiatus herniaHeart disease: Yes No Unknown
Diabetes mellitus: Yes No Unknown
Chronic lung disease: Yes No Unknown Heart rate: 85 /min
Respiratory rate: 24 /min
Temperature: 37.2 °C Myocardial infarction: Confirmed Possible Excluded
Reflux esophagitis: Confirmed Possible Excluded Myocardial infarction: Confirmed Possible Excluded
Reflux esophagitis: Confirmed Possible Excluded 
In the context of health information technology (IT), an information model is a formal representation or framework that defines the structure, organization, and semantics of health data. It serves as a blueprint for designing electronic health record (EHR) systems, health information exchanges (HIEs), clinical decision support systems, and other health IT applications. Information models specify how data elements are structured, their relationships, and the rules governing their use.
Here are some key aspects of information models in health IT:
Data Structure : Information models define the structure of health data by specifying the data elements or attributes that comprise a health record. These elements can include patient demographics, clinical observations, diagnoses, procedures, medications, and more. Information models organize these data elements into meaningful units, such as patient encounters, episodes of care, or clinical documents.
Relationships : Information models describe the relationships between different data elements within a health record. For example, they specify how a diagnosis is associated with a patient encounter, how a medication is linked to a prescription order, or how a laboratory result relates to a specific test.
Semantics : Information models provide a semantic framework for health data, ensuring that the meaning of data elements is unambiguous. They define standardized terminologies and codes for clinical concepts, such as SNOMED CT for diagnoses and LOINC for laboratory tests, to enable consistent representation and interpretation of health information.
Interoperability : Information models support interoperability by providing a common framework for structuring and exchanging health data across different systems and organizations. They enable seamless data sharing and communication between EHRs, HIEs, laboratories, pharmacies, and other healthcare stakeholders.
Standards Compliance : Information models often adhere to industry standards and specifications, such as HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) or openEHR, to ensure compatibility and interoperability with other health IT systems and applications.
Extensibility : Information models are designed to accommodate evolving healthcare needs and technological advancements. They are often extensible, allowing for the addition of new data elements, attributes, or relationships to support emerging clinical requirements or regulatory mandates.
The relationship between SNOMED CT and information models exists along a continuum rather than as distinct, separate components.
At one extreme, an information model could consist of a single generic data element, relying entirely on a highly expressive terminology to convey clinical meaning. At the other extreme, a highly structured information model could encode detailed semantics independently of the terminology it employs. The challenges of information exchange and semantic interoperability arise from the wide range of implementations that exist between these two extremes, reflecting the diverse approaches found in contemporary healthcare systems.
In general, the roles and use cases of SNOMED CT and information models can be described as:
Standardization : SNOMED CT provides standardized clinical terminology, while information models ensure that this terminology is integrated into health information systems in a structured and consistent manner.
Interoperability : By using SNOMED CT in conjunction with information models, healthcare organizations can achieve interoperability, allowing different systems and applications to exchange and use health information effectively.
Semantic Interoperability : SNOMED CT's rich semantics enable precise representation of clinical concepts, supporting semantic interoperability—the ability to exchange and understand the meaning of health information accurately. Information models help ensure that these semantic structures are appropriately utilized within health information systems.
Information models serve various functions within healthcare IT systems. Each type of information model plays a crucial role in healthcare IT. Combining these models ensures effective data capture, storage, communication, analysis, and decision support, ultimately improving patient care and healthcare delivery.
This table provides an overview of the different types of information models used in healthcare, along with examples for each type.
Information models in healthcare can represent clinical data in different ways, ranging from unstructured text to highly standardized, machine-processable formats. The type of representation chosen impacts data usability, interoperability, and precision in information exchange. The table below outlines the key types of information model representations, their descriptions, advantages, and limitations.
Choosing the right information model representation is critical for achieving effective clinical documentation, interoperability, and data-driven decision-making. Combining free-text narratives for human interpretation with structured and standardized representations for machine processing ensures robust healthcare data management.
Clinical Decision Support : When integrated with information models, SNOMED CT enables the development of sophisticated clinical decision support systems, which can analyze and interpret health data to provide clinicians with relevant information and guidance at the point of care.
Research and Analytics : SNOMED CT's detailed clinical concepts, when combined with information models, support advanced data analysis, research, and population health management by providing a standardized framework for querying and aggregating health data across disparate sources.
Regional, National, and International Clinical Models
Provide standardized definitions for health data at different levels of healthcare delivery.
National EHR models, regional health information exchanges (HIEs), international standards like ISO 13606.
Reference Information Models
Serve as formal frameworks for consistent data definitions and sharing.
HL7 v3 RIM, openEHR, FHIR resources, ISO 13606.
Message Models
Standardize the structure of messages exchanged between systems.
HL7 v2 messages, FHIR messages, ISO 13606 extracts.
Service Models
Facilitate service-based communication between systems.
FHIR APIs, SOAP-based web services, RESTful services.
Data Warehouse Models
Organize large datasets for efficient querying and analysis.
Clinical data warehouses, population health analytics platforms.
Guideline Definition Models
Define clinical guidelines and care pathways.
Clinical practice guidelines, care pathway models (e.g., Map of Medicine, Ardern syntax).
Rule Models
Support automated decision-making and clinical rules.
Clinical decision support rules, workflow automation rules.
Supports machine processing, consistency, and interoperability.
Limited flexibility for complex clinical scenarios.
Terminology-Bound Representations
Data elements linked to standardized terminologies like SNOMED CT, LOINC, or ICD-10.
Ensures consistent meaning, supports semantic interoperability and data analysis.
Requires terminology maintenance and appropriate binding.
Model-Based Representations
Data represented using formal models like HL7 FHIR, openEHR archetypes, or ISO 13606.
Supports complex relationships, extensibility, and precise data exchange.
Requires expertise in modeling standards and implementation.
Computer-Processable Representations
Data encoded in formats like XML, JSON, or relational database schemas.
Enables automated processing, validation, and system integration.
Complexity increases with detailed data structures.
User Interface Models
Define how data is captured, displayed, and interacted with in clinical user interfaces.
Forms in EHR systems, clinical dashboards, data entry screens.
Information Storage Models
Describe how data is stored within the system.
Free-Text Narratives
Unstructured, human-readable text used for documenting clinical information, such as notes or summaries.
Easy to capture, flexible for human interpretation.
Difficult for machines to process, prone to inconsistencies, limited interoperability.
Structured Data Elements
Relational databases (SQL), object databases, XML stores.
Data captured in predefined fields with specific values, such as drop-down menus or checkboxes.
Accurate and consistent data representation is essential for ensuring interoperability, data quality, and meaningful exchange of healthcare information. However, challenges arise when clinical data is represented in ways that are inconsistent or ambiguous. These issues can lead to misinterpretation, data loss, and hindered communication between systems.
Inconsistencies in data representation in healthcare can significantly impact patient care and operational efficiency. These inconsistencies often arise from the use of varied formats, terminologies, and levels of detail across different healthcare systems and providers. For instance, one clinic might use a simple model to record basic information about a patient's examination, such as general appearance and basic vital signs, while another might employ a detailed model capturing extensive metrics, including specific observations on each body system. Such disparities can lead to challenges in sharing and interpreting data, causing potential miscommunication or loss of critical patient information. Furthermore, the lack of standardized data representation complicates the aggregation and analysis of healthcare data for research and quality improvement, ultimately affecting the ability to deliver consistent, high-quality patient care.
Even when using the same terminology, the representation of information in healthcare can vary significantly. For example, standards like SNOMED CT provide a comprehensive set of terms for encoding clinical data, but the application of these standards can differ among systems, providers, and users. Different electronic health record (EHR) systems may implement SNOMED CT differently, affecting how data is recorded and retrieved. In addition to this, implementations may change over time, adopting different conventions in the same system.
The representation of information containing contextual factors can vary significantly based on the design of the systems and their underlying information models. Specifically, within the recording of clinical data, key contextual factors include presence/absence indicators, temporal context, and subject relationship.
Presence/Absence Indicators: Indicating the presence or absence of specific conditions, symptoms, or risk factors is essential for accurately documenting a patient's health status, tracking disease progression, and monitoring treatment outcomes.
Temporal Context: The timing of events, such as the onset of symptoms, duration of treatment, or frequency of occurrences, provides valuable context for understanding a patient's medical history and informing clinical decision-making.
Subject Relationship: This contextual factor pertains to understanding who the condition or procedure relates to, such as family history or genetic predisposition. Clarifying subject relationships can provide insights into disease etiology, risk assessment, and personalized treatment strategies.
Incorporating these contextual factors into the recording of clinical data enhances the comprehensiveness, accuracy, and relevance of health information, facilitating more informed clinical decisions and improved patient outcomes. However, variations in how these factors are captured and represented across different systems and information models underscore the need for standardized approaches and interoperable systems to ensure consistency and compatibility in healthcare data management.
SNOMED CT enable consistent representation and analysis of clinical ideas. However, the same concept can be used in different contexts in the information model of an ) and, as illustrated by the examples in , the context may fundamentally affect the meaning. Therefore, accurate interpretation of an EHR entry depends on understanding both the meaning of the concept __ when encountered in isolation,__ and how that meaning is modified by associated contextual information.
An EHR entry containing a concept that represents a disease might be assumed to imply an assertion that the subject of that record currently has that disease.
Associated contextual information may make this assumption incorrect.
An EHR entry containing a concept that represents a symptom might be assumed to imply that the subject of the record states that they currently have that symptom. Similarly, a concept that represents a clinical sign may seem to indicate that this sign has been found when examining the patient.
Associated contextual information may make these assumptions incorrect.
An EHR entry containing a concept that represents a procedure might be assumed to imply that the procedure has been carried on on the subject of the record.
Associated contextual information may make this assumption incorrect.
An EHR entry containing a concept that represents an observable entity might be assumed to imply that an observation had been made.
Associated contextual information may make this assumption incorrect.
<
Possible diagnosis: A note that this diagnosis is being considered or investigated.
Excluded diagnosis: An assertion that this diagnosis has been ruled out.
Medical history: An indication of whether the subject of the record has previously had this disorder. In the case of a chronic condition, such as diabetes mellitus, the diagnosis remains relevant but may be distinct from the diagnosis of the presenting complaint.
Family history: An indication of whether any members of the subject's family have had this disorder.
< MINUS <<
Past history of a symptom: A symptom that was present but is not currently present.
Absent symptom: A note that the subject reports that they have not had this symptom.
Negative sign: An indication that the examination did not detect the clinical sign.
Sign not tested: An indication that the clinical sign was not checked.
<
Requested procedure: A request for a procedure to be considered or done, which is submitted to an appropriate .
Planned procedure: A note of a decision to carry out the procedure at some point in the future.
Admitted for a procedure: An indication that the reason for admission is to carry out a procedure.
Procedure not done: An indication that the procedure was not carried out.
<
Scheduled observations: A plan for regular observations associated with a particular procedure or assessment.
Data entry label: The observation is only known to have been done if its results are recorded.
Observation not done: An indication that observation was not made.