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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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 Role of SNOMED CT in Information Models

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Information Models Types

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 Model Representation

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.

Provide Feedback

Background

An important challenge for achieving semantic interoperability across borders, even when using the same terminology, lies in the potential mismatch between the terminology and the applied information models. While using consistent terminology helps in communication, the way this terminology is bound to specific information models can lead to incompatible data representations.

In SNOMED CT, context refers to additional semantic details that modify the meaning of a clinical concept, typically by specifying aspects such as who the subject is, the temporal status of the event, or the certainty of a finding. These details are essential in distinguishing between different interpretations of the same base concept.

The problem arises from the divergence in approaches to representing context within different implementations of systems or databases. Some implementations rely on the terminology itself to represent contextual information, while others use the information model to encapsulate and represent context. Consequently, this leads to a disparity in how context is managed and represented, creating challenges in achieving semantic interoperability. These two overall approaches are summarized below, but even within these categories, variations may occur.

1. Terminology-based Context Representation:

   • In some systems, the context is embedded within the terminology itself, e.g. when SNOMED CT concepts such as |family history of asthma| or |suspected neoplasm| are captured. This approach utilizes concepts and relationships within the terminology to convey contextual information. In these cases, the defining properties of the concepts represent the contextual factor, e.g. the temporal, subject relationship, or certainty of the disorder or procedure.

2. Information Model-based Context Representation:

   • Conversely, other systems embed contextual details within their information models. Instead of being explicitly represented by the terminology, the context relies on how the information model structures and organizes data elements. This can involve attributes, relationships, or additional metadata fields specifically designated to convey context.

The problems stemming from this diversity in data representation include:

1. Interoperability Challenges:

   • Misalignment between systems arises due to the differing approaches in representing context. Systems relying on the terminology for context may not easily communicate with those that embed context in their information models, leading to interoperability issues.

2. Data Consistency and Interpretation:

Addressing these issues involves developing frameworks or guidelines that reconcile these differing approaches. Creating a standardized approach to represent context, bridging the gap between terminology-driven and information model-based systems, is crucial to enhancing semantic interoperability and facilitating seamless data exchange across diverse healthcare information systems.

The objective of this SNOMED CT Implementation Guide for Context Representation is to:

• Help implementers understand how SNOMED CT represents context.

• Offer practical guidance for designing data models, performing terminology bindings, and interpreting SNOMED-encoded information.

• Facilitate the transformation between systems that use the ‘Situation with Explicit Context’ hierarchy and systems that represent context in information models, in either direction.

This guide focuses on:

• Describing approaches for representing context in SNOMED CT, both through terminology and information models.

• Offering guidance on transforming data between terminology-based and information model-based context representations.

• Providing best practices for achieving semantic interoperability.

Out of Scope:

• Detailed technical implementation for specific software systems.

• Broader aspects of clinical terminology outside context representation.

• General SNOMED CT use cases unrelated to context representation.

This guide is intended for the following stakeholders:

• SNOMED International Members: Seeking best practices for consistent context representation and interoperability.

• Clinicians: Understanding how SNOMED CT supports clinical data collection involving contextual information.

• Information Managers: Integrating SNOMED CT into health information models to improve data interoperability.

• Software Developers:

This SNOMED CT Implementation Guide for Context Representation provides guidance on managing and implementing context within healthcare systems using SNOMED CT. The guide addresses challenges related to differing context representation approaches and supports achieving semantic interoperability despite those differences. It is organized into the following chapters:

• • Introduces the background, objectives, scope, and target audience of the guide, emphasizing the importance of addressing context representation challenges to improve interoperability.

• • Examines the role of healthcare terminologies and information models, highlighting how inconsistent data representation can impact semantic interoperability.

This SNOMED CT Implementation Guide for Context Representation is maintained by SNOMED International. Updates to the guide will be made when significant changes to SNOMED CT content affect the principles outlined in the guide, or when user feedback identifies areas requiring attention.

For general inquiries or comments unrelated to specific page content, please contact:

Email:

Your input is invaluable in helping us maintain a resource that supports effective implementation and promotes interoperability across healthcare systems.

In today's interconnected digital ecosystem, the seamless exchange of information between diverse systems is more critical than ever. A fundamental obstacle to achieving true interoperability lies in how different systems represent context information about concepts. Some systems embed this context directly within the terminology, using codes with rich, nuanced meanings. Others represent context through their information models, structuring data to convey context via relationships and attributes. This disparity creates a landscape where data exchanged between systems may lose its intended meaning unless carefully transformed and interpreted.

This chapter focuses on the strategies and methodologies for implementing transformations between these heterogeneous models. We will delve into the technical challenges of mapping context from terminologies to information models and explore practical solutions to bridge these differences. By examining real-world scenarios and leveraging interoperability standards, we aim to equip you with the knowledge and tools necessary to ensure that context is preserved and accurately conveyed during data exchange. Understanding these transformation processes is essential for developers, architects, and stakeholders striving to enhance interoperability and achieve consistent, reliable communication across varied systems.

Example of a transformation from a "Situation with explicit context" concept to a FHIR FamilyMemberHistory Resource information model

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.

Inconsistent Data Representation

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.

1. 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.

2. 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.

3. 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.

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.

Terminology

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

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.

Separation and Overlap

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.

Information model-driven vs Terminology-driven Context Representation

Overarching Principle

• Ensure that the consolidated meaning represented by the chosen SNOMED CT concept and the applied information model represent the intended semantics, and unambiguously declare the context. I.e. the verification, temporal, and subject relationship context.

Below find a set of terminology binding principles, to help guide the binding of specific types of data elements.

Terminology Binding Principles and Examples

Adhering to these principles provides a robust framework for designing terminology bindings compatible with the SNOMED Concept Model and the structural expressivity of FHIR resources. By ensuring compatibility, we can create a cohesive system where clinical content is accurately and consistently represented across different platforms and applications. This alignment is crucial for maintaining the integrity of clinical data, allowing for seamless integration and reducing the risk of misinterpretation or data loss during exchanges.

Furthermore, this approach facilitates efficient transformations and adaptations in the context of analytics and interoperability. Standardized terminology bindings enable healthcare systems to effectively share and analyze data, supporting advanced analytics, research, and population health management.

Measurable Entities

This section describes how to model clinical data items that capture measurable or observable values. These may include numeric values (e.g., blood pressure) or coded findings (e.g., eye color).

• Concrete values (e.g., numbers with units)

• Coded findings:

• Use Observable Entity for measurable/quantifiable data.

• Use Clinical Finding when answers are selected from a list of predefined, coded options (e.g., eye color).

This section explains how to model whether a clinical finding is present or absent. It includes both direct verification and more complex contextual modeling.

There are two typical approaches:

• Direct Finding: used for current, patient-specific presence/absence

• Contextual Finding: used for historical, familial, or other contextualized interpretations

• Use Direct Finding for simple verification in the current clinical context.

• Use Contextual Finding when temporal, subject, or situational context is required.

• Ensure consistency between meaning binding and value set binding.

• For complex expressions, follow the .

Used when recording whether a condition applies to the patient at the time of data entry.

Used when the finding is not current or applies to someone other than the patient (e.g., family member, historical diagnosis).

• Replace or populate the 408729009 |Finding context| attribute using the chosen qualifier (e.g., “Known absent”).

• Appropriate for modeling:

  • History of conditions

  • Family history

Boolean-style clinical questions require modeling using SNOMED CT concepts with verification qualifiers. These typically involve conditions where only a “yes” or “no” answer is expected.

• Use “Known present” and “Known absent” to model responses.

• If the absence of a finding is implied (e.g., by default), you may choose to record only the “yes” responses.

• Ensure consistent use of Boolean logic across the dataset.

When applying qualifier values to represent the absence of a condition like diabetes mellitus using SNOMED CT an expression can be derived to convey the meaning with explicit context.

Example:

1. Identify the Concept for Diabetes Mellitus: Firstly, we need to identify the SNOMED CT concept representing diabetes mellitus.

   • 73211009 |Diabetes mellitus (disorder)|

2. Representing the Absence/Presence of Diabetes Mellitus: To represent the absence/ of diabetes mellitus, we need to create an expression that explicitly states the absence of the disorder.

This expression clearly indicates that the disorder of diabetes mellitus is absent in this patient at the current point in time or the time specified in the model. It provides a single expression that encapsulates the meaning of the absence of diabetes mellitus with explicit context.

In summary, expressions representing the absence of any specific disorders or conditions in SNOMED CT can be formulated as a SNOMED expression by combining the concept representing the disorder with a qualifier value indicating absence, linked together using the appropriate context model attribute (in this case, 408729009 |Finding context| ). This approach allows for the creation of concise and unambiguously meaningful expressions that convey the absence of any particular condition, all entirely within the SNOMED CT terminology framework.

These expressions must adhere to the SNOMED CT concept model and other constraints to ensure that they extend SNOMED CT in a cohesive and meaningful way, see the

This chapter focuses on Information Models and Terminology Binding, key components for ensuring the structured representation, exchange, and understanding of healthcare data. It explores how SNOMED CT integrates with information models to enable interoperability and semantic clarity across health information systems.

The chapter introduces value set binding, which constrains the allowed values in a data entry context, and meaning binding, which captures how context affects the interpretation of a data item.

It also examines interoperability standards like FHIR and compares clinical findings in different contexts, further emphasizing SNOMED CT’s role in facilitating accurate and consistent healthcare documentation.

In health information systems, data is often entered within structured contexts such as forms, templates, or EHR fields. The way in which terminology is bound to these data structures has a direct impact on:

• What concepts can be entered (i.e., constraining the input)

• How entered concepts should be interpreted (i.e., defining their meaning in context)

Terminology bindings are formal links between terminology components (e.g., SNOMED CT concepts, value sets, or expression constraints) and elements of an information model (e.g., fields, templates, or data entry sections).

There are two main types of terminology binding:

1. Value Set Binding – defines the allowable set of concepts that can be selected or entered in a specific context.

2. Meaning Binding – specifies how the entered concept should be interpreted within that context.

A data entry context to which this constraint is applied would only permit the entry of concepts representing surgical procedures.

If a user searches for terms matching “append”, surgical procedure concepts such as:

• 80146002 | Excision of appendix (procedure)|

• 174036004 | Emergency appendectomy|

• 6025007 | Laparoscopic appendectomy (procedure)|

should be available for selection.

However, other concepts with matching terms such as:

• 74400008 | Appendicitis (disorder)|

• 47693006 | Rupture of appendix (disorder)|

• 66754008 | Appendix structure (body structure)|

should not be available in this data entry context.

Designing user interfaces for data capture that effectively represents context is a critical aspect of developing interoperable healthcare systems. This process involves defining sets of related fields that are bound to SNOMED CT. By carefully structuring these fields and their relationships, we ensure that the context in which data is captured is accurately represented and preserved. This enhances the data's quality and facilitates seamless data exchange between different systems and applications.

There are two primary approaches to achieving context representation in user interfaces. The first involves software designers incorporating context-aware elements during the UI development phase. In this method, developers define and hard-code the sets of related fields and their specific terminology bindings directly into the user interface. This approach allows for precise control over the data capture process but may require significant effort to update or modify as clinical practices evolve.

The second approach utilizes dynamic user interface generators that support the creation of data entry templates. These generators enable the development of flexible interfaces where templates can be designed and adjusted without extensive programming. Healthcare providers can customize data entry forms using templates to capture the appropriate context level for each use case. This method supports adaptability across different sections of clinical records and accommodates the varying needs of medical specialties, enhancing usability and efficiency.

We have developed a terminology binding sandbox to demonstrate the practicality of dynamic interfaces with terminology bindings. This tool supports the creation of dynamic user interfaces with SNOMED CT terminology bindings, demonstrating how a library of templates could be created. This example shows how it is possible to design templates to provide the appropriate level of context representation for various data entry scenarios. Whether used in different sections of clinical records or tailored for specific medical specialties, a template designer tool similar to this sandbox enables users to generate context-aware interfaces that improve data accuracy and interoperability.

FHIR Questionnaires offer a robust and standardized method for creating data capture forms that are both interoperable and context-aware. As part of the HL7 FHIR standard, the Questionnaire resource allows for the definition of structured forms, including questions, response options, and complex logic for conditional display and validation. By utilizing FHIR Questionnaires, developers can create forms that are consistent across different systems and capable of capturing detailed context information tied to standardized terminologies like SNOMED CT. Content entered in FHIR Questionnaires can be exported into other FHIR resources, such as Conditions or Observations, enabling further transformations if necessary.

Recognizing the importance of integrating SNOMED CT into these standardized forms, SNOMED International has collaborated with the National Library of Medicine (NLM) to enhance with full support for SNOMED CT. This collaboration has resulted in a more powerful forms builder that enables users to seamlessly incorporate SNOMED CT concepts into FHIR Questionnaires. The enhanced tool allows for precise terminology bindings and integration with terminology servers, ensuring that the data captured aligns with international standards and can be effectively exchanged and interpreted across diverse healthcare systems.

Moreover, SNOMED International has developed a to further support the adoption of standardized data capture forms. This application allows the use of any FHIR server as a repository for a collection of FHIR Questionnaires designed with SNOMED CT integration, providing a valuable resource for healthcare organizations looking to implement standardized forms efficiently. The validation app complements this repository by allowing users to verify that the terminology bindings in their Questionnaires refer to current concepts in SNOMED CT latest releases.

Data storage considerations are pivotal when managing context-aware data capture and retrieval. One option is to develop an ad-hoc data model , where you create custom schemas tailored to the specific needs of your application. This approach allows for precise control over how data and context are stored. However, it can be inflexible and challenging to scale or modify as requirements evolve, potentially leading to increased maintenance overhead.

Alternatively, you can store flexible objects in a document database. Document databases are designed to handle semi-structured data, making them well-suited for storing complex and dynamic data structures generated from user interfaces or templates. This method offers greater flexibility and ease of adaptation to changing data models without the need for extensive schema migrations. It allows developers to adjust the data structure as needed, accommodating new fields or context information seamlessly.

Another strategy is to directly store FHIR resources in their native format. Since FHIR resources inherently include both data and context within a standardized structure, storing them as-is ensures compatibility with other FHIR-compliant systems. This approach simplifies data management by leveraging the built-in interoperability of FHIR, reducing the need for additional data transformation during storage and retrieval. It facilitates easier data exchange and integration with other healthcare applications, promoting a more unified ecosystem.

Definition and Purpose

Procedures with explicit context describe situations where a medical procedure’s status, timing, or relationship to the patient is specified. These concepts clarify whether a procedure is planned, completed, or not done, among other statuses.

Attributes Used

• Associated Procedure: Links the situation to the specific procedure being considered.

  • For example, |Lung transplant planned (situation)| uses this attribute to connect to |Lung transplant (procedure)|.

• Procedure Context: Describes the status of the procedure, such as whether it is planned, completed, or not done.

  • For example, |Lung transplant planned (situation)|, the procedure context is |Planned|.

• Temporal Context: Indicates when the procedure is or was to take place (past, present, future).

  • For example, |Lung transplant planned (situation)| uses |In the future| as the temporal context.

• Subject Relationship Context: Specifies who the procedure pertains to, usually the patient but can be a different person.

  • For example, |Mother’s surgery planned (situation)| would indicate the procedure pertains to the patient’s mother.

The default values for the context attributes for procedures assume that the procedure has occurred, is current or at a specified time, and pertains to the subject of the record.

The SNOMED CT concept describes a patient’s status as they await a kidney transplant. A key attribute here is Associated procedure, which is . This indicates that the focus of the situation is the upcoming kidney transplantation procedure. Additionally, the concept includes the as To be done, specifying that the transplant is planned but not yet performed, and it applies to the patient at the .

The SNOMED CT concept represents a planned lung transplant for a patient. A key attribute here is . This attribute indicates that the lung transplant is scheduled for the future and has not yet been performed. Additionally, the concept includes as

, specifying the type of procedure planned. The

is , indicating that the procedure pertains to the patient themselves. The is , showing that the procedure is relevant at the present time or based on a specific schedule.

The SNOMED CT concept represents the occurrence of mastectomy within a patient’s family history. A key attribute here is Subject relationship context, which is . This attribute specifies that the mastectomy is related to a family member rather than the patient themselves. The concept also includes the associated procedure as , indicating that the mastectomy was the specific procedure performed, and the procedure context as Done, reflecting that the procedure has been completed. The temporal context is , signifying that the procedure occurred in the past or is relevant at present.

The SNOMED CT concept details a patient’s past use of estrogen hormone therapy. A key attribute here is , which is . This attribute specifies that the estrogen therapy occurred in the past. Additionally, the concept includes as , indicating the specific therapy administered, and as , showing that the therapy was completed. The subject relationship context is as , signifying that the therapy pertains to the patient themselves.

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.

Clinical Data Entry Scenarios and Context Representation Challenges

Free Text Entry

Interpretation

• 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

The following use cases highlight how addressing context representation challenges can enhance data capture, interoperability, and analytics in healthcare.

Establishing a well-structured data model with appropriate terminology bindings ensures accurate clinical data recording and meaningful documentation. This supports patient care and enables long-term health data analysis.

Standardizing context representation allows systems with different approaches—such as terminology-driven or model-based contexts—to seamlessly exchange data. This improves interoperability and ensures comprehensive patient information sharing.

Consistent context representation enables accurate integration and interpretation of data across systems. This supports reliable analytics, research, and population health management by ensuring semantic consistency.

Definition and Purpose

Clinical findings with explicit context refer to situations where the presence, absence, or uncertainty of a clinical finding is documented with additional contextual details. These concepts provide a clear understanding of the specific circumstances under which a clinical finding is relevant.

Attributes

• Associated Finding : Links the situation to a relevant clinical finding or event.

  • For example, the concept |History of sepsis (situation)| uses this attribute to connect to the clinical finding |Sepsis|.

• Finding Context : Indicates whether the clinical finding is confirmed, suspected, unknown, or absent.

  • For example, for the concept |No known food allergy (situation)|, the finding context is |Known absent|.

• Temporal Context : Specifies when the finding occurred or is expected to occur (past, present, future).

  • For example, |History of sepsis (situation)| uses |In the past| as the temporal context.

• Subject Relationship Context : Identifies who the clinical finding pertains to, such as the patient, a family member, or another individual.

  • For example, |Family history of diabetes mellitus (situation)| would indicate that the finding relates to a family member.

The SNOMED CT concept describes a past instance of monkeypox in a patient’s medical history. It is characterized by the Associated finding attribute, which specifies that the condition is . This indicates that monkeypox was the specific viral illness recorded in the patient’s history. The concept also includes information that the condition was confirmed as present, pertains to the patient, and occurred in the past.

The SNOMED CT concept indicates that the patient does not have known food allergies. A key attribute here is , which is . This attribute specifies that the absence of a food allergy is confirmed. Additionally, the concept includes as , showing the specific type of allergy being assessed. The is , meaning the information pertains to the patient. The is , indicating that this absence of allergy has been consistent over time.

The SNOMED CT concept represents a patient’s past occurrence of sepsis. A key attribute here is , which is . This attribute specifies that the sepsis occurred in the past. The concept also includes as , indicating the specific condition recorded, and as , confirming that the sepsis was known to be present. The is , indicating that the sepsis pertains to the patient themselves.

The SNOMED CT concept represents the smoking status of a patient’s father. Central to this concept is the Subject relationship context attribute, which is . This attribute indicates that the smoking status being recorded pertains specifically to the patient’s father. The concept also includes details such as the associated finding of , the finding context as , and the temporal context as , reflecting that the smoking status is currently known and applies to the patient’s father.

This chapter delves into how context is represented within SNOMED CT, highlighting how context-free hierarchies interact with explicit contextual details present in the Situation with Explicit Context subset. Understanding these nuances holds significance for healthcare practitioners and informaticians, impacting the accuracy and utility of clinical terminologies.

Content without Explicit Context

The top-level hierarchies of SNOMED CT, excluding the Situations with Explicit Contexts hierarchy, are typically meant to be interpreted within the framework of an information model. These hierarchies, including Clinical Finding, Procedure, Body Structure, and Substance, among others, do not inherently carry explicit contextual information within the concepts themselves. Instead, their interpretation relies heavily on the applied information model within a specific healthcare system or setting. The information model defines how these SNOMED CT concepts are structured, related, and utilized within a particular context. It offers a structured framework for their meaningful interpretation and application in clinical scenarios. This reliance on the information model ensures that these concepts are accurately understood and used within the context of healthcare delivery, aiding in precise data representation, clinical decision-making, and interoperability across different healthcare systems.

Defining Properties and the Concept Model

The SNOMED CT concept model serves as the framework for SNOMED CT's quality, defining relationship types (attributes) that encapsulate the defining properties of concepts. For each top-level hierarchy or sub-hierarchies, it specifies the set of attributes applicable to concepts within that domain, and it outlines the range of concepts suitable as the value for each attribute. This set of rules supports uniformity and coherence across concept definitions.

The concept model is integral to ensuring SNOMED CT's quality standards. It fosters consistency in concept definitions, vital for the accurate functioning of the Description Logic reasoner. Adhering to this model enables the reasoner to accurately derive inferences, ensuring dependable and precise outcomes when searching, querying, or utilizing SNOMED CT data.

The attributes outlined in the SNOMED CT concept model represent inherent properties that must be true for every instance of that concept. These attributes do not change the fundamental nature or primary type of the concept within its hierarchy. Rather, they establish consistent and unchanging characteristics unique to each instance in the hierarchy, maintaining the core identity of the concept. For this reason, concepts such as 'family history of asthma' or 'diarrhea not present' are not included in the Clinical finging top-level hierarchy. These concepts don't depict actual disorders; instead, they describe particular contextualized situations associated with conditions like asthma and diarrhea. Similarly, within the Procedure hierarchy, concepts such as 'no history of mammogram' or 'Hypersensitivity skin test not done' wouldn't be present. These concepts don't signify specific clinical procedures; rather, they indicate situations or contexts surrounding procedures like mammograms or hypersensitivity skin tests.

Maintaining the integrity and scope of each hierarchy within SNOMED CT is crucial. Altering the meanings of concepts or introducing concepts with explicit context can compromise the terminology's usability for precise data retrieval, analysis, and decision support. When concepts deviate from their intended definitions within their hierarchies, it hampers the accuracy and reliability of information retrieval and analysis processes. This situation becomes particularly critical in healthcare settings, where inaccuracies or ambiguous interpretations due to altered concepts can lead to safety-critical outcomes. Therefore, upholding the intended scope and definitions within hierarchies in SNOMED CT is vital for ensuring the reliability and safety of clinical data interpretation, decision-making, and patient care.

For more information about the SNOMED CT concept model, please refer to the Editorial Guide and the .

SNOMED CT was purposefully designed with a specific hierarchy, known as the Situation with Explicit Context (SWEC), to maintain a clear separation of contextualized findings and procedures. This hierarchy intends to define clinical situations as precoordinated concepts, i.e. clinical findings or procedures associated with contextual factors. The concept model guiding SWEC precisely defines acceptable contextual factors for each concept, enabling the documentation of contextualized clinical information while maintaining a standardized structure crucial for accurate data utilization and interoperability. Importantly, unlike other clinical hierarchies in SNOMED CT that are generally context-free, SWEC concepts are distinguished by their inclusion of context-specific details within the concepts themselves. This self-contained representation of SWEC concepts reduces reliance on external models for context interpretation.

The Situation with Explicit Context (SwEC) hierarchy is designed to capture and represent clinical findings and procedures within specific contexts, ensuring that their meaning is fully understood in the appropriate circumstances.

The concept model for SwECs includes two core attributes that apply universally to any concept within the hierarchy. Additionally, two specific attributes apply to Procedures with Explicit Context, and another two attributes are specific to Clinical Findings with Explicit Context. The table below outlines the purpose and semantic interpretation of each of these attributes.

The following pages will present examples of the different types of situations with explicit context, illustrating how each attribute is applied.

SNOMED CT implementers must develop a clear strategy for representing clinical context, taking into account:

• The structure and constraints of existing data models

• Cultural preferences and local workflows for data entry

• Alignment with national or organizational standards

This strategy must define the division of responsibility between the information model and the terminology model, i.e., which context elements are represented by system fields and which are encoded directly within SNOMED CT concepts.

These decisions impact:

• The design of terminology bindings

• The structure of user interfaces

• The consistency of clinical data interpretation

Two general approaches can be used to represent clinical context in SNOMED CT implementations:

• Representing context in the information model

• Representing context in the terminology

In this approach, only context-free concepts from SNOMED CT are bound to data elements. Contextual details are stored in separate fields in the information model.

• Diagnosis/Problems:

• Procedures:

These fields may be populated with SNOMED CT concepts representing:

• Finding context

  Describes the nature of the finding (e.g., suspected, confirmed)

• Subject relationship context

  Indicates the relationship of the subject to the patient (e.g., family member)

• Temporal context

  Specifies the time frame (e.g., past, present)

This approach binds to SNOMED CT concepts that include both the clinical meaning and its context, using either:

• Pre-coordinated concepts

• Postcoordinated expressions

• Diagnosis/Problems:

• Procedures:

This approach minimizes reliance on custom or ad-hoc fields by using SNOMED CT’s built-in context modeling features.

Pros:

• Greater coverage

  Not all context combinations are represented in SNOMED CT—this method fills that gap.

• Flexibility

  Allows systems to dynamically combine findings/procedures with context values.

Cons:

• Higher development effort

  Requires more complex UI and backend design to manage contextual fields.

• Increased user burden

  Without thoughtful UI design, clinicians may face longer workflows.

Pros:

• Simplified text search

  Pre-coordinated concepts (e.g., “History of asthma”) are easier to find.

• Efficient data entry

  Eliminates the need for separate context fields.

• Expandability

  New context combinations can be represented via new concepts or post-coordinated expressions.

Cons:

• Limited context coverage

  Only a subset of possible context variations are pre-coordinated in SNOMED CT.

• Terminology maintenance overhead

  Requires ongoing updates and careful management.

• Reduced alignment with standard models

  May not map cleanly to information models like FHIR, which expect discrete context fields.

There is no one-size-fits-all solution. The choice between representing context in the information model or in the terminology should be based on:

• Implementation goals

• Data model architecture

• Tooling capabilities

• User needs and workflow requirements

A balanced strategy, combining the flexibility of the information model with the efficiency of terminology-based context, often yields the best results.

Careful design ensures that context is represented accurately, consistently, and efficiently throughout the health information system.

Transforming information between the SNOMED concept model and a FHIR representation is a clear use case for interoperability or analytics. Creating a set of rules to reproducibly perform these transformations safely in real-world scenarios is possible.

We represent these rules as a decision table to offer a clear and structured approach to handling the heterogeneity between terminologies and information models. Although the list provided is not exhaustive and serves only as an example, it effectively demonstrates the critical considerations and steps involved in the transformation process. This approach helps readers understand not just the theoretical aspects but also the practical implementation of transformation rules, enabling them to apply similar strategies within their own systems to achieve seamless interoperability.

Example of a set of transformation rules from SNOMED Situations to FHIR Resources

To further illustrate the practical application of these transformation rules, we have developed a demonstration tool that performs real-time conversions from SNOMED CT to FHIR. This tool serves as a concrete example of how context information can be effectively translated between different models using a similar set of rules. It is open source, and the code is publicly available for anyone to review, use, or modify.

The SNOMED CT Implementation Guide for Context Representation provides important guidance for aligning SNOMED CT terminology with healthcare information models. It addresses the challenges of representing clinical context and terminology binding, particularly between SNOMED CT’s “Situation with Explicit Context” hierarchy and models like HL7 FHIR or openEHR. By introducing key principles and practical methods for accurate and interoperable context representation, the guide helps healthcare systems achieve consistency, improve data quality, and support better clinical decision-making. This standardized approach empowers developers and organizations to enable context-aware, interoperable data exchange across the healthcare ecosystem.

In the context of this SNOMED implementation guide, we have chosen to use the FHIR context model as an example of an information model for several reasons. FHIR is a widely adopted standard in the healthcare industry for exchanging electronic health records and related data. Its modular and extensible design makes it an ideal candidate to demonstrate how context information can be represented outside terminologies like SNOMED CT.

Here is your table cleanly formatted and optimized for GitBook, using Markdown and consistent styling for readability and responsiveness.

Clinical Findings with Context vs. FHIR Resources

The following table maps SNOMED CT “Situations with Explicit Context” subhierarchies to relevant FHIR resources, showing how clinical context is represented across terminology and information models.

• Where FHIR Resource is listed as N/A, there may be no direct mapping in the base FHIR specification.

• Context properties such as subject and temporal frame help clarify how the SNOMED concept aligns with FHIR resource attributes like subject, status, or effective[x].

The table below maps specific types of Situations with Explicit contexts to specific FHIR resources and states the associated context properties

As seen in the previous table, depending on the type of context represented in the SWEC concept, it can be transformed into a Condition or Observation resource. Here, we provide some examples of values for different key elements.