CTS 2 Service Functional Model

Service Functional Model Specification

Common Terminology Services 2(CTS 2)

Version 0.3

10-April-2008

Project Leads	Russell Hamm rhamm@apelon.com (Apelon, Inc.) Craig Stancl stancl.craig@mayo.edu (Mayo Clinic/Foundation)
Editors	John Carter John.X.Carter@ge.com(GE Healthcare) Sundak Ganesan dsq3@CDC.GOV(CDC) Russell Hamm rhamm@apelon.com (Apelon, Inc.) Senthil Nachimuthu snachimuthu@mmm.com(3M Health Information Systems Division) Craig Stancl stancl.craig@mayo.edu (Mayo Clinic/Foundation)
Contributors	Harold Solbrig hsolbrig@apelon.com(Apelon, Inc.) James Buntrock buntrock.james@mayo.edu(Mayo Clinic/Foundation)

Preface

Notes to Readers

This document is the Service Functional Model for the Common Terminology Services 2 specification, which is specified under 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 a Service Interface specification, NOT the specification of a Service implementation. This is a critical distinction in terms of Service Oriented Architecture. There could be many different ways of implementing all or part of the functionality to support the behavior described in this specification.

NOTE: For the purposes of this specification, the terms vocabulary and terminology are interchangeable.

Changes from Previous Release

This is the first public release of this document.

Acknowledgments

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, the following individuals are acknowledged for their contributions and support during the development of this specification.

• The HL7 Vocabulary Technical Committee
• Dr. Christopher Chute (Mayo Clinic/Foundation)
• John Koisch (OCTL Consulting)
• Ken Rubin (EDS)
• Harold Solbrig (Apelon, Inc.)

Note: Sections of this document in blue indicate text that is consistent across HSSP specifications.

Overview

Introduction and Scope

The Service Specification Development Framework Methodology is the methodology followed to define HSSP specifications. The methodology sets out an overall process, and also defines the responsibilities of the Service Functional Model (SFM). Section 2 sets out the business context for this particular specification, but firstly it is important to understand the overall context within which this specification is written, i.e. its purpose from a methodology standpoint.

HL7-OMG Healthcare Services Specification Project (HSSP)

The Healthcare Services Specification Project (HSSP) [http://hssp.wikispaces.com] is a joint endeavor between Health Level Seven (HL7) [http://www.hl7.org] and the Object Management Group (OMG) [http://www.omg.org]. The HSSP was chartered at the January 2005 HL7 meeting under the Electronic Health Records Technical Committee, and the project was subsequently validated by the Board of Directors of both organizations.

The HSSP has several objectives. These objectives include the following:

• To stimulate the adoption and use of standardized “plug-and-play” services by healthcare software product vendors
• To facilitate the development of a set of implementable interface standards supporting agreed-upon services specifications to form the basis for provider purchasing and procurement decisions.
• To complement and not conflict with existing HL7 work products and activities, leveraging content and lessons learned from elsewhere within the organization.

Within the process, HL7 has primary responsibility for (1) identifying and prioritizing services as candidates for standardization; (2) specifying the functional requirements and conformance criteria for these services in the form of Service Functional Model (SFM) specifications such as this document; and (3) adopting these SFMs as balloted HL7 standards. These activities are coordinated by the HL7 Services Oriented Architecture SIG in collaboration with other HL7 committees, which currently include the Vocabulary TC and the Clinical Decision Support TC.

Based on the HL7 SFMs, OMG will develop “Requests for Proposals” (RFPs) that are the basis of the OMG standardization process. This process allows vendors and other submitters to propose solutions that satisfy the mandatory and optional requirements expressed in the RFP while leaving design flexibility to the submitters and implementation flexibility to the users of the standard. The result of this collaboration is an RFP Submission, which will be referred to in the HSSP process as a Service Technical Model (STM). HL7 members, content, and concerns are integral to this process, and will explicitly included in the RFP creation and evaluation process.

It is important to note that the HL7 SFMs specify the functional requirements of a service, the OMG RFPs specify the technical requirements of a service, and the STM represents the resulting technical model, except as specified below. In many cases, SFMs describe an overall coherent set of functional capabilities and / or define a minimum set of behaviors necessary to guarantee a minimal level of service in a deployment scenario. These capabilities may be specialized or subdivided from both functional and informational (semantic) perspectives to provide conformance “profiles” that may be used as the basis for the OMG RFP process and/or implemented.

Service Definition Principles

The high level principles regarding service definition that have been adopted by the Services Specification Project are as follows:

• Service Specifications shall be well defined and clearly scoped and with well understood requirements and responsibilities.
• Services should have a unity of purpose (e.g., fulfilling one domain or area) but services themselves may be composable.
• Services will be specified sufficiently to address functional, semantic, and structural interoperability.
• It must be possible to replace one conformant service implementation with another meeting the same service specification while maintaining functionality of the system.

A Service at the SFM level is regarded as a system component; the meaning of the term “(system) component” in this context is consistent with UML usage.A component is a modular unit with well-defined interfaces that is replaceable within its environment. A component can always be considered an autonomous unit within a system or subsystem. It has one or more provided and/or required interfaces, and its internals are hidden and inaccessible other than as provided by its interfaces.

Each Service’s Functional Model defines the interfaces that the service exposes to its environment, and the service’s dependencies on services provided by other components in its environment. Dependencies in the Functional Model relate to services that have or may in future have a Functional Model at a similar level; detail dependencies on low-level utility services should not be included, as that level of design is not in scope for the Functional Model.

The manner in which services and interfaces are deployed, discovered, and so forth is outside the scope of the Functional Model. However, HSSP Functional Models may reference content from other areas of HSSP work that deals with architecture, deployment, naming and so forth. Except where explicitly specified, these references are to be considered informative only. All other interactions within the scope of the scenarios identified above are in the scope of the Functional Model.

Reference may be made to other specifications for interface descriptions, for example where an interface is governed by an existing standard.

Overall disclaimers

• Examples are illustrative and not normative unless otherwise specified
• The scope of information content of HSSP service specifications is not limited to HL7 content models. At a minimum, however, specifications should provide a semantic profile as part of its conformance profile to provide support for HL7 content models where applicable.

Context of this SFM within HSSP Roadmap

As described above, the purpose of an HL7 SFM is to identify and document the functional requirements of services important to healthcare. Accordingly, this SFM seeks to define the functional requirements for a set of Common Terminology Services, which provides a set of capabilities to represent, retrieve and manage terminology resources. Once adopted as an HL7 standard, it is anticipated that this SFM will serve as the basis for one or more OMG technical specifications. It is expected that CTS 2 will effectively leverage other HSSP specifications to enhance overall functionality in integration environments.

In particular, the CTS 2 service is expected to interact with one or more infrastructure services as outlined in the following diagram:

<<diagram on relationship of CTS 2 to other HSSP services>>

This specification will provide an important foundation component for many healthcare interoperability scenarios, both within and across organizations. Although in many business scenarios CTS 2 may be used in conjunction with other services, it has been specified to provide stand alone capabilities when referenced solely for terminology access and management purposes.

Service Overview and Business case

Service Overview

CTS 2 Service Description and Purpose

The goal of the Common Terminology Services 2 (CTS 2) Specification is to expand on the original functionality developed in HL7’s Common Terminology Service (CTS) Specification. CTS 2 defines the functional requirements of a set of service interfaces to allow the representation, access, and maintenance of terminology content either locally, or across a federation of service nodes.

The CTS 2 specification strives to expand on the original functionality developed in HL7’s Common Terminology Service specification, specifically looking to:

1. Establish the minimal common structural model for terminology, and how it is related to meta-data (information about data) and data (the information itself)
2. Integrate into CTS 2 the functional coverage outlined in the existing CTS specification.
3. Specify both an information and functional model that addresses the relationships and use of terminology, e.g. how value sets are built and queried, and how terminological information is validated.
4. Specify the interactions between terminology providers and consumers – how terminology users can submit unambiguous requests for corrections and extensions and how revisions to content are identified, distributed and integrated into running systems.
5. Specify how mapping between compatible terminologies and data models is defined, exchanged and revised.
6. Specify how logic-based terminologies can be queried about subsumption and inferred relationships.
7. Engage broad community participation to describe the dimensions of use and purpose for vocabularies and value sets. This aim will attempt to harmonize these efforts in terms of models, use cases, and requirements for creating a functional model for CTS 2.

Scope

To address the above stated purpose of CTS2, the scope of functionality addresses several broad categories.

Terminology services represent functions necessary to manage, search, and access terminology content. Terminology services provide a consistent specification for using terminology content independent of the terminology content and underlying technology stack. Terminology content represents various resources including lists, value sets, taxonomies, and formal description logic based ontologies. The following thematic areas are considered as part of CTS 2.

Administration: This is a set of functions that provide the ability to manage content as part of a terminology service. Administration functions include load terminology, export terminology, activate terminology, and retire terminology. These functions are generally protected and accessible by service administrators with appropriate authorization.

Search / Query: This is a set of functions that 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.

Association / Mapping: This is a set of functions that provide the ability to map a concept code and its attributes of a source terminology to a concept in a target terminology, or create associations between concepts within a single code system.

Authoring / Maintenance: This is a set of functions that provide the ability to create and maintain content. From a terminology service perspective would include the appropriate APIs to add, change, or delete concepts and associations. This would also include the processing of change events from various terminology providers.

CTS 2 is intended to allow the lookup and management of a wide variety of terminology components, including, but not limited to, Concepts, Relationships, and Value Sets. 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 will be defined which may limit specific implementations of CTS 2 to a specific class of functionality and pre-define minimum trait sets for each specified functionality class, such as query, authoring and mapping. This will also allow for performance optimizations to be defined for terminology searches and queries (which are implementation considerations which will be considered in the technical specification arising from the OMG RFP process).

The scope of this functional specification covers support for multiple terminology sources and a federated terminology environment.

The reason why the service is necessary

The original HL7 CTS specification deliberately steered clear of developing a generic model of terminology, and avoided issues related to terminology distribution and versioning. The value set, or sub-setting section of CTS focused on static value sets and didn’t fully address the definition or resolution of value sets that define post-coordinated expressions – issues that are now in scope due to the maturing Terminfo/SNOMED Concept Model Working Group (CMWG) model.

Adopting organizations have recognized the existing HL7 CTS standard serves an important role in defining the common functional characteristics that an external terminology must be able to provide. However, these organizations are also realizing that CTS fails to address many of the issues that are required for a truly interoperable “semantics of terminology”.

While CTS defined a standard API to access terminology source content, in practice it is often necessary to implement those APIs specific to the target source terminology being accessed. This is necessary because CTS does not – by intention - define a “normal form” model that the terminology content can be represented in. Controlled terminologies are developed with specific purposes and use cases in mind. As such, different terminology sources define different model attributes and structure, specific to the purpose and intent of each source.

CTS 2 will be a commonly accepted standard for terminology services that enhances the capabilities of the initial CTS specification for sub-setting and mapping, and extends the specification into domains such as terminology distribution, authoring, versioning, and classification. Standardizing the 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.

CTS 2 will provide the terminology community with a defined set of standards that can be used to evaluate terminology source structure, terminology source content, and terminology tools.

Structure of the Service

• Describe the service in macro and its overall organization
• Include an executive summary of the overall service capabilities (e.g., a concise overall description of the responsibilities of this service, and the roles (if any) that it plays in interaction patterns such as client-server, service-to-service, etc.)
• Discussion of Maintenance Interfaces and Service Management
  • The service Functional Model may include much or only a little of such content; its nature and role is discussed here.
  • If no or very little maintenance and management functionality is included, then the way in which this service’s environment is assumed to provide these capabilities should be discussed in the following subsection.
• Enumeration of the interfaces that are known to be needed, with a concise description of each (detailed descriptions are given in Secti3on 5 below)
• Grouping, if any, into defined levels of conformance for the service

Service specification teams may choose to identify profiles of functionality and assign a name to those profiles. Profiles will clarify those mandatory and optional service capabilities that will be included in a service instance. A minimum profile MUST be identified which identifies a minimum set of operations. Other profiles may build on the minimum set, i.e. MUST include the minimum profile.

Enumerate (but do not elaborate) each conformance profile and cite the relationship to prior examples.

Indicate which portions are covered in this version and expected future versions.

Implementation Considerations

Interface Interoperability Considerations

CTS 2 is an interface specification, not an implementation specification. As such, it is intended to be an interoperability mechanism for terminology resources between applications. There is nothing inherent in the CTS 2 specification that restricts its use to be within a single organization. To the contrary, CTS 2 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 2.4-1 CTS 2 Service Accessed by a Single Organization

CTS 2 will provide for 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.

CTS 2 can be used in an inter-organizational setting where each organization maintains its own security and application specific provisions. CTS 2 will enable consistent access to a high availability or international standard terminology resource, made available to subscribers via a CTS 2 interface.

NOTE: We need a descriptive use case to identify flows, etc. to assist with diagram meaning.

Figure 2.4-2 Multi Organizational access to a CTS 2 Service

Since terminology content is not static, CTS 2 will also provide 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 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 those “local” extensions to the terminology provider to be included as part of the release.

CTS 2 will provide 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 CTS 2 server as input to update the source terminology with the content contained in the change request. As depicted in Figure 2.4-3, Organization A is applying its own local extensions to a terminology resource being served by a CTS 2 service. In addition to 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.

Figure 2.4-3 Multi Organization Access with Write Permissions by One Organization

CTS 2 as a functional specification assume the existence and usability of other interoperability components such as security. The Security component is likely necessary to enable role based access to functionality that should be restricted, such as the ability to affect an update to the terminology or apply a change request.

<Include diagram for use of CTS 2 in a messaging environment>

Terminology Structure Considerations

Terminologies are created for many purposes, and as such are often structured very differently, from a flat list of concepts, to complex poly-hierarchies. The 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, to others which have explicit or implied meaning.

The functional components of CTS 2 must be able to operate on this broad spectrum of terminology sources. At a minimum, CTS 2 must specify a concept based terminology model that is capable of representing most varieties of structured terminologies. While the minimal required attributes for code system entities will be called out in Section 9, the basic structure of the code system is illustrated in figure X. This model outlines the various components and the cardinalities between them but does not dictate particular levels of data normalization or other technical details of implementation.

Figure 1 CTS 2 Upper Level Class Model

Code System

Within HL7, a code system is defined as a collection of codes with associated designations 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 code must resolve to one and only one meaning within the code system. Given this definition, each table in the HL7 Version 2 standard represents a different code system since codes are sometimes used in different tables to have different meanings. For example, “M” in the gender table means Male, while “M” in the marital status table means Married.

In the terminology model, a code system is represented by the Code System entity. Code systems themselves can be concepts and each can be represented by a Code entity with a unique identifier.

Code System Version

Code Systems are not generally static entities, and change over time. A Code System Version is a static snapshot of a Code System at a given point of time. The available e

Concept

A Concept defines a unitary mental representation of a real or abstract thing; an atomic unit of thought. Concepts should be unique within a given Code System, but may have synonyms in terms of representation. Concept may be primitive or compositional in nature. For example, the concept of “hypertension” evokes the same meaning to all clinicians even though it may be expressed as “high blood pressure,” “hypertensive disorder,” or “HTN.”

Each Code System entity will have a set of Concepts associated with it. Each Concept is associated with a Code System through a specific Code System Version in a one-to-one manner.

Code

In the terminology model, all Concepts are represented by the Codes. A Code must be unique within the Code System that defines it. <<include something from desidrata>>

Concept Designation

Concept Designations are representations of Concepts. 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 Concept Designations for the Concept “fever.”

In the terminology model, designations are represented by the Concept Designation entity. Each Concept Designation is a representation of the concept and is assigned a unique designation identifier. In most instances, Concept Designations are human readable forms, but machine readable forms may also be present.

The Concept Designation identifier must, at minimum, 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 designation identifier, which means that the same designation identifier may occur under more than one concept. In other terminologies, there may be more than one identifier for a given text string, meaning that the designation identifier uniquely determines the concept. Service software must not assume either model.

Concept Property

A Concept Property is a property of a Code, and is a named characteristic of the Concept that can be assigned a value. In the terminology model a concept property is represented by the Concept Property class. The allowable or supported Concept Properties for any given Code System are specified by the Supported Concept Property class, and specific to Code System Version.

For example, the result of Hematocrit with a LOINC code of 11271-4 has a specimen property with the value of “blood” and a method property with the value of “automated count.”

In the above example, the specimen and method properties are part of how LOINC assigns the code and, when these properties change, a different LOINC code will be assigned. This implies that concept properties do not change over time. However, exceptions may be possible when the addition of a new property does not change the concept and code. For example, if LOINC decides to add “analyte chemical structure” as a new property, there may not be a need to change the existing LOINC codes since the new information can apply to all of the LOINC concepts.

Each Code may have zero to many Concept Properties, and each Code System may have its own unique set of Concept Properties associated with its Codes for any specific Code System Version.

Concept Relationship

Relationships define the associations or linkages between concepts. For example, in SNOMED CT, the concept of “pneumonia” has an “is-a” relationship to the concept of “lung consolidation,” and “lung consolidation” has an “is-a” relationship to the concept of “disorder of lung.” This represents the logical conclusion that “pneumonia” is a “disorder of lung.”

In the terminology model, relationships are represented by the Concept Relationship entity and are defined as a directed semantic relationship triples (source concept  relationship  target concept) between two Concepts. The allowable or supported Concept Relationships for any given Code System are specified by the Supported Concept Relationship class, and specific to Code System Version.

It is not necessary for concepts to have relationships to other concepts. However, when relationships exist, the cardinality and the explicit declaration of source and target would indicate the directionality that restricts the designation of the relationship. For example, from the relationship in the above example, we can infer that “pneumonia” is a “disorder of lung,” but the inverse relationship of “disorder of lung” is-a “pneumonia” cannot be inferred. If we want the inverse relationship, it must be explicitly stated, that is, there has to be a specific relation of “disorder of lung” “is-a” “pneumonia.”

A ConceptRelationship is declared as a Concept that is represented by a Code. The supported ConceptRelationship type is represented by a Code.Code with its own unique identifier.

Value Set

A Value Set represents a uniquely identifiable set of valid concept representations (Codes), where any concept representation can be tested to determine whether or not it is a member of the value set.

Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

In the terminology model, a value set is represented by the ValueSet class. Value sets have identifiers and is a collection of Code representations for a given Concept.

Business Scenarios

Scenario Actors

Actors will use the CTS 2 service for different purposes. These different actors can be generalized into a basic Terminology User actor that is simply an individual, organization, or application that requires access to terminology content for some purpose. Specializations of the Terminology User actor participate in additional operational specific scenarios that are defined by this Service Functional Model to address the Scope that is outlined in section 2.1.2. Actors described in this section are not necessarily human actors, but also include organizations and systems.

Figure3.1-1 outlines the specializations and composition of the different actors used in this specification. These actors are described below.

Figure 3.1‑2

The following actors take a role in the CTS 2 scenarios.

• CTS 2 Service - Update model

The CTS 2 Service is a specific implementation of the CTS 2 Terminology Server.

• Terminology User

A Terminology User is an actor such as a subject matter expert, terminologist or terminology enabled application. Terminology User activities include, but are not limited to, querying for specific concept codes and browsing or comparing value sets. Specializations of the Terminology User actor follow below.

• Terminology Administrator

The Terminology Administrator is an actor responsible for ensuring the availability and overall maintenance of the terminology server. This includes, but is not limited to loading content into the terminology server, and making available the required functionality to address the specific conformance profiles implemented by the Terminology Server instance.

• Terminology Enabled Application Developer

A Terminology Enabled Application Developer is an actor who is responsible for the development of software applications that make explicit use of controlled terminologies.

• Terminology Author / Curator

A Terminology Author / Curator is an actor who is responsible maintaining terminology content, including but not limited to, the development of new concepts that may be submitted to the Terminology Provider or the extension of an existing terminology with local concepts.

• Terminology Human Language Translator

A Terminology Human Language Translator is an actor with domain knowledge who is also familiar with the languages and dialects which they are responsible for translating.

• Terminology Mapping Specialist

A Terminology Mapping Specialist is an actor with domain and terminological expertise who is responsible for creating mappings between concepts from different code systems.

• Terminology Quality Assurance Specialist - Need to add to UML model

A Terminology Quality Assurance Specialist is an individual who is a domain expert who can validate and contribute content suggestions back to the source terminology. The

• Terminology Provider

The Terminology Provider is the actor the individuals or organization that is responsible for the development of Terminology Content. ion of the Terminology User actor.

• Terminology Value Set Developer - Update Diagram With new terminology

A Terminology Value Set Developer is an actor with specific domain knowledge, as well as expertise in controlled terminologies who develops and maintains domain-or application-specific terminology value sets.

Primary Scenarios

Primary scenarios are tied to one or more conformance profiles. Note, that as an aid to reading this specification, Actors that are identified in the text are italicized. In addition, when a scenario references another scenario, that referenced scenario is in bolded italics.

Administrative Scenarios

Import Content

A Terminology Administrator is requiredwants to to make available a new terminology – or an updated version of an existing terminology from a Terminology Provider – available to Terminology Users through a Terminology Server. This may or may not include the removal of a previously loaded terminology from the terminology server. To accomplish this, the Terminology Administrator may be required to convert the content from the format provided by the Terminology Provider to a format that the Terminology Server is capable of importing.

Export Content

A Terminology Administrator wants to is required to export a terminology or terminology subset from the Terminology Server. This may require filtering of the content and converting the format of the export.

Update Notification

A Terminology User has a dependency on a specific terminology element that is available to a Terminology Server. The Terminology User is interested in knowing when this terminology element is modified in any way, and would like to receive an electronic notification in the event of that change to that terminology element.

Update Notification Management

A Terminology User is requiredwants to update the notification information pertinent to their notification account.

Content Dependency Notification

A Terminology Administrator wants is required to run a dependency check to compare updated content for a given code system, against the version of that code system currently used by the Terminology Administrator’s organization. For example, to provide a list of all terminology elements which are somehow affected by upgrading to a newer version of a terminology.

Search / Query Scenarios

The scenarios in this section describe the ability to query code system and value set meta-data and contents of a given instance of a CTS 2 implementation. These scenarios attempt to outline the information requirements for querying. The detailed function models in section 5.2 call out the distinct functional requirements.

A given CTS 2 implementation will be required to advertise the specific search algorithms that is supports. A representative set of search algorithms are identified in Appendix B.

In each scenario below, the Terminology User may need to specify additional information pertaining to the query. This information may include:

• Specify ‘run-as-if’ information to determine the status of meta-data or contents of a code system or value set as it existed in a specified version.

NOTE: Details of the available meta-data requirements will be identified as part of the Binding Document stuff aka Model harmonization activity.

Code System Search / Query

This section outlines Search / Query operations pertaining to Code Systems.

Resolve Available Code Systems

A Terminology User wants to determine what code systems are available through a specific instance of a Terminology Service. The Terminology User is interested in seeing a listing of the available code systems, as well as the details pertaining to each code systems available through a specific Terminology Service instance.

Retrieve Coded Concepts from Code System

A Terminology User wants to browse or query the content of a specific code system. The Terminology User is interested in seeing a listing of specific coded concepts, associated attributes, as well as the metadata pertaining to each coded concept that meets some search criteria. For example, after a retrieval of concepts has been performed, the result set could be fed to a terminology browsing GUI.

Validate Concept in Code System

A Terminology User wants to validate that a given concept exists in a given code system.

Validate Relationship between Concepts

A Terminology User wants to determine if a specified relationship type exists between two concepts in a code system.

Identify Concept Relationships

A Terminology User wants to identify all the relationships that exist for a given concept.

Returns a set of triples (Expand on this)

Enumerate Concept Relationship Types

A Terminology User wants to determine the set of relationship types that are available for a given terminology.

Identify Concept Language Translations

A Terminology User wants to determine what (if any) alternate language representations exist for a given Concept.

Resolve Concept Representations

A Terminology User wants to determine what (if any) alternate representations exist for a given Coded Concept. Examples of alternate representations for a concept may include abbreviations, or synonyms.

Compare Code System Versions

A Terminology User wants to determine what differences exist between different versions or instances of a code system.

NOTE: Need to compare versions that may not be versioned, for example, updates to a code system to be compared (not versioned at this point)..

Value Set Search / Query

This section outlines Search / Query operations pertaining to Value Sets.

Resolve Available Value Sets

A Terminology User wants to determine what value sets are available through a specific instance of a Terminology Service. The Terminology User is interested in seeing a listing of the available value sets that match some search criteria, as well as the details pertaining to each value set available through a specific CTS 2 Service instance.

Retrieve Coded Concepts from Value Set

A Terminology User wants to browse or query the content of one or more value sets. The Terminology User is interested in seeing a listing of specific coded concepts, as well as the details pertaining to each coded concept in any of the given value sets. For example, the Terminology User may want to search for some criteria over a set of value sets.

Validate Coded Concept in Value Set

A Terminology User wants to validate that a given concept exists in a given value set.

Compare Value Set Versions

A Terminology User wants to determine what differences exist between different versions of a value set.

Value Sets can be defined as either enumerations of concepts (Enumerated Value Set), or by expression syntax that defines the content of the Value Set.

In the case of an Enumerated Value Set, the specific Value Set version identifier can be used as a compare point for the two value sets.

For Intenssionally My wish to consider the use of ‘by definition’ or ‘by reference’ instead of intensional. (John Carter)defined Value Sets, the compare point is either the Code System version when the Value Set definition is bound to a specific Code System version, or the date when the Value Set definition is bound to a code system with no specific version specified. …

Resolve Concept Representations

A Terminology User wants to determine what (if any) alternate representations exist for a given Coded Concept in a value set. Examples of alternate representations for a concept may include abbreviations, or synonyms.

Association Scenarios

The scenarios in this section describe the ability to create, query and maintain associations between coded concepts. These coded concepts may or may not come from the same Code System. As such, these scenarios can describe internal Code System associations, as well as cross Code System associations, often referred to as concept mapping.

The premise for this is that information requirements for internal Code System associations and mapping associations are the same, although the functional requirements for each are quite different.

These scenarios attempt to outline the information requirements for associations. The detailed functional models in section five call out the distinct functional requirements that specifically differentiate internal code system associations from mapping associations.

In each scenario below, the Terminology User may need to specify additional notes and information pertaining to the source / target relationship being dealt with. This information may include:

• The version of the source and target Code Systems being used to create the association, or,
• If the concept association is one-to-one, one-to-many, many-to-one, or many-to-many.

Additionally, the type of associations may include, but are not limited to:

• if the source concept is an exact match to the target concept,
• if the source concept is equivalent to the target concept,
• if the source concept is broader than the target concept,
• if the source concept is narrower than the target concept
• Other examples are generic-to-brand name, ingredient-variant-of, etc.

Create / Maintain an Association between Coded Concepts

A Terminology User wants to create or maintain (i.e. remove or update) an association between coded concepts.For example, these associations may be required to map a local Code System to standard Code Systems in order to be compliant with regulatory reporting policies.

Retrieve Associations

A Terminology User is requiredwants to provide a listing of the concept associations that exist between coded concepts. For example, these associations may be required as part of a government regulatory compliance review or audit.

Search criteria may be accompanied by a "match algorithm code" that determines how the search text will be applied. The table below provides an example set of match algorithms. NOTE: This match algorithm list is not exhaustive. It is permissible for service implementations to extend the list below with additional, custom match algorithms as appropriate, although implementers are strongly encouraged to register the algorithm code to ensure interoperability.

Create Lexical Association

A Terminology User wants to instantiate an association between two sets of coded concepts using a set of lexical rules (matching algorithms) to generate the associations.

Create Rules Based Association

A Terminology User wants to instantiate an association between two sets of coded concepts using a set of description logic or inference rules that either assert or infer mappings between two Code Systems. NOTE: These associations may be subject to human review to verify validity.

Validate Associations between Coded Concepts

A Terminology User wants to validate that a given Coded Concept has a mapping to a specified Coded Concept.

Authoring / Curation Scenarios

This section outlines the requirements of terminology systems that provide the capability of making changes to terminology elements such as code system or value sets. This may include adding new concepts and or relationships within a code system, extending a code system with local terms, or developing value sets for use by a specific application.

Code System Authoring / Curation

This section outlines the business scenarios specific to terminology systems that provide the capability of making changes to code system components which include coded concepts, representations (textual), Associations or Relationships, and value sets.

<<include component definitions from Senthil >>

Create Code System

A Terminology Author is requiredwants to create a new Code System to contain a set of new coded concepts. The Code System is created by defining the set of meta-data properties that describe it.

<add xref to information model when we have it>

Maintain Code System

As part of ongoing terminology maintenance, a Terminology Author is requiredwants to perform maintenance to the defining characteristics of an existing code system.

Create Concept

A Terminology Author is requiredwants to create concept to be included in a Code System.

For example, as part of providing Terminology Service infrastructure to another department, a Terminology Author is required to add additional concept codes to a code system to represent the domain concepts that are important to the new department.

The new concept is defined by the set of meta-data properties that describe it, which may include its proper placement via association binding within the hierarchy of the Code System.

Maintain Concept

A Terminology Author is requiredwants to maintain a concept. This includes making updates to the associated concept attributes, such as changing the presentation, preferred name, etc. (technical corrections), as well as modifying the associations bound to that concept (meaning changes). Versions will be generated depending on the type of updates applied.

Deprecate Concept

A Terminology Author is requiredwants to deprecate a coded concept. Concepts may be required to be deprecated if they become obsolete or are ambiguous. In many cases, the deprecated concept is replaced with other new concepts.

NOTE: In keeping with good vocabulary practice, codes or identifiers for concepts cannot be reused. Additionally, in hierarchical Code Systems, it may be necessary to re-associate any concepts related to the concept being deprecated to prevent a part of the code system hierarchy from being orphaned.

<include diagram>

Maintain Concept Relationship/Association

A Terminology User is requiredwants to manually create or maintain (i.e. remove or update) an association between coded concepts.

This is covered in section 3.2.3.1 Create / Maintain an Association between Coded Concepts.

Create Relationship Type

A Terminology Author is requiredwants to create a new relationship type that may be used to link two concepts.

Value Set Authoring / Curation

This section outlines the business scenarios specific to terminology systems that provide the capability of creating and maintaining sub-sets of a code system, otherwise known as value sets.

Create Value Set by Intension

A Terminology User is requiredwants to create a dynamic value set that is defined by a computable expression that can be resolved to an exact list of coded concepts at any given point in time.

For example, an intensional value set might be expressed as, “SNOMED CT concepts that are children of the SNOMED CT concept “Diabetes Mellitus.”

Note: When creating an intensionally defined value set, the Terminology User may or may not bind the value set definition to a specific version of the Code System(s) from which the concepts are being drawn.

If the value set expression is bound to a specific version of the Code System(s), the value set will always resolve the same set of concept codes for any given version of the value set.

If the value set expression is not bound to a specific version of the Code System(s), the value set will resolve a different set of concept codes as the version of the Code System changes.

Create Value Set by Extension

A Terminology User is requiredwants to create an enumerated (static) value set that is comprised of an explicitly enumerated set of codes.

For example, A Terminology Author is interested in creating a value set based on the SNOMED-CT code system. The Terminology Author builds the value set by selecting the individual concepts that best represent the concepts that are required for the value set.

Maintain Value Set (Definition)

A Terminology User is requiredwants to maintain (i.e. remove or update) a value set (by definition).

For example, a Terminology User identifies an error in how a value set (by definition) is defined. A Terminology Author re-defines the value set to be accurate to the understanding of the Terminology User.

Maintain Value Set (Enumeration)

A Terminology User is requiredwants to maintain (i.e. add, remove or update) an enumerated coded concept in value set.

For example, a Terminology User identifies a concept code that is not included in an enumerated value set. The Terminology Author browses the code system to select the concept code identified by the Terminology User. The Terminology Author selects the concept code to be included in the existing value set.

Note: In order to create a coded concept in a value set it must first exist in the code system (include concept section).

Assumptions and Dependencies

Assumptions

CTS 2 is based on the following assumptions:

• CTS 2 is an interface specification, not an implementation specification.
• This SFM will consider the following areas to be considered as part of the CTS2 Vocabulary Service: Administration, Search/Query, Mapping, Authoring/Curation.
• CTS 2 will support the following terminology components: Concepts, Relationships/Mappings, Representations (textual) and Value Sets.
• At a functional level, CTS 2 will support query, definition, publication and modification of the supported terminology components.
• The ability to process a set of features about a concept to determine where the concept should be classified (placed) in an ontology (Classification) is not within scope of this SFM.
• The ability to provide a set of assertions about an instance (concept) and determine what inference could be made against a target vocabulary (or subset) or knowledge resource is not within scope of this SFM.
• All data and metadata will be stored in appropriate HL7 vocabulary specific datatypesdata types.
• CTS 2 will allow backward compatibility with the CTS IDL input/output structures.
• The CTS 2 specification will maintain MIF compatibility with the current MIF.
• CTS 2 interfaces will be backward compatible with the CTS MAPI/VAPI interfaces.
• Requirements related to system availability, load balancing, failover, and redundancy are outside the scope of this document.

In this section please address the following questions:

• Upon what services does this specification depend (underpinning infrastructure, other HSSP services, HSSP Roadmap dependencies, etc)
• Are there any key assumptions that are being made?

Detailed Functional Model for each Interface

Administration Functions

Import Terminology

Description	Installs a terminology into the terminology service for subsequent access by other service functions.
Inputs	Terminology source
Outputs	An acknowledgement indicating weather the terminology has been successfully loaded or not.
Invariants
Precondition	# CTS 2 Service installed and running Terminology source is available in a format directly consumable by CTS 2 import tools.
Postconditions	The terminology is available for access via the CTS 2 service functions.
Exception Conditions	Information pertaining to the failure is logged and reported for analysis and serviceability.
Aspects left to RFP Submitters
Relationship to levels of conformance	Administration
Miscellaneous notes
Other relevant content

Import Terminology Revision

Description	Installs a new version of an already loaded terminology into the terminology server repository.
Inputs	Terminology revision source.
Outputs	An acknowledgement indicating weather the terminology revision has been successfully loaded or not.
Invariants
Precondition	# CTS 2 Service installed and running. Terminology source is available in a format directly consumable by CTS 2 import tools
Postconditions	The revision is available for access via the CTS 2 service functions.
Exception Conditions	Information pertaining to the failure is logged and reported for analysis and serviceability.
Aspects left to RFP Submitters
Relationship to levels of conformance	Administration
Miscellaneous notes	Terminology revisions may be available as either complete code systems, or as a set of deltas to be applied sequentially to the previous version.In either case, all previous versions/iterations should be available until specifically removed.
Other relevant content

Remove Terminology / Terminology Version

Description	Removes a terminology or terminology version from the terminology service, rendering it unavailable for subsequent access by other service functions.
Inputs	The terminology (and optional terminology version) identifier to be removed.
Outputs	An acknowledgement indicating weather the terminology / terminology version has been successfully removed or not.
Invariants
Precondition	# CTS 2 Service installed and running. Terminology source is available in a format directly consumable by CTS 2 import tools
Postconditions	The terminology / terminology revision is no longer available for access via the CTS 2 service functions.
Exception Conditions	Information pertaining to the failure is logged and reported for analysis and serviceability.
Aspects left to RFP Submitters
Relationship to levels of conformance	Administration
Miscellaneous notes
Other relevant content

Change Terminology Status

Description	Make a code system either active or inactive. This allows a Terminology Administrator to activate or inactivate a given terminology, thus changing its availability for access by other terminology service functions.
Inputs	Code system identifier with optional code system version. Flag to indicate whether to activate or inactivate a code system or code system version.
Outputs	An acknowledgement indicating weather the source terminology has been successfully activated/inactivated or not.
Invariants
Precondition	# CTS 2 Service installed and running. Code System must be loaded into the terminology service.
Postconditions	The terminology source is active/inactive making it either available or unavailable by other terminology service operations.
Exception Conditions	Information pertaining to the success or failure of the status change is logged and reported for analysis and serviceability.
Aspects left to RFP Submitters
Relationship to levels of conformance	Administration
Miscellaneous notes
Other relevant content

Convert Terminology Format

Description	Converts a terminology from its source format into or terminology format that can directly imported (consumed) by the CTS 2 importer.
Inputs	The terminology source to be loaded in its native format.
Outputs	An acknowledgement indicating weather the source terminology has been successfully converted or not.
Invariants
Precondition	# CTS 2 Service installed and running. Terminology source is available in its original source format.
Postconditions	The terminology source is available in a format that is readily ingestible by the CTS 2 importers.
Exception Conditions	Information pertaining to the failure is logged and reported for analysis and serviceability.
Aspects left to RFP Submitters
Relationship to levels of conformance	Administration
Miscellaneous notes
Other relevant content

Register for Update Notification

Description	Register to be notified whenever the state of a vocabulary element (code system or value set) is updated in the registry.
Inputs	URL or other electronic address which to send the terminology element modification notification to.
Outputs	An acknowledgement indicating weather the terminology element notification request was received or not
Invariants
Precondition	User or appropriate proxy (system administrator, etc) are authorized to access registry
Postconditions	Notification records are updated appropriately
Exception Conditions	Information pertaining to the failure is logged and reported for analysis and serviceability.
Aspects left to RFP Submitters
Relationship to levels of conformance	Administration
Miscellaneous notes	Subsequent notifications do not require a confirmation. Where appropriate, however, negative feedback on the channel (unable to deliver message, unable to connect), should result in attempts to retransmit and/or the placement of a temporary hold on notifications until connection problem is corrected.
Other relevant content

Revise or Remove Update Notification

Description	Revise or remove a notification entry for a particular vocabulary element
Inputs	URL or other electronic address which to send the terminology element modification notification to.
Outputs	An acknowledgement indicating weather the terminology element notification revision request was received or not
Invariants
Precondition	User or appropriate proxy (system administrator, etc) are authorized to access registry
Postconditions	Notification records are updated appropriately
Exception Conditions	Information pertaining to the failure is logged and reported for analysis and serviceability.
Aspects left to RFP Submitters
Relationship to levels of conformance	Administration
Miscellaneous notes	Subsequent notifications do not require a confirmation. Where appropriate, however, negative feedback on the channel (unable to deliver message, unable to connect), should result in attempts to retransmit and/or the placement of a temporary hold on notifications until connection problem is corrected.
Other relevant content

Search / Access

Resolve Available Code Systems

Description	Resolve the code systems available by this instance of the CTS 2 Service
Inputs	Terminology service instance identifier.
Outputs	A listing of the code systems and code system metadata properties available on the specified instance of the terminology service.
Invariants
Precondition	A running CTS 2 Service with at least once code system loaded and active
Postconditions	None.
Exception Conditions	Terminology service not available.
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes
Other relevant content

Resolve Code System Metadata

Description	Resolve the metadata attributes for a given code system available on the terminology service
Inputs	Code system name or identifier, and optional version
Outputs	The code system metadata (attributes)
Invariants
Precondition	Code system must be loaded into the terminology service
Postconditions	None.
Exception Conditions	Code system not loaded
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes
Other relevant content

Resolve Code System Concepts

Description	Returns the set of all (or all active) concepts in the specified code system.
Inputs	Code system. Optional code system version. Boolean for active concepts only.
Outputs	The set of all (or all active) concepts in the specified code system.
Invariants
Precondition	Code system must be loaded in the CTS 2 service
Postconditions	None.
Exception Conditions	Code system not available.
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes	Returning all concepts in a code system is generally impractical for large code sets. Indexing, query optimization is necessary.
Other relevant content

Resolve Concept Details

Description	Resolve the details for the known attributes (metadata) of a coded concept.
Inputs	A coded concept, a code system, an optional code system version
Outputs	The details of the attributes (metadata) of the coded concept
Invariants
Precondition	A coded concept and a known code system
Postconditions	None.
Exception Conditions	Coded concept not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes
Other relevant content

Resolve Coded Concept from Code System

Description	Given a set of attributes for a coded concept, allow for the search of entries that match the criteria specified on the query attributes.
Inputs	Code System identifier (and optional version). A list of attribute(s). Matching algorithm (optional).
Outputs	An acknowledgement that a list of coded concepts for the search predicate has been found or no matches. The list of coded concepts from the code system that match the search criteria. The list of coded concepts from the code system that match the search attributes.
Invariants
Precondition	A code system must be loaded and available on the code system.
Postconditions	None.
Exception Conditions	Concept attribute does not exist. Code system does not exist.
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes
Other relevant content

Resolve Relations Between Coded Concepts

Description	Determine whether there is a directed relation (or transitive closure relation) from the source code to the target code.
Inputs	Source Code, Target Code, Association, Boolean
Outputs	Return True if a directed relation exists; otherwise False
Invariants
Precondition	Code system available to the terminology server.
Postconditions	None.
Exception Conditions	Coded concept not found. Relationship Type not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes	Boolean input parameter determines whether only direct associations are considered or whether the transitive closure of the relation is used.
Other relevant content

Value Set Search / Access

Compare Value Sets

Description	Compare two or more value sets via the metadata properties of the value sets.
Inputs	Two value sets for comparison, including optional value set version for comparison
Outputs	The comparison result from the two value sets is returned.
Invariants
Precondition	CTS 2 Service is running. Two value sets are available for comparison.
Postconditions	None.
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Query /Search
Miscellaneous notes	Comparison of value set may include set comparisons such as intersection, difference and union. This comparison is ONLY at the value set container level, and does NOT include comparison of the contents of the value sets
Other relevant content

Compare Value Set Contents

Description	Compare the contents of two or more value sets.
Inputs	Two or more value sets for comparison.
Outputs	The result of the compare of the contents of the value sets.
Invariants
Precondition	CTS 2 Service is running. Two value sets are available for comparison.
Postconditions	None.
Exception Conditions	Value set or value set version not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes	Comparison of value sets may include set comparisons such as intersection and difference and union. This comparison is on the contents of the value sets (Value Set Entries and PickList Entries) and is not a comparison of the Value Set metadata attributes (Value Set container object.)
Other relevant content

Resolve Available Value Sets

Description	Resolve the value sets that are available to the CTS 2 service.
Inputs	Optional search attributes specified from the value set metadata properties.
Outputs	Listing of the available value sets on this instance of the terminology server.
Invariants
Precondition	Functioning CTS 2 service
Postconditions	None.
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes	When search attributes are applied, the result set is restricted to the value sets that match the search attribute criteria. Examples include: restricting to matching properties such as value set ID, Name, value set version, code systems that comprise the values of the value set, or other metadata attributes/properties of the value set.
Other relevant content

Resolve Value Set Metadata

Description	Look up detailed information (metadata) for a given value set.
Inputs	Value Set (name or identifier) and optional value set version
Outputs	Detailed value set description (resolved meta data or attributes for the value set.)
Invariants
Precondition	Value set must exist and be available on the terminology service.
Postconditions	None.
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes
Other relevant content

Resolve Value Set Entries

Description	Resolve the contents (entries) of a given value set
Inputs	Value set identifier, optional value set name
Outputs	A set representing all entries for the given value set
Invariants
Precondition	Value set name and/or identifier
Postconditions	None.
Exception Conditions	Value set does not exist
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes	Value sets may not be finite (e.g. the set of all reals between 1 and 10) Obviously we don't want to list them all. We need to limit the result set to a reasonable amount.
Other relevant content

Resolve Value Set Entry

Description	Determine whether the supplied coded concept exists in the supplied value set
Inputs	Coded Concept, Value Set, optional value set version
Outputs	True / False
Invariants
Precondition	Value set must be available in the code system
Postconditions	None.
Exception Conditions	Value set does not exist
Aspects left to RFP Submitters
Relationship to levels of conformance	Query/Search
Miscellaneous notes
Other relevant content

ConceptCode System RelationshipMapping and Mapping

Create RelationshipMap Between Coded Concepts

Description	RelatesMaps the supplied code system id and coded concept to a corresponding coded concept (if any) in the target system.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Optional source code system version. Optional target code system version.
Outputs	A relationshipmapping is created between a coded concept from a source code system and a coded concept in the target code system.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	A relationship mapping is created between a coded concept from a source code system and a coded concept in the target code system.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	RelationshipMapping
Miscellaneous notes
Other relevant content

Create Lexical Relationship Between Coded Concepts

Description	Relates the supplied code system id and coded concept to a corresponding coded concept (if any) in the target system using a set of lexical rules (matching algorithms) to generate the relationships.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Search Criteria (text string), Match Algorithm Code, Optional source code system version. Optional target code system version.
Outputs	Relationships are created between one or more coded concepts from a source code system and one or more coded concepts in the target code system.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	Relationships are created between one or more coded concepts from a source code system and one or more coded concepts in the target code system.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. No coded concepts match the search criteria for the specificed match algorithm.
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content	Match Algorithm Code Description IdenticalIgnoreCase The lower case representation of the target text must match the lower case representation matchText exacty. Identical The target text must match the matchText exactly. StartsWithIgnoreCase The lower case representation of target text must begin with the lower case representation of matchText. StartsWith The target text must begin with the matchText. EndsWithIgnoreCase The lower case representation of the target text must end with the lower case representation of matchText. EndsWith The target text must end with the matchText. ContainsPhraseIgnoreCase The lower case representation of the target text must contain the lower case representation of the matchText. ContainsPhrase The target text must contain the matchText. WordsAnyOrderIgnoreCase The target text must contain all of the words in the match text, but in any order. WildCardsIgnoreCase The match text may contain zero or more 'wild cards', designated by an asterisk (*). Wild cards match 0 of more characters in the target string. The escape character is a backslash('\') meaning that the matchText "a\*b*' would match any string that begins with the string "a*b". RegularExpression The match text may contain regular expressions, as defined in XML Schema Part 2: Datatypes. NYSIIS New York State Identification and Intelligence System phonetic encoding

Create Rules Based Relationship Between Coded Concepts

Description	Relates the supplied code system id and coded concept to a corresponding coded concept (if any) in the target system using a set of description logic or inference rules that either assert or infer relationships.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Description Logic (text string), Inference Rules (text string), Optional source code system version. Optional target code system version.
Outputs	A relationship is created between one or more coded concepts from a source code system and one or more coded concept in the target code system.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	A relationship is created between one or more coded concepts from a source code system and one or more coded concept in the target code system.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. No coded concepts satisfy the description logic or inference rules.
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content	These relationships are subject to human review to verify validity.

Retrieve Relationships

Description	Given two or more coded concepts, returns the set of all relationships between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Optional source code system version. Optional target code system version.
Outputs	A list of relationships.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	A list of relationships.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content

Validate Relationships between Coded Concepts

Description	Given two or more coded concepts and relationship type (and optional code system identifiers,) determine of any of the specified relationships exist between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Relationship type. Optional source code system version. Optional target code system version.
Outputs	Boolean
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. Relationship type not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content

Validate Lexical Based Relationships between Coded Concepts

Description	Given two or more coded concepts and lexical search criteria and match algorithm (and optional code system identifiers,) determine of any of the specified lexical based relationships exist between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Lexical Search Criteria and Match Algorithm. Optional source code system version. Optional target code system version.
Outputs	Boolean
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. Lexical Search Criteria not found. Match Algorithm not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content

Validate Rules Based Relationships between Coded Concepts

Description	Given two or more coded concepts and description logic or inference rules (and optional code system identifiers,) determine of any of the specified rules based relationships exist between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Description Logic. Inference Rules. Optional source code system version. Optional target code system version.
Outputs	Boolean
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. Description Logic not found. Inference Rules not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content

Maintain Relationships between Coded Concepts

Description
Inputs
Outputs
Invariants
Precondition
Postconditions
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content

Remove Relationships between Coded Concepts

Description
Inputs
Outputs
Invariants
Precondition
Postconditions
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content

Update Relationships between Coded Concepts

Description
Inputs
Outputs
Invariants
Precondition
Postconditions
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Relationship
Miscellaneous notes
Other relevant content

Create Mapping Between Coded Concepts

Description	Maps the supplied code system id and coded concept to a corresponding coded concept (if any) in the target system.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Optional source code system version. Optional target code system version.
Outputs	A mapping is created between a coded concept from a source code system and a coded concept in the target code system.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	A mapping is created between a coded concept from a source code system and a coded concept in the target code system.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content

Create Lexical Mapping Between Coded Concepts

Description	Maps the supplied code system id and coded concept to a corresponding coded concept (if any) in the target system using a set of lexical rules (matching algorithms) to generate the relationships.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Search Criteria (text string), Match Algorithm Code, Optional source code system version. Optional target code system version.
Outputs	Mappings are created between one or more coded concepts from a source code system and one or more coded concepts in the target code system.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	Mappings are created between one or more coded concepts from a source code system and one or more coded concepts in the target code system.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. No coded concepts match the search criteria for the specificed match algorithm.
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content	Match Algorithm Code Description IdenticalIgnoreCase The lower case representation of the target text must match the lower case representation matchText exacty. Identical The target text must match the matchText exactly. StartsWithIgnoreCase The lower case representation of target text must begin with the lower case representation of matchText. StartsWith The target text must begin with the matchText. EndsWithIgnoreCase The lower case representation of the target text must end with the lower case representation of matchText. EndsWith The target text must end with the matchText. ContainsPhraseIgnoreCase The lower case representation of the target text must contain the lower case representation of the matchText. ContainsPhrase The target text must contain the matchText. WordsAnyOrderIgnoreCase The target text must contain all of the words in the match text, but in any order. WildCardsIgnoreCase The match text may contain zero or more 'wild cards', designated by an asterisk (*). Wild cards match 0 of more characters in the target string. The escape character is a backslash('\') meaning that the matchText "a\*b*' would match any string that begins with the string "a*b". RegularExpression The match text may contain regular expressions, as defined in XML Schema Part 2: Datatypes. NYSIIS New York State Identification and Intelligence System phonetic encoding

Create Rules Based Mapping Between Coded Concepts

Description	Maps the supplied code system id and coded concept to a corresponding coded concept (if any) in the target system using a set of description logic or inference rules that either assert or infer mappings.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Description Logic (text string), Inference Rules (text string), Optional source code system version. Optional target code system version.
Outputs	A mapping is created between one or more coded concepts from a source code system and one or more coded concept in the target code system.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	A mapping is created between one or more coded concepts from a source code system and one or more coded concept in the target code system.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. No coded concepts satisfy the description logic or inference rules.
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content	These mappings are subject to human review to verify validity.

Retrieve Mappings

Description	Given two or more coded concepts, returns the set of all mappings between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Optional source code system version. Optional target code system version.
Outputs	A list of mappings.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions	A list of mappings.
Exception Conditions	Source or target code systems not found. Source or target coded concept not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content

Validate Mappings between Coded Concepts

Description	Given two or more coded concepts and mapping (and optional code system identifiers,) determine if any of the specified mappings exist between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Mapping. Optional source code system version. Optional target code system version.
Outputs	List of mappings.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. Mapping not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Mappings
Miscellaneous notes
Other relevant content

Validate Lexical Based Mappings between Coded Concepts

Description	Given two or more coded concepts and lexical search criteria and match algorithm (and optional code system identifiers,) determine if any of the specified lexical based mappings exist between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Lexical Search Criteria. Match Algorithm. Optional source code system version. Optional target code system version.
Outputs	Boolean
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. Lexical Search Criteria not found. Match Algorithm not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content

Validate Rules Based Mappings between Coded Concepts

Description	Given two or more coded concepts and description logic or inference rules (and optional code system identifiers,) determine of any of the specified rules based mappings exist between the concepts.
Inputs	Source code system identifier. Target Code system identifier. Souce code system terminology service identifier. Target Code system terminology service identifier. Source coded concept. Target Coded concept. Description Logic. Inference Rules. Optional source code system version. Optional target code system version.
Outputs	Boolean.
Invariants
Precondition	Source and target code systems loaded and available on one or more instances of a terminology service.
Postconditions
Exception Conditions	Source or target code systems not found. Source or target coded concept not found. Description Logic not found. Inference Rules not found.
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content

Maintain Mappings between Coded Concepts

Description
Inputs
Outputs
Invariants
Precondition
Postconditions
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content

Remove Mappings between Coded Concepts

Description
Inputs
Outputs
Invariants
Precondition
Postconditions
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content

Update Mapping between Coded Concepts

Description
Inputs
Outputs
Invariants
Precondition
Postconditions
Exception Conditions
Aspects left to RFP Submitters
Relationship to levels of conformance	Mapping
Miscellaneous notes
Other relevant content

• Consider client, maintenance, and management interfaces when conducting this analysis
• Note that each “capability” may result in one or more individual operations in the technical specification resulting from an RFP submission.

Profiles

Introduction

A profile is a named set of cohesive capabilities. A profile enables a service to be used at different levels and allows implementers to provide different levels of capabilities in differing contexts. Service-to-service interoperability will be judged at the profile level and not the service level. Note that through the use of profiles, there are no “optional” interfaces. Conditions that might otherwise merit this optionality should be addressed via a dedicated profile.

Include the following boilerplate text:

A set of profiles may be defined that cover specific functions, semantic information and overall conformance. The SSDF explains in detail the meaning of each of these types of profile. In brief, they are as follows:

• • • Functional Profile: a named list of a subset of the operations defined within this specification which must be supported in order to claim conformance to the profile.
    • Semantic Profile: identification of a named set of information descriptions (e.g. semantic signifiers) that are supported by one or more operations.
    • Conformance Profile: this is a combination of a set of functional and semantic profiles taken together to give a complete coherent set of capabilities against which conformance can be claimed. This may optionally include additional constraints where relevant.

Fully define the profiles being defined by this version of the service.

When appropriate, a minimum profile should be defined. For example, if a service is data-oriented, a minimum semantic profile supporting HL7 data (with the relevant data cited) should be included.

Each functional profile must identify which interfaces are supported, and where relevant where specific data groupings are covered etc.

When profiling, consider the use of your service in:

• Differing business contexts
• Different localizations
• Different information models
• Partner-to-Partner Interoperability contexts
• Product packaging and offerings

User Scenario Interaction Details [Optional]

• Describe the dynamics of the service from a requirement-level architectural view and its interactions with anticipated (services/components/applications, etc.)
• High-level description, illustrating the scenarios
• Elaborated for each scenario (or use case) in Chapter 2.

The Services Framework Functional Model

The Services Framework Functional Model identifies common underlying enterprise infrastructure such as naming, directory, security, etc. that may be assumed and referenced by this Functional Model.

Note that the Services Framework Functional Model is being developed in parallel with other service Functional Models; candidate functionality for the Framework should be submitted to the Infrastructure subgroup for evaluation.

Relationship to Information Content

The following principles shall be followed for specifying the information model to be used by the services being specified in this Service Functional Model:

1. SFMs shall provide a conformance profile supporting HL7 content where relevant
2. We shall not preclude the use of non-HL7 content
3. SFMs will reuse to the maximum extent possible the content models as defined in other standards (for example, HL7 RMIMs)
4. Information content representations shall be represented in platform-agnostic formalisms (e.g., UML)
5. SFMs may identify content at varying levels of granularity, depending upon the functions being specified. (For example, the Common Terminology Service will deal with different granularity of information than the Resource Location and Update Service).
6. Conformance Profiles may be balloted or adopted after the release of the initial SFM to address specialized business needs. (realm-specific profiles, domain-specific profiles, etc.)
7. Details about semantics specific to this SFM appear in other sections of this document

Recommendations for Technical RFP Issuance

• Identification of topics requiring elaboration in candidate solutions. This may be service-specific, deployment related, or non-functional
• Technology solutions supporting this functional requirement should consider the following areas:
  • What is the impact of internationalization of this specification?

Appendix A - Relevant Standards

• Review of potentially relevant standards, including a short-list of applicable standards.
• For each applicable standard (this may include citations to standards themselves, information content, portions of standards, etc. Demonstrate that “you are not re-inventing the wheel”):
  • A short review that explains its intended relationship to this specification
    • What are the relevant parts that are being re-used, extended, etc.
    • Include context of how the service relates to the existing standard.
  • How does this work relate to similar work;
  • What are the implications if this service is used in an environment that has already adopted a competing or closely related standard
• If there is relevant realm work, a traceability matrix would be useful here {for instance, U.S. Federal Enterprise Architecture/Service Reference Model}

There is no generally accepted standard for terminology services but there are several sources of material on this topic. Include the contextual information as to why the referenced content is relevant. - rah

HL7 Common Terminology ServicesThe Common Terminology Services (CTS) specification was developed as an alternative to a common data structure.The HL7 Common Terminology Services (HL7 CTS) is an Application Programming Interface (API) specification that is intended to describe the basic functionality that will be needed by HL7 Version 3 software implementations to query and access terminological content. It is specified as an API rather than a set of data structures to enable a wide variety of terminological content to be integrated within the HL7 Version 3 messaging framework without the need for significant migration or rewrite.Instead of specifying what an external terminology must look like, HL7 has chosen to identify the common functional characteristics that an external terminology must be able to provide. As an example, an HL7 compliant terminology service will need to be able to determine whether a given concept code is valid within the particular resource. Instead of describing a table keyed by the resource identifier and concept code, the CTS specification describes an Application Programming Interface (API) call that takes a resource identifier and concept code as input and returns a true/false value. Each terminology developer is free to implement this API call in whatever way is most appropriate for them.There are two layers between HL7 Version 3 message processing applications and the target vocabularies. The upper layer, the Message API communicates with in terms of vocabulary domains, realms, coded attributes and other artifacts of the RIM and HL7 messaging model. The lower layer, the Vocabulary API communicates in terms of coding system, concept codes, designations, and other vocabulary related entities.NOTE: THE CTS II specification is an extension of the original HL7 Common Terminology Services approved standard.

The Lexical GridThe Lexical Grid is a proposal for standard storage of terminologies and ontologies.  The LexGrid Model defines how terminologies should be formatted and represented programmatically.  It also defines several different server storage mechanisms and a XML format.  

The OMG Terminology Query Services (TQS) specificationTQS specifies a full terminology service, but is not widely implemented and vendor support is minimal. The specification is considered by some to be too "heavyweight" and also assumes a particular technical solution (CORBA). Since reliance on the TQS standard is not an assumption of the HL7 standard, a more general approach to terminology services is needed - at least to cover those areas in which HL7 is terminology dependent.

API specifications specific to individual terminologiesAn example of this is the "Read Code - Version 3 API" specified for the NHS Clinical Terms in 1996 and revised in 1998. Work is proceeding to develop a SNOMED CT API based on similar principles. There is an informal understanding that this specific API will converge with or utilize elements of the CTS where these are appropriate. A COM implementation of this is supported by at least one freeware coding engine (CLUE). Specifications of this type identify many of the general functions needed to access a terminology. However, they are inevitably specific to the needs of a particular terminology. Explicit support for a single defined terminology model allows efficient implementation within an operational environment at the expense of the flexibility to access other terminologies.

Terminology Query Language (TQL)TQL, formerly based on an SQL-like syntax, today implements as a URI-based language specific to terminology servers designed by Michael Hogarth and colleagues from the University of California Davis. TQL provides a rich mechanism that deals specifically with common properties and relationships in terminological models. A working Java-based implementation of TQL can be downloaded for free from the web

Appendix B – Glossary

Actor

In the Unified Modeling Language (UML), an actor is something or someone who supplies a stimulus to the system. An actor cannot be controlled by the system and is defined as being outside the system. An actor is often thought of as a role, rather than an actual person. A single person in the real world can be represented by several actors if they have several different roles and goals in regards to a system. Source: http://en.wikipedia.org/wiki/Actor_(UML)

Code System

A Code System is defined as a collection of codes with associated designations, meanings and associations. The persistent representation of a Code Systems include meta-data about the code system itself, as well as the contents of the Code System.

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 Code must resolve to one and only one meaning within the Code System. Given this definition, each table in the HL7 Version 2 standard represents a different Code System since Concept Codes are sometimes used in different tables to have different meanings. For example, the Concept Code “M” in the gender Code System means “Male”, while “M” in the marital status Code System means “Married”.

Concept Code Mapping

The process of linking content from one terminology or classification scheme to another.

Curation

Authoring and maintenance in a defined context of good practices.

Kristi Eckerson

Nested Value Sets

When a Value Set Entry references another Value Set, the child value set is referred to as a Nested Value Set. There is no preset limit to the level of nesting allowed within value sets. Value sets cannot contain themselves, or any of their ancestors (i.e. they cannot be defined recursively).

Intensional Value Sets can be defined by either fixing the Value Set definition to a specific version of the Code System (when the Code System supports versioning), or by decoupling the Value Set definition from the version of the code system. This seemingly subtle variation can have very significant impact on the final list of concepts which the Value Set ultimately resolves to.

When the Value Set definition is tied to the version of the Code System, the value set content will remain fixed when instantiated. When the Value Set definition is independent of Code System version, the content of the Value Set can vary as the Value Set is resolved against different versions of the Code System.

Sub-value Sets

A sub-value set is a sub-set of a parent Value Set.

Value Set

A Value Set represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content, and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

Sub-value Sets

A sub-value set is a sub-set of a parent Value Set.

Value Set Specification

Value sets can be specified in two ways, either by enumeration (extension), or definition (intention). Extensional Value Set Representation (Enumeration)

From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an extensional definition is a description of a concept by enumerating all of its subordinate concepts under one criterion of subdivision.

Value sets defined by extension are comprised of an explicitly enumerated set of codes. The simplest case is when the value set consists of only one code.

Code Value	Description
M	Male
F	Female
U	Unspecified

More complex variations might re 1000 late to hierarchical coding systems such as the following fictitious example, where “Level” represents the nesting level for a particular Code Value:

Code Value	Level	Description
1123123	1	Education
1343434	2	Diabetic Education
1445455	2	Stroke Education
2135534	1	Counseling
2344566	2	Emotional
3456663	2	Daily Living

Intensional Value Set Definition (Definition)

From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an intensional definition describes the intension of a concept by stating the superordinate concept and the delimiting characteristics.

Value sets defined by intension are value sets that are defined by a computable expression that can be resolved to an exact list of codes.

For example, an intensional value set definition might be defined as, “ SNOMED CT concepts that are children of the SNOMED CT concept “Diabetes Mellitus.”

Some common strategies used to define intensional values sets include:

• Reference a head concept and its subordinate concepts in a hierarchy.
• Reference only the concepts subordinate to a head code (and not the head code itself).
• Create arbitrarily complex unions, intersections, and exclusions of the two previously described types of value sets.
• Other mechanisms, including statements created using a rich expression language.

Nested Value Sets

When a Value Set Entry references another Value Set, the child value set is referred to as a Nested Value Set. There is no preset limit to the level of nesting allowed within value sets. Value sets cannot contain themselves, or any of their ancestors (i.e. they cannot be defined recursively).

Intensional Value Sets can be defined by either fixing the Value Set definition to a specific version of the Code System (when the Code System supports versioning), or by decoupling the Value Set definition from the version of the code system. This seemingly subtle variation can have very significant impact on the final list of concepts which the Value Set ultimately resolves to.

When the Value Set definition is tied to the version of the Code System, the value set content will remain fixed when instantiated. When the Value Set definition is independent of Code System version, the content of the Value Set can vary as the Value Set is resolved against different versions of the Code System.

Version

A Version represents

Provide a definition of version – in HL7, the timestamp will indicate version. (Kristi Eckerson)

Appendix C - HL7 EHR Functional Model Traceability

This section lists the EHR Functions that are related to this service.

Note that in general there will not be a direct correspondence between EHR Functions and HSSP Services, since Services are specified from a different system viewpoint. The mapping provided here enables the HSSP Services to be understood in the context of the EHR-S Functional Model DSTU. The table below references Version ________ of the EHR Functional Model.

EHR Function ID	EHR Function Name	EHR Function Statement	Notes For every row, explain the rationale for including in this specification.

---