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.

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

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.

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.