HL7 Common Terminology Services Service Functional Model Specification Release 2

Transcription

1 ANSI/HL7 V3 CTS R /25/2015 HL7 Common Terminology Services Service Functional Model Specification Release 2 February 2015 Sponsored by: Vocabulary WG SOA WG Copyright 2015 Health Level Seven International ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

2 IMPORTANT NOTES: HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7 s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), nonexclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7 s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see for the full license terms governing the Material. HL7 Common Terminology Services Service Functional Model Release 2 Page 2 of 126

3 HL7 Common Terminology Services, Release 2: Service Functional Model Specification, Normative Version 1.0 August 28 th, 2014 Vocabulary Work Group Project Lead: Editor: Authors : Contributors: Russell Hamm (Lantana Consulting Group) Ana Estelrich (Phast) Ana Estelrich (Phast) Russell Hamm (Lantana Consulting Group) Senthil K. Nachimuthu (3M) Monica Harry (Gordon Point Informatics Ltd.) Frank Oemig (Agfa Healthcare GmbH, HL7 Germany, ebpg Project [NRW]) Ana Estelrich (Phast) Russ Hamm (Lantana Consulting Group) Nicolas Canu (Phast) Frank Oemig (Agfa Healthcare GmbH, HL7 Germany, ebpg Project [NRW]) Senthil K. Nachimuthu (3M) Anne Smith (National Committee for Quality Assurance) Ken Rubin (HP Enterprise Services) Craig Stancl (Mayo Clinic/Foundation) Kevin Peterson (Mayo Clinic/Foundation) Harold Solbrig (Mayo Clinic/Foundation) Carmela Couderc (Siemens) David Sperzel (Apelon, Inc) Giorgio Cangioli (Invitalia) HL7 Common Terminology Services Service Functional Model Release 2 Page 3 of 126

4 Preface Notes to Readers This document is the Service Functional Model (SFM) for the Normative Version (N) for the Common Terminology Services 2 (CTS2) specification, which was developed using the Service Development Framework process under the auspices of the Healthcare Services Specification Project (HSSP). Further context is given in the overview section below, but one key point to note is that the SFM provides the specification of the service's functionality, NOT the specification of a service implementation.. This is a critical distinction in terms of Service Oriented Architecture (SOA). There could be many different ways of implementing all or part of the functionality to support the behavior described in this specification. Figure 1 below shows the perimeter of this document: What the CTS2N SFM does: Lists all possible functionalities for a terminology server Lists functional profiles and the minimum operations to be implemented for conformance What the CTS2N SFM does not: Assure interoperability between different terminology servers on a technical level Specifies functionalities pertaining to the notification, identity management, security, clinical research and decision support. In October 2009, the CTS2 SFM was approved as a Draft Standard for Trial Use (DSTU). The DSTU was used as the basis for several different CTS2 Service implementations. The DSTU was also used for the Object Management Group (OMG) Request for Proposal (RFP), within the HSSP Framework, leading to the OMG CTS2 Technical Specifications for a Platform Independent Model (PIM), which are available on the OMG site at: The normative release of CTS2 addresses corrections and oversights in the DSTU, with the terms and definitions present with the Core Principles and Properties of HL7 Version 3 Models, and add enhancements based on the real-world implementations. The current CTS2N also lists the minimum of CTS2 operations necessary to implement in order to satisfy various CTS2 functional profiles. CTS2N does not change the functional scope of the PIM. For the purposes of this specification, the terms vocabulary, terminology and code system are used interchangeably. For the purposes of use in HL7 models, the differences between a terminology, ontology, taxonomy, or classification do not affect the technical means by which coded components of these are handled; they are treated the same technically in the instances of the coded data types (although implementers should be cognizant of the semantics impact on using these different resources appropriately in their models)". Changes from the DSTU The following is a summary of changes from the DSTU: Correction of the errors present in the DSTU. HL7 Common Terminology Services Service Functional Model Release 2 Page 4 of 126

5 Alignment of the terms and definitions present with the Core Principles and Properties of HL7 Version 3 Models. As Core Principles is richer in information content with regards to the description of the terms involved, only the equivalent of the information already present in the DSTU was updated. Please see section Coded Model Elements and their Vocabularies in Core Principles for an in-depth description. In cases where the DSTU provided additional clarifying information, the definition was merged with the one present in Core Principles. Removing direct specifications about the notification service, while providing references to other HSSP specifications dealing with notification. Addition of enhancements based on implementation experience not impacting the functional scope. These changes are applied to both the text and the conceptual model. Clarifications on the minimal requirements necessary in order to meet various HL7 CTS2 conformance profiles. Removed several sections and appendices and restructured the text in order to reflect the fact that the DSTU was used to issue an RFP to which PIM responded and the recommendations were addressed in the PIM. This includes: o Removal of the sections referring to Functional Overload, Metadata Discovery and Semantic Profiles, as it is a more accurate reflection of the current situation. o Removal of Section 9 Relationship to Information Content since it contains recommendations for the PIM and the PIM was already published. o Removal of Section 10 Recommendations for Technical RFP Issuance since the RFP and the PIM was published. o Removed Appendix B Glossary. Definitions can be found in the body of the text as well as in the Core Principles. o Listed the Matching Algorithms in a separate appendix (Appendix B). Added Appendix C An informative mapping between the SFM operations and the PIM Services which attempts to align the operations of the SFM and the PIM services. Acknowledgements This document is the result of the collaboration of many individuals and organizations. The terminology and standards community - all involved in the numerous meetings and teleconferences are to be thanked for their contributions and support. In addition to the listed authors, we would like to thank all the individuals and organizations who have dedicated effort and resource into furthering the development of this specification. HL7 Common Terminology Services Service Functional Model Release 2 Page 5 of 126

6 Table of Contents Preface Service Overview and Business Case CTS2 Service Overview Why terminology as a service? Scope The reason why the service was necessary Structure of the CTS 2 Service Key concepts of this specification Implementation Considerations Interface Interoperability Considerations Terminology Structure Considerations Business Scenarios Scenario Actors Terminology User Terminology Administrator Terminology-Enabled Application Developer Terminology Author/Curator Terminology Human Language Translator Terminology Mapper Terminology Provider Terminology Value Set Developer Primary Scenarios Administrative Scenarios Search/Query Scenarios Authoring/Curation Scenarios Association Scenarios Assumptions and Dependencies Dependencies on other Service Frameworks CTS Backwards Compatibility Message API Support (MAPI) General CTS API Support Operations on ISO21090 CD Datatype Considerations for Technical Specification CTS2 Implementation Guides Artifact Versioning Properties Code System Partitions Code System Supplement HL7 Common Terminology Services Service Functional Model Release 2 Page 6 of 126

7 4.1.5 HL7 Terminologies Detailed Functional Model for each Interface Administration Operations Import Code System Remove Code System Import Code System Version Remove Code System Version Import Value Set Version Remove Value Set Remove Value Set Version Import Association Version Export Association Export Code System Content Change Code System Status Search / Access Operations Code System Search / Access Value Set Search/Access Concept Domain and Usage Context Search / Access Association related queries Authoring/Curation Operations Code System Authoring/Curation Value Set Authoring/Curation Concept Domain and Usage Context Authoring/Curation Association Authoring Operations Service Information Operations Service Information Operations Profiles Introduction CTS 2 Functional Profiles Functional Conformance Subgroups CTS 2 Query Profile CTS2 Administration Profile CTS2 Authoring Profile The Services Framework Functional Model Appendix A - Relevant Standards HL7 Common Terminology Services Appendix B Examples of Matching Algorithms Appendix C Mapping between the SFM operations and the PIM Services HL7 Common Terminology Services Service Functional Model Release 2 Page 7 of 126

8 HL7 Common Terminology Services Service Functional Model Release 2 Page 8 of 126

9 1 Service Overview and Business Case 1.1 CTS2 Service Overview The goal of CTS2 is to provide a standardized interface for the use and management of terminologies. Terminologies provide the atomic building blocks of shared semantics. In a shared semantics environment, CTS2 provides a modular, common and universally deployable set of behaviors which can be used to manage sets of terminologies deployed in a service environment. CTS2 services will contribute to interoperability by supporting easy access to the foundational elements of shared semantics. It will also foster the authoring of high-quality terminologies via its authoring profile. CTS2 defines the functional requirements of a set of service interfaces that allow the representation, access, and maintenance of terminology content either locally, or across a federation of terminology service nodes. This goal is realized via the expansion of the original functional requirements outlined in HL7 s Common Terminology Service (CTS) specification with focus on the need to: 1. Establish the minimal common structural model for terminology behavior independent from any specific terminology implementation or interchange model and how it is related to metadata and data. 2. Specify information and functional models that address the relationships and use of terminology, e.g. how value sets are built and queried. 3. Specify the interactions between terminology providers and consumers. 4. Specify how mapping between compatible terminologies and data models is defined, exchanged and revised. 5. Specify how logic-based terminologies can be queried about subsumption and inferred relationships. 1.2 Why terminology as a service? The purpose of this specification is to describe the requirements for the representation, access, and maintenance of terminology content. A frequently asked question in this context is whether the problems around terminology should not be resolved using a common data repository. Historically, this approach has been tried, and with some success. However, experience shows that in order to share functionality and content, a hub and spokes model forcing terminology consumers to use a common hub is more intrusive for users and introduces adoption barriers, especially in distributed environments. This service specification has the aim to overcome such barriers by a separation of behavior (software functionality) from content (the deployed terminologies). This way, in an implementation, adopters can chose the terminology content they want and use the service functionality to provide the system behavior which is specific to their needs. 1.3 Scope Terminology services provide a consistent mechanism for accessing and managing terminology content, independent of the representational format and underlying technology stack. Terminology content represents various resources including code systems, value sets, taxonomies, and formal description logic based ontologies. The following areas that operate on terminology content areas are considered in scope for CTS2. Administration operations provide the ability to manage content as part of a terminology service. Administration functions include the ability to export and import terminologies, as well as their management. Whenever engaging in importing and exporting activities, the terminology users shall follow the licensing agreement of the terminologies which is outside the scope of CTS2N. HL7 Common Terminology Services Service Functional Model Release 2 Page 9 of 126

10 Notification services are described in separate documents published within Architecture umbrella. the HSSP Service Search / Query operations provide the ability to find concepts based on search criteria. This includes restrictions to specific associations or other attributes of the terminology, including navigation of associations for result sets. This represents the primary utility for using terminology content in a number of application contexts and includes capabilities for searching and querying terminology content as well as representing terminology content in the appropriate formats. Authoring / Maintenance operations provide the ability to create and maintain terminologies. From a terminology service perspective, this would include the appropriate operations to add, change, or delete concepts and associations and processing change events from various terminology providers. In addition to the operations categories such as query/search, administration and authoring, the CTS2 operation can also be grouped according to the content that they handle such as associations, value sets, and bindings. CTS2 is intended to allow the look up and management of a wide variety of terminology components, including, but not limited to, Concepts, Associations, and Value Sets. Associations operations provide the ability to map concepts and the concept's associated attributes from a source terminology to a concept in a target terminology, or create relationships between concepts within a single code system as well as the ability to manage these associations (such as maintaining or remove them). Value Set operations provide the ability to define, manage, remove and use sets of coded concepts in a terminology-enabled application. Bindings: operations which provide the ability to resolve content bound to a specific Concept Domain and/or Jurisdictional Domain (Binding Realm). This also includes the ability to query, create, maintain and remove Concept Domains, Jurisdictional Domains, and Usage Contexts. At the functional level, the service interface will explicitly allow the query, definition, publication, and modification of the different terminology components that are required of terminologies and terminology services. Conformance profiles are defined within this specification and are intended to focus CTS2 implementations to address specific classes of functionality and pre-define minimum trait sets for each specified functional class. This will also allow for performance optimizations to be defined for terminology searches and queries (which are implementation considerations considered in the CTS2 technical specification as a result of OMG RFP process). The scope of this functional specification covers support for multiple terminology sources and a federated terminology environment. The notification, user authentication, licensing and security services are not part of the CTS2 interface specifications but exist as separate services used by CTS2 and are part each individual implementation specification. At a minimum, it is expected that CTS2 will make use of an Entity Identification Service, and Notification service which in turn will reference a set of Security Services. CTS2 itself will make use of the Security HL7 Common Terminology Services Service Functional Model Release 2 Page 10 of 126

11 Services to implement its own functional profile restrictions. Services such as a Decision Support Service, Clinical Research Functional Query, and Resource Locate and Update Service may find the use of the CTS 2 service a key resource in improving content disambiguation (see figure below). class CTS2 HSSP Service Architecture Retriv e_locate_update_serv ice (Notification included) Common_Terminology_Serv ices_2 Entity_Identification_Serv ice Decision_Support_Serv ice Clinical_Research_Filtered_Query Security_Serv ices Figure CTS2 Service Accessed by a Single Organization For informative purposes only, the Object Management Group (OMG) has two specifications on notification, namely: Notification Service Specification (NOT) 1 Data Distribution Services Framework (DDS) The reason why the service was necessary The original HL7 CTS specification deliberately avoided issues related to terminology distribution, versioning and authoring; it was also focused on static value sets and did not fully address the definition or resolution of value set definitions issues that are now in scope. CTS implementers have recognized that the existing HL7 CTS standard serves an important role in defining the common functional characteristics that a terminology service (either internal or external) must be able to provide. However, these implementers have realized that CTS fails to address many of the maintenance, versioning and representation requirements necessary for a complete terminology service. In addition, CTS was deliberately silent on how vocabulary content should be structured. This silence resulted in CTS implementations that are inconsistent in their representations of vocabularies. CTS2 includes a conceptual model that is intended to represent a superset of the metamodels of terminologies. CTS2 will enhance the capabilities of the original CTS specification for subsetting and mapping, and extend the specification into domains such as terminology distribution, authoring, and versioning. Standardizing HL7 Common Terminology Services Service Functional Model Release 2 Page 11 of 126

12 terminology service functionality at this level will allow applications using terminology services to build on a common infrastructure and improve interoperability at the terminology layer across applications. CTS2 provides the terminology community with a defined set of standards interfaces that can be used to evaluate terminology source structure, terminology source content, and terminology tools. 1.5 Structure of the CTS 2 Service To provide the maximum implementation flexibility, these specifications define several functional profiles for CTS2. These profiles serve to subset and focus the functionality of a CTS2 implementation to accomplish a targeted set of tasks. The functional profiles can be grouped in three larger functionalities: Query Profile The CTS2 Query profile outlines functional coverage necessary for a service to declare itself as being a conformant CTS2 service. The CTS2 Query Profile includes capabilities for searching and querying terminology content. Terminology Administration Profile The CTS2 Administration profile defines the functional operations necessary for terminology administrators to be able to access and make available terminology content obtained from a Terminology Provider. Terminology Administrators are required to interface with Terminology Provider systems in order to obtain terminology content, load terminology content on local Terminology Servers, as well as export terminology content from a central server to users Terminology Authoring Profile The CTS2 Terminology Authoring profile defines the functional operations necessary for terminology authors to apply structured changes to existing terminology content Key concepts of this specification CTS2 deals with three major terminology components: concept, code system and value set. A Concept is a unitary mental representation of a real or abstract thing; an atomic unit of thought unique to a given Code System which may have synonymous terms. It may be a singleton, or may be constructed of other concepts (i.e. post-coordinated). Concepts in HL7 are manipulated via vocabulary objects called Concept Representations. Concept Representations can take on a number of different roles in the structure and processing of vocabulary in HL7; these roles and functions are described further in the document. A Code System is a managed collection of Concept Representations, including codes, but sometimes more complex sets of rules and references. A minimal Code System provides a flat list of at least two concepts and may not differentiate concept code and concept designation. Large Code Systems may contain hundreds of thousands of concepts, concept definitions, concept symbols (codes or other designations) and concept relationships. A Value Set represents a uniquely identifiable set of valid concept identifiers not necessarily stemming from the same Code System, where any concept identifier in a coded element can be tested to determine whether it is a member of the Value Set at a specific point in time. A concept identifier in a Value Set may be a single concept code or a post-coordinated expression of a combination of codes. Value Sets exist to constrain the permissible content for a particular use, e.g. for use in analysis, display to a user, etc. For HL7, value sets constrain the permissible content for a coded element in an HL7 information model or data type specification. Thus, at implementation time, a coded element must be associated with a list of codes that represent the possible concepts that can be represented in that element at the time of use. CTS2 provides functionality to systems dealing with these definitions. This specification also comprises the HL7-specific HL7 Common Terminology Services Service Functional Model Release 2 Page 12 of 126

13 notion of a concept domain. An HL7 Concept Domain is a named category of like concepts (a semantic type), for example, the Concept Domain named 'HumanLanguage' carries the description, "Codes for the representation of the names of human languages". 1.6 Implementation Considerations Interface Interoperability Considerations CTS2 is an interface specification, not an implementation specification. As such, it is intended to facilitate the development of an implementable interoperability mechanism for terminology resources. There is nothing inherent in the CTS2 specification that restricts its use to be within a single organization. To the contrary, CTS2 is intended to expose a single or multiple terminology sources for use by various applications that may or may not be within the same organization, providing a standardized method for terminology access. Figure CTS2 Service Accessed by a Single Organization CTS2 allows terminology interoperability between organizations. While coded concepts from structured terminology can unambiguously identify the concept(s) being communicated, a standard way of structuring and communicating those coded entries is required. CTS2 can be used in an inter-organizational setting where each organization maintains its own security and application specific provisions. CTS2 enables consistent access to a high availability or international standard terminology resource made available to subscribers via a CTS2 interface. HL7 Common Terminology Services Service Functional Model Release 2 Page 13 of 126

14 Figure Multi Organizational access to a CTS2 Service Since terminology content is not static, CTS2 also provides functionality to maintain and update terminology content. Updates and update requests to terminology sources need to be reviewable and traceable over time. Often, a terminology source provider will want to maintain the gold standard or the master release of a code system, as to maintain a consistent standard terminology that can be used across multiple organizations and realms. Notwithstanding, users of any given source terminology may wish to extend that terminology for their own use, and may even wish to recommend the addition of local extensions to the terminology provider to be included as part of the release. CTS2 provides a mechanism to allow for terminology users to extend a given terminology, share those extensions with others, or feed those extensions back to the source provider in a structured format to be reviewed, modified as necessary, and fed into a CTS2 server as input to update the source terminology with the content contained in the change request. As depicted in Figure 1.6-2, Organization A is applying its own local extensions to a terminology resource being served by a CTS2 service. In addition to also applying its own local extensions, Organization B is feeding some of those local extensions back to the terminology provider as suggestions to be included in the next release of the code system. HL7 Common Terminology Services Service Functional Model Release 2 Page 14 of 126

15 Figure Multi Organization Access with Write Permissions by One Organization HL7 Common Terminology Services Service Functional Model Release 2 Page 15 of 126

16 Terminology Structure Considerations Controlled terminologies are developed with specific purposes and use cases in mind, and as such are structured very differently. The format of any given terminology may range from a simple flat list of concepts to more complex poly-hierarchies. The variety of attributes of the entities of code systems vary as well. Even the formats of the identifiers are different, with some concept identifiers being meaningless identifiers and others having explicit or implied meaning. The functional components of CTS2 must be able to operate on this broad spectrum of terminology sources. At a minimum, CTS2 must specify a concept-based terminology model that is capable of representing most varieties of structured terminologies. The basic requirements of the CTS2 terminology model are illustrated in the CTS2 Conceptual Model below. This model outlines the various components of terminologies and the cardinality of the relationships between them, but does not dictate particular levels of data normalization or other technical details of implementation. The CTS2 Conceptual Model describes a logical (analysis level) model with the intent that most - if not all - key attributes that affect terminology behavior have been described. It is the intent of this model to support both well-behaved and more arbitrarily-defined code systems. Several aspects of handling terminologies are supported by the conceptual model. For example, code systems, concepts and value sets have specific version classes. Additionally, curation has been supported explicitly by inclusion of a number of classes that permit the versioning of key terminology entities. Specific concerns of audit trail / history have not been explicitly represented. In a typical implementation, it is likely that more than one status value may be needed on certain classes, to cover different purposes (e.g. curation vs. actual business state of the class). This level of detail is fully resolved in the detailed design specification (Platform Independent Model, PIM), as will the actual values of the various state related attributes. The CTS2 Conceptual Model also specifies identifiers which have been included to ensure uniqueness and can be used for system generation, especially on some of the lower level classes. The purpose of this model is to represent the semantics of the key requirements of CTS2 and it is intended to assist with understanding the expected behaviors and interactions of terminology components. The CTS2 Conceptual Model is derived from business requirements, and as such was rather meant to reflect these requirements and not intended to explicitly provide implementation level detail. For example, the presence of identifier or version identifier attributes in classes in the Conceptual Model is not intended to indicate that a unique identifier property will be assigned by the code system author or that identifiers are persisted across versions of a code system. The intent of this model is NOT to serve as an implementation blueprint. Implementation guidance is provided in Platform Independent Models (PIMs) and Platform Specific Models (PSMs), and terminology-specific implementation guides. Also, the status code sets for the model classes are undefined in this specification. It is explicitly intended that these are left to the technical specification. The values need to be determined by the requirements for maintaining metadata. The primary reason is that this service is designed for handling of many different kinds of code systems, and these may have different state models. Technical specifications must define minimum explicit state models for the purposes of interoperability. The basic default minimum assumption is that the concept of active and inactive states is covered, whereby inactive instances would not show up in normal searches. However, these restrictions are seen as realm or organization specific configuration settings. Individual deployments may also use an additional separate curation state (e.g. pending, approved HL7 Common Terminology Services Service Functional Model Release 2 Page 16 of Health Level Seven International. All Rights Reserved January 2015

17 50 55 etc.). This is not explicitly covered in this specification since this would be organization specific and often handled by separate workflow tools. Several classes in the model include an attribute for provenance information, named "provenancedetails". This should be more concretely defined in the technical specifications, but should include such information as: author, copyright, generation type, source and source type, approval information, whether it is modifiable, and so on. This may vary to some degree by the class to which it applies, but a consistent structure should be defined where possible. HL7 Common Terminology Services Service Functional Model Release 2 Page 17 of 126

18 class CTS2N Conceptual Model restricts Slot «type» ConceptValueSetMembership 0..* 0..* AnnotationAttribute CodedConcept slot_value 0..* 1 1..* 0..* effectivedate [0..1] code ValueSetVersion ValueSet slot_name valueoverride [0..1] 1..* slot_datatype versionid id effectivedate name [0..1] 1..* releasedate [0..1] description [0..1] previousversionid [0..1] rulesetid [0..1] CodeSystemVersion 1..* rulesetversionid [0..1] status versionid supportedlanguage [0..*] «abstract» statusdate [0..1] Includes terminology effectivedate These identify the defined or status CodeSystemEntity isimmutable associations and mappings. previousversion [0..1] "allowable" properties and statusdate [0..1] Type may indicate: map, releasedate [0..*] id [0..1] associations that may be provenancedetails [0..1] rules based, lexical etc. releaseformat [0..*] applied to concepts within a author [0..1] May be specialized for releaselocation [0..1] code system. contentdefinition [0..1] different properties. supportedlanguage [0..*] 1 status CodeSystem specializesdomain statusdate [0..1] 1..* 0..* description [0..1] id 0..* AssociationType provenancedetails [0..1] description [0..1] 0..* 0..* full [0..1] administrativeinfo [0..1] typecode 1 ConceptDomain DefinedEntityProperty local [0..1] description [0..1] ContextBinding 0..* 0..1 id copyright [0..1] id associationkind effectivedate 0..* 0..1 name source [0..1] name forward [0..1] rulesetid [0..1] description [0..1] description [0..1] reverse [0..1] bindingqualifier [0..1] status 0..* status isdirected provenancedetails [0..1] statusdate [0..1] statusdate [0..1] rulesetid [0..1] provenancedetails [0..1] 1 provenancedetails [0..1] provenancedetails [0..1] 0..* 1 rulesetid [0..1] EntityPropertyVersion 1 effectivedate 0..* DesignationType value DesignationValueSetVersionMembership 1 0..* JurisdictionalDomainAssociation status isdefault [0..1] statusdate [0..1] status 0..* effectivedate [0..1] language [0..1] statusdate designationoverride [0..1] provenancedetails [0..1] 0..* UsageContext CodeSystemSupplement 0..* id id name 1 name [0..1] CodeSystemEntityVersion description [0..1] JurisdictionalDomain description [0..1] 0..* 0..* 0..1 status Designation provenancedetails [0..1] 0..* 1 0..* versionid id statusdate [0..1] effectivedate effectivedate name id targetcodesystemid previousversion [0..1] description [0..1] name [0..1] 0..* rendering [0..1] status description [0..1] statusdate [0..1] issourceof AssociationInsideCodeSystem ispreferred [0..1] provenancedetails [0..1] istargetof 0..* associationkind preferredusagetype [0..1] description [0..1] status language [0..1] 0..* statusdate [0..1] format [0..1] associationproperty [0..*] status EntityVersionCodeSystemVersionMembership statusdate [0..1] designationkind [0..1] 1..* MapSetVersion issourceof istargetof versionid effectivedate previousversion [0..1] releasedate [0..*] releaseformat [0..*] releaselocation [0..1] supportedlanguage [0..*] status statusdate [0..1] description [0..1] provenancedetails [0..1] full [0..1] local [0..1] copyright [0..1] source [0..1] 0..* «abstract» MapSetEntity id [0..1] MapSet 1..* id description [0..1] administrativeinfo [0..1] MapSetEntityVersion versionid effectivedate 0..* previousversion [0..1] status statusdate [0..1] provenancedetails [0..1] description [0..1] 0..* AssociationInMapSet associationkind status statusdate [0..1] associationproperty [0..*] EntityVersionMapSetVersionMembership Figure CTS2 Conceptual Model HL7 Common Terminology Services Service Functional Model Release 2 Page 18 of Health Level Seven International. All Rights Reserved January 2015

19 CTS2 Conceptual Model Classes Concept A Concept is a unitary mental representation of a real or abstract thing an atomic unit of thought. It should be unique in a given Code System. A concept may have synonyms in terms of representation and it may be a singleton, or may be constructed of other concepts (i.e. post-coordinated concepts). Concepts, as abstract, language- and context-independent representations of meaning, are important for the design and interpretation of HL7 V3 models. They constitute the smallest semantic entities on which HL7 V3 models are built. The authors and the readers of a model use concepts and their relationships to build and understand the models; these are what matter to the human user of HL7 V3 models. The rest of the vocabulary machinery exists to permit software manipulation of these units of thought Concept Representation A Concept Representation is a vocabulary object that enables the manipulation of a concept in HL7. A Concept representation exists in some form that is computable, and can be used in HL7 models and specifications. Concept representations can take on a number of different roles in the structure and processing of vocabulary in HL7; these roles and functions are described below Concept Identifier A Concept Identifier is a Concept Representation that may be published by the code system author, and unambiguously represents the concept internally within the context of that code system. Such an object used for identification, when combined with the unique identifier of the code system itself (a machine-processable unique string), provides a globally unique and language-independent identification for the particular concept. This globally unique identification can be used in transactions and data records that span both space and time. In some cases, multiple synonymous identifiers may be present for the same concept Concept Code A Code is a Concept Representation published by the author of a Code System as part of the Code System. It is the preferred unique identifier for that concept in that Code System for the purpose of communication (preferred wire-format identifier), and is used in the 'code' property of an HL7 coded data type. Codes are sometimes meaningless identifiers, and sometimes they are mnemonics that imply the represented concept to a human reader. In Code Systems that contain more than one Concept Identifier, the one that should be used in HL7 as the Code should be explicitly declared as part of the HL7 Code System registration process. The meaning of a Code within a particular Code System entity is valid only within that Code System. For example, each table having enumerated codes in the HL7 Version 2.x standards represents a different Code System, since codes are sometimes used in different Code Systems to have different meanings. One example is the code "M" in the v2.x table 0001 Administrative Sex which signifies "Male," whereas the code "M" in the in the v2.x table 0002 Marital Status signifies "Married". Another example is the code "1609-7" which signifies the Native American tribe "Sioux" in the Race & Ethnicity CDC Code System( ), and the code "1609-7" which signifies "Prolactin^1.5H post dose insulin IV" in the LOINC Code System ( ). Codes do not have explicit semantics without their Code Systems, and cannot be referenced without identifying the code system in which they are published HL7 Common Terminology Services Service Functional Model Release 2 Page 19 of Health Level Seven International. All Rights Reserved January 2015

20 CodedConcepts are represented by attributes including: A code that according to terminology best practices is unique within the context of the code system, although some code systems do allow reuse of codes over time For more information on Code System Versions, please see section Concepts and Codes of Core Principles and Properties of V3 Models Designation A Designation is a Concept Representation that may be published by the code system author, and is a language symbol for a concept that is intended to convey the concept meaning to a human being. A Designation may also be known as an appellation, symbol, or term. A designation is typically used to populate the 'display' property of an HL7 coded data type. The designation identifier must uniquely map to a given text string, bitmap, etc. within the context of the containing concept. In some terminologies, every unique text string will have exactly one identifier, meaning that the identifier is unique to the designation. In other terminologies, there may be more than one identifier for a given designation, which means that the same identifier may occur under more than designation. Service software must not assume either model. For example, in SNOMED CT, the concept of fever has the fully specified name of fever (finding), a preferred name of fever, and synonyms of febrile and pyrexia. These are all designations for the concept of fever. In the terminology model, designations are represented by the Designation class. Each designation is a representation of the concept and may be assigned a unique designation identifier. In most instances, concept designations are human readable forms, but machine readable forms may also be present. The Designation class is defined by the following attributes: A unique identifier (id) for the designation in the cases where this exists. A name (name) for the designation. An optional graphical representation (rendering) that allows for the use of an image or sound or other non-textual representation as the designation rather than text, if this is the case. A description (description) for the designation. An optional (ispreferred) attribute that identifies whether an attribute has a type of usage preference. A repeatable preferences structure (preferredusagetype) which works in combination with ispreferred to outline the type of usage that a designation is preferred for. This allows identification of whether the designation is preferred for combinations of language, UI, e- prescribing, patient friendliness, etc. The human language (language) in which the designation is expressed. A format (format) for the designation. An example would be UTF-8 encoding. A status (status) to identify the state (mainly for curation). A status date (statusdate) to identify the date the status was set to its current value (for curation). A type (designationkind) that describes the nature of the designation (e.g. human readable text vs. BLOB, etc.) Designation Type Concept designation types are a specific type of property that may be defined for a CodeSystemEntity. This class allows for identification of the "type" of a designation, i.e. a designation category. The set of HL7 Common Terminology Services Service Functional Model Release 2 Page 20 of 126

21 designation types can be defined under DefinedEntityProperty and can contain designation categories like term, picture, symbol or their specializations such as preferred term, long name, short name CodeSystem A Code System is a managed collection of Concept Representations, including codes, but sometimes more complex sets of rules and references, optionally including additional Concept Representations playing various roles including identifiers of the concepts, designations, etc. Code systems are often described as collections of uniquely identifiable concepts with associated representations, designations, associations, and meanings. Examples of code systems include ICD-9-CM, SNOMED CT, LOINC, and CPT. To meet the requirements of a code system as defined by HL7, a given concept identifier must resolve to one and only one meaning within the code system. In the HL7 Terminology Model, a code system is represented by the Code System class. Although code systems may be differentially referred to as terminologies, vocabularies, or coding schemes, HL7 considers all such collections Code Systems for use in Version 3 as described in this document. At a minimum, code systems have the following attributes: An identifier that uniquely identifies the code system. For HL7 conformant model instances, this SHALL be in the form of a UID. This UID will take one of four forms: an ISO OID, a UUID, an HL7 RUID or a URI. If the code system is identified by an OID, this OID SHALL be registered in the HL7 OID registry, unless the code system is a local code system, in which case it MAY be registered in the HL7 OID Registry. The HL7 OID Registry may be found at The HL7 OID Registry will also contain the corresponding URIs in addition to the OIDs following a recent decision of the Vocabulary group. A description consisting of prose that describes the code system, and may include the code system uses, maintenance strategy, intent and other information of interest. Administrative information proper to the code system, independent of any specific version of the code system, such as ownership, source URL, and copyright information The Concept Representations in a code system may also be augmented with additional text, annotations, references and other resources that serve to further identify and clarify what a concept is. A code system also may contain assertions about relationships that exist between its concepts CodeSystemVersion Code systems evolve over time. Changes occur because of corrections and clarifications, because the understanding of the entities being modeled evolves (e.g., new genes and proteins are discovered), because the entities being modeled change (e.g., new countries emerge; old countries are absorbed), or because the assessment of the relevance of particular entities within the knowledge resource change (e.g., the addition of new parent-child relationships to existing codes in SNOMED CT). Depending upon how well the code system adheres to good vocabulary practices, the changes in meaning could be significant. Therefore it can be important to know which version of a given code system was used in the creation of HL7 model instances; the recording of coded data or in some cases the creation of the HL7 models. For more information on Code System Versions, please see section Code System Versions of Core Principles and Properties of V3 Models. HL7 Common Terminology Services Service Functional Model Release 2 Page 21 of 126

22 185 A CodeSystemVersion is a static snapshot of a CodeSystem at a given point of time and in force for a period until the subsequent version supersedes it. It enables identification of the versions of the code system in which any given concept can be found. A CodeSystemVersion is represented by attributes including: A version identifier (versionid) that uniquely identifies each version of a code system. The start date (effectivedate) when the version is deemed to be valid for use. This is specific to the usage context in which the service is used (e.g. for a particular terminology server instance), so can be used for historical date based queries to establish when a version was in use. Identification of the previous version (previousversionid) of the code system, which enables tracking of sequencing of versions, and identification of missing versions on a server instance. A set of dates (releasedates) that represent the date when the version of the code system became available within a particular domain (could be universal, realm specific or for an organization). The formats (releaseformats) in which the version of the code system is available in. The official location (releaselocation) at which the version of the code system is made available. The different human languages (supportedlanguages) supported by the code system in this version. A status (status) to identify the state of the code system version (mainly for curation). A status date (statusdate) to identify the date the status was set to its current value (for curation). A description (description) that describes the code system version. Provenance information (provenancedetails) relating to the release (version) of the code system. A name (full) that is the official name of the code system as assigned by the terminology provider at the time of the version being issued. A name (local) to which the code system is normally referred to for the life of this version. Copyright information (copyright) pertaining to the release (version) of the code system. An attribute (source) that identifies the authority or source of the code system in this version. i.e. IHTSDO CodeSystemEntity A CodeSystemEntity is an abstract class that represents either a CodedConcept or an association (CodeSystemEntityVersionAssociation) within an overall ontology for a code system. This allows for property and version information to be defined for any of the subclasses of code system entity using a consistent structure. CodeSystemEntity is represented by attributes including: 220 An optional unique identifier (id) for the Code System Entity. Note that most of the "interesting" information and relationships relating to the Code System Entity (and its subclasses) is versioned, and as such is identified at the level of the Code System Entity Version. HL7 Common Terminology Services Service Functional Model Release 2 Page 22 of 126