Unattributed Code Systems

• http://unstats.un.org/unsd/methods/m49/m49.htm

Copyright Fragment

This fragment is available on index.html

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 © 2024+ HL7 International / Terminology Infrastructure. Package hl7.fhir.uv.termchangeset#1.0.0 based on FHIR 4.0.1. Generated 2025-08-14 Links: Table of Contents | QA Report | Version History | CC0 | Propose a change ( 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 )
• 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 )
• Updated versions of LOINC are distributed twice per year, in February and August. Between public releases, LOINC publishes a preview of new codes that were requested by users and processed for development by the LOINC team. 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. ( 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 )
• Copyright/Legal: This value set includes content from SNOMED CT, which is copyright © 2002+ International Health Terminology Standards Development Organisation (IHTSDO), and distributed by agreement between IHTSDO and HL7. Implementer use of SNOMED CT is not covered by this agreement ( 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 )
• 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 )
• Terminology Change Set Exchange, published by HL7 International / Terminology Infrastructure. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/termchangeset-ig/ and changes regularly. See the Directory of published versions ( src )
• This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc. Show Usage * LOINC: LOINC_277_Attachments_ChangeSet ( src )
• This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html Show Usage * Provenance participant type: Provenance/053f26d4-b805-4ff2-8c42-866459d5f1f4, Provenance/52b1a1d2-80ab-460b-b5fc-341edd35b032 and Provenance/7e4f317e-8c13-46ba-b79a-9913da2afa2c * ActReason: Provenance/053f26d4-b805-4ff2-8c42-866459d5f1f4, Provenance/52b1a1d2-80ab-460b-b5fc-341edd35b032 and Provenance/7e4f317e-8c13-46ba-b79a-9913da2afa2c * DataOperation: ChangeType, ChangeTypeVS... Show 4 more , EvidenceVariableRole_UTG247_ChangeSet, Provenance/053f26d4-b805-4ff2-8c42-866459d5f1f4, Provenance/52b1a1d2-80ab-460b-b5fc-341edd35b032 and Provenance/7e4f317e-8c13-46ba-b79a-9913da2afa2c ( src )

External References

Internal Images

20200901chroniclungdisease.png

20210301chroniclungdisease.png

ChangeSetInteractionDiagram.png

ClassDefinitions.png

ClassVersionComponent.png

ComponentTypes.png

CompositionalSemantics.png

Motivation_Why_Tinkar.png

SemanticDefinition.png

SeparationOfConcern.png

TermChangeSetDesign.png

TinkarArchitecture.png

VertexExample.png

tree-filter.png