IP Review

Unattributed Code Systems

Copyright Fragment

This fragment is available on index.html

No use of external IP

Copyright and Registered Trademark Uses

Data analysis and research require integrated terminology to analyze aggregated information. Interoperability, CDS, or other types of automation require common semantics based on a set of integrated models across reference standards (e.g., SNOMED CT®, LOINC®, RxNorm). ( src )
A new set of local terminology may be managed with value sets and concept gaps addressed in quick iterations (e.g., “COVID-19 negative test result” was needed in practical use before official SDO releases, or gaps like “mild anemia”, which was proposed, but not accepted, by both the international and U.S. SNOMED CT® release). ( src )
Difficulty with determining that codes/terms using standard terminologies from disparate health IT systems represent a common clinical idea/concept (e.g., “Feels Feverish” in the Temperature Symptoms SNOMED CT® hierarchy versus “Feels Hot/Feverish” in the Observation and Sensation SNOMED CT® hierarchy. Both concepts are Findings in SNOMED CT® but there is no unifying way to identify equivalence). ( src )
Incorrect usage or representation of clinical ideas/concepts from standard terminologies due to a lack of harmonization and multiple representations that currently exist (e.g., LOINC® and SNOMED CT® have overlapping concepts). ( src )
IG © 2025+ HL7 Terminology Infrastruture Work Group. Package hl7.xprod.uv.tinkar#2.0.0 based on FHIR 5.0.0. Generated 2025-04-28 Links: Table of Contents | QA Report ( src )
Representation of medications: RxNorm codes overlap with CVX codes. Investigational vaccines from the FDA are not represented in RxNorm, CVX, or SNOMED CT®. ( src )
Stated vs. inferred relationships from SNOMED CT® ( src )
Module: Assignment to the appropriate terminology (e.g., LOINC) or terminology component (e.g., SNOMED CT®, US Extension). A module is identified by a concept, which may be annotated with other identifying information. (Requirement 22) ( src )
All Components in Tinkar are uniquely identified using UUIDs. A Component will be represented by an array of UUIDs with at least one UUID, but can be represented by more than one UUID in the case of a concept being derived from multiple sources as shown in the figure above. For example, the concept Acetaminophen (which exists in SNOMED CT®, LOINC, and RxNorm) could have a UUID from each terminology and be represented as an array of UUIDs for this single concept within a Tinkar implementation. ( src )
Despite the need to use standard terminologies in a highly integrated way, there is no standard representation across SNOMED CT®, LOINC®, RxNorm, etc. Some partnerships have been created among development teams to facilitate interoperability and minimize duplication of effort. Further integration has been proposed but will require additional resources to bring these terminologies closer together. However, while this evolution leads to greater compatibility and interoperability, integration of SNOMED CT®, LOINC®, and RxNorm is non-trivial as these terminologies use different formalisms and tools for their representation. Various terminologies have different semantics, models, release cycles, and versioning mechanisms [1]. While there is recognition that terminologies are not standardized at the exchange level, there is no consensus about harmonized next steps to solve the challenges. ( src )
Foundational Architecture - The Foundational layer of the Knowledge Architecture provides the common elements of interoperability, such as: object identity, versioning, modularity, and knowledge representation. It includes (a) the foundation and building blocks of the common model; (b) how the repeatable transformation process of disparate standards into the common model promotes interoperability with other environments; and (c) how the modules of the architecture are tightly version controlled over time. The Tinkar Reference Model belongs in this layer. ( src )
Interoperability requires standardized semantics based on reference terminology provided by standards development organizations, professional organizations, or government agencies. These organizations publish their content with the intention of licensing it to health IT vendors, providers, and research organizations. In the U.S., the core clinical reference terminology is based on SNOMED CT®, LOINC®, and RxNorm. Healthcare organizations must adopt and integrate subsets or modules of various reference terminology and manage references, dependencies, versions, and releases. It is important for the integrity of medical records that the change history of concepts and value sets can be managed and tracked to allow the exchange of either current or retrospective medical records. Therefore, enterprise terminology requires integrated terminology using a common representation and management. ( src )
Terminology Knowledge - The Terminology Knowledge layer is responsible for structured sets of medical terms and codes that define concepts of interest, including descriptions, dialects, language, and semantic hierarchy. SNOMED CT®, LOINC®, and RxNorm are part of this layer. It defines what valid codes or expressions may be used by higher level layers. ( src )
The Tinkar Reference Model is a logical model described herein using the Object Management Group (OMG) Unified Modeling Language (UML) 2.0 notation to describe the structure of integrated data representation and change management for biomedical terminologies. Tinkar provides an architecture that delivers integrated terminology to the enterprise and its information systems. In doing so, it addresses the differences in management and structure across reference terminology, local concepts, and code lists/value sets. This section describes classes of objects that support a common foundational framework for terminology and knowledge base systems (e.g., SNOMED CT®, LOINC®, RxNorm, HL7). An implementation of Tinkar can provide a single representation for all terminologies required in the U.S. and other countries, while also providing a better foundation for managing change. Tinkar could support the operation of a variety of systems intended to deliver knowledge management for terminology to vendors providers, and standards-development organizations like HL7. ( src )
The full LOINC database, supporting documentation and supplemental files, and the RELMA® mapping program are available for download from the Regenstrief Institute on the LOINC website (http://loinc.org). LOINC version 2.77, released on February 27, 2024, contains the following files: ( src )
Tinkar aims to adhere to the following statement from a publication about developments in clinical terminologies in the 2018 Yearbook of Medical Informatics [1]: “The benefits of the integrated terminologies in terms of homogenous semantics and inherent interoperability should, however, outweigh the complexity added to the system.” This specification provides the foundation of a knowledge architecture that is intended to integrate reference terminology from distributors (e.g., SNOMED CT®, LOINC®, RxNorm) with local concepts to support interoperable information semantics across the enterprise. ( src )
Tinkar provides the foundation of a knowledge architecture that is intended to integrate reference terminology from distributors (e.g., SNOMED CT®, LOINC®, RxNorm) with local concepts to support interoperable information semantics across the enterprise. ( src )
hl7.fhir.us.hai: Healthcare Associated Infection Implementation Guide ®© HL7 | CC0 ( src )
A type used to represent whether a term is a synonym, fully qualified name (for example: SNOMED CT ® Fully Specified Name or LOINC ® Long Common Name), definition, etc. ( src )
A user adds, modifies, or deactivates content in the terminology assets of the standard, including assets provided to client terminology systems as well as management data used only within the knowledge base (e.g., changing SNOMED CT ® relationships, inserting a concept in between two existing concepts). Note that a standard can only be modified by the standard owner . A client enterprise may add to or modify the content in an “overlay,” but those changes are part of the local enterprise assets. The client enterprise cannot actually modify the standard. ( src )
Equivalences to support semantic integration of terminologies (e.g., that a LOINC ® “system” instantiates the same relationship concept as the SNOMED CT ® “inheres in” attribute) ( src )
For example, constraints would be used to represent standard terminology artifacts, like the SNOMED CT ® Machine Readable Concept Model. Additionally, constraints could be used to ensure that the terminologies represented within a Tinkar implementation are completely and consistently queried and displayed. ( src )
HL7 Logical Model: Standardized Terminology Knowledgebase, Edition 2, published by HL7 Terminology Infrastruture Work Group. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/tinkar-ig/ and changes regularly. See the Directory of published versions ( src )
Logical composition constraints on concepts (e.g., the SNOMED CT ® concept model) ( src )
Over the past decades, biomedical terminologies have increasingly been recognized as key resources for knowledge management, data integration, and decision support [1]. Acceleration and development of Electronic Health Record (EHR) systems has precipitated the emergence of “standard terminologies” and their widespread adoption in the clinical community. These include Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), the Logical Observation Identifiers, Names, and Codes (LOINC®) and RxNorm. The availability of these clinical terminologies through the terminology services of FHIR is facilitating their usage in support of interoperability in healthcare. ( src )
SNOMED CT ® Fully Specified Name hierarchy tags are applied based on where a concept exists in a hierarchy ( src )
Since some Quality Assurance Constraints do not always indicate an error, an Allow List could also be represented as a Semantic to record concepts that are allowed to not conform to a constraint. Constraints would be represented using semantics as they are self describing and can support multiple different representations for constraints (SNOMED CT ® Expression Constraint Language, Drools, etc.). Representing Constraints as a Semantic also ensures STAMP. STAMP is versioned over time, capturing author information and allowing for tests and progress over different modules and paths. ( src )

External References

Type	Reference	Content
web	github.com	HL7 Logical Model: Standardized Terminology Knowledgebase, Edition 2, published by HL7 Terminology Infrastruture Work Group. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/tinkar-ig/ and changes regularly. See the Directory of published versions
web	protobuf.dev	Protocol Buffers (Protobuf) stands as a robust and efficient data serialization framework crafted by Google. Protocol Buffers Documentation ( https://protobuf.dev/ ). At its core, Protobuf aims to provide language-agnostic and platform-agnostic means of encoding structured data. This is achieved through the definition of data structures using a straightforward and human-readable schema language. The resulting serialization process produces compact binary data, facilitating seamless transmission between diverse systems and programming languages. One of Protobuf's key strengths lies in its extensibility, allowing developers to modify data structures over time while maintaining backward compatibility. The framework's efficiency, both in terms of space utilization and processing speed, coupled with its support for multiple programming languages, positions Protobuf as a compelling solution for applications where rapid and interoperable data exchange is a critical consideration. Further insights into Protobuf's features, applications, and advantages can be explored in the official documentation, accessible at ( https://protobuf.dev/overview/ ).
web	protobuf.dev	Protocol Buffers (Protobuf) stands as a robust and efficient data serialization framework crafted by Google. Protocol Buffers Documentation ( https://protobuf.dev/ ). At its core, Protobuf aims to provide language-agnostic and platform-agnostic means of encoding structured data. This is achieved through the definition of data structures using a straightforward and human-readable schema language. The resulting serialization process produces compact binary data, facilitating seamless transmission between diverse systems and programming languages. One of Protobuf's key strengths lies in its extensibility, allowing developers to modify data structures over time while maintaining backward compatibility. The framework's efficiency, both in terms of space utilization and processing speed, coupled with its support for multiple programming languages, positions Protobuf as a compelling solution for applications where rapid and interoperable data exchange is a critical consideration. Further insights into Protobuf's features, applications, and advantages can be explored in the official documentation, accessible at ( https://protobuf.dev/overview/ ).

Type

Reference

Content

web

github.com

HL7 Logical Model: Standardized Terminology Knowledgebase, Edition 2, published by HL7 Terminology Infrastruture Work Group. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/tinkar-ig/ and changes regularly. See the Directory of published versions

web

protobuf.dev

Protocol Buffers (Protobuf) stands as a robust and efficient data serialization framework crafted by Google. Protocol Buffers Documentation ( https://protobuf.dev/ ). At its core, Protobuf aims to provide language-agnostic and platform-agnostic means of encoding structured data. This is achieved through the definition of data structures using a straightforward and human-readable schema language. The resulting serialization process produces compact binary data, facilitating seamless transmission between diverse systems and programming languages. One of Protobuf's key strengths lies in its extensibility, allowing developers to modify data structures over time while maintaining backward compatibility. The framework's efficiency, both in terms of space utilization and processing speed, coupled with its support for multiple programming languages, positions Protobuf as a compelling solution for applications where rapid and interoperable data exchange is a critical consideration. Further insights into Protobuf's features, applications, and advantages can be explored in the official documentation, accessible at ( https://protobuf.dev/overview/ ).

web

protobuf.dev