|
|
| (16 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | <center>'''Service Functional Model Specification'''</center>
| |
| | | | |
| − |
| |
| − | <center>'''Common Terminology Services 2(CTS 2)'''</center>
| |
| − |
| |
| − |
| |
| − | <center>'''Version 0.3'''</center>
| |
| − |
| |
| − |
| |
| − | <center>'''20-March-2008 '''</center>
| |
| − |
| |
| − |
| |
| − |
| |
| − | {| class="prettytable" border="1"
| |
| − | | Project Leads
| |
| − | | Russell Hamm [mailto:rhamm@apelon.com rhamm@apelon.com] (Apelon, Inc.)
| |
| − |
| |
| − | Craig Stancl [mailto:stancl.craig@mayo.edu stancl.craig@mayo.edu] (Mayo Clinic/Foundation)
| |
| − |
| |
| − | |-
| |
| − | | Editors
| |
| − | | John Carter [mailto:John.X.Carter@ge.com John.X.Carter@ge.com](GE Healthcare)
| |
| − |
| |
| − | Sundak Ganesan [mailto:dsq3@CDC.GOV dsq3@CDC.GOV](CDC)
| |
| − |
| |
| − | Russell Hamm [mailto:rhamm@apelon.com rhamm@apelon.com] (Apelon, Inc.)
| |
| − |
| |
| − | Senthil Nachimuthu [mailto:snachimuthu@mmm.com snachimuthu@mmm.com](3M Health Information Systems Division)
| |
| − |
| |
| − | Craig Stancl [mailto:stancl.craig@mayo.edu stancl.craig@mayo.edu] (Mayo Clinic/Foundation)
| |
| − |
| |
| − | |-
| |
| − | | Contributors
| |
| − | | Harold Solbrig [mailto:hsolbrig@apelon.com hsolbrig@apelon.com]
| |
| − |
| |
| − | (Apelon, Inc.)
| |
| − |
| |
| − | James Buntrock [mailto:buntrock.james@mayo.edu buntrock.james@mayo.edu](Mayo Clinic/Foundation)
| |
| − |
| |
| − | |}
| |
| − |
| |
| − |
| |
| − | '''Preface'''
| |
| − |
| |
| − | Notes to Readers
| |
| − |
| |
| − | <font color=blue>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.</font>
| |
| − |
| |
| − |
| |
| − |
| |
| − | '''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.
| |
| − |
| |
| − |
| |
| − | Acknowledgements
| |
| − |
| |
| − | This document is the result of the collaboration of many individuals and organizations. The terminology and standards community - all involved in the numerous meetings and teleconferences are to be thanked for their contributions and support. In addition to the listed authors, 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)
| |
| − | * Harold Solbrig (Apelon, Inc.)
| |
| − | * Ken Rubin (EDS)
| |
| − |
| |
| − |
| |
| − | Note that sections of this document in <font color=blue> <blue> </font> 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) ===
| |
| − | <nowiki>The Healthcare Services Specification Project (HSSP) [</nowiki>[http://hssp.wikispaces.com/ http://hssp.wikispaces.com]<nowiki>] is a joint endeavor between Health Level Seven (HL7) [</nowiki>[http://www.hl7.org/ http://www.hl7.org]<nowiki>] and the Object Management Group (OMG) [</nowiki>[http://www.omg.org/ 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<ref name="ftn1"><sup>It is expected that services will be defined, in response to the OMG RFP process, as UML components, however that level of design is outside the scope of the Functional Model.</sup>
| |
| − |
| |
| − |
| |
| − | </ref>.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:
| |
| − |
| |
| − |
| |
| − | '''<nowiki><<diagram on relationship of CTS 2 to other HSSP services>></nowiki>'''
| |
| − |
| |
| − |
| |
| − | 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:
| |
| − |
| |
| − | # Establish the minimal common structural model for terminology, and how it is related to meta-data (information about data) and data (the information itself)
| |
| − | # Integrate into CTS 2 the functional coverage outlined in the existing CTS specification.
| |
| − | # 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.
| |
| − | # 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.
| |
| − | # Specify how mapping between compatible terminologies and data models is defined, exchanged and revised.
| |
| − | # Specify how logic-based terminologies can be queried about subsumption and inferred relationships.
| |
| − | # 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.
| |
| − |
| |
| − |
| |
| − | [[Image:]]
| |
| − |
| |
| − | '''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.
| |
| − |
| |
| − |
| |
| − | [[Image:]]Descriptive use case to identify flows, etc. to assist with diagram meaning. See IHE sharing value set use cases.
| |
| − |
| |
| − | '''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.
| |
| − |
| |
| − |
| |
| − | [[Image:]]
| |
| − |
| |
| − | '''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.
| |
| − |
| |
| − |
| |
| − | '''<nowiki><Include diagram for use of CTS 2 in a messaging environment></nowiki>'''
| |
| − |
| |
| − |
| |
| − | == 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.
| |
| − |
| |
| − |
| |
| − | [[Image:]]
| |
| − |
| |
| − | <center>'''Figure 1 CTS 2 Upper Level Class Model'''</center>
| |
| − |
| |
| − |
| |
| − | === Code System ===
| |
| − | <center>[[Image:]]</center>
| |
| − |
| |
| − | 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 ===
| |
| − | <center>[[Image:]]</center>
| |
| − |
| |
| − |
| |
| − | 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 ===
| |
| − | <center>[[Image:]]</center>
| |
| − |
| |
| − |
| |
| − | 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 ===
| |
| − | <center>[[Image:]]</center>
| |
| − |
| |
| − |
| |
| − | In the terminology model, all ''Concepts'' are represented by the ''Codes''. A ''Code ''must be unique within the ''Code System''<nowiki> that defines it. <<include something from desidrata>></nowiki>
| |
| − |
| |
| − |
| |
| − | === Concept Designation ===
| |
| − | [[Image:]]
| |
| − |
| |
| − | ''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 ===
| |
| − | <center>[[Image:]]</center>
| |
| − |
| |
| − |
| |
| − | 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 ===
| |
| − | === [[Image:]] ===
| |
| − | 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 ===
| |
| − | <center>[[Image:]]</center>
| |
| − |
| |
| − |
| |
| − | 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 a''ctor 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.
| |
| − |
| |
| − |
| |
| − | [[Image:]]
| |
| − |
| |
| − | <center>'''Figure 3.1‑2'''</center>
| |
| − |
| |
| − |
| |
| − | The following actors take a role in the CTS 2 scenarios.
| |
| − |
| |
| − | * CTS 2 ServiceUpdate model<br/>
| |
| − |
| |
| − |
| |
| − | 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 SpecialistNeed 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 DeveloperUpdate 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.
| |
| − |
| |
| − |
| |
| − | = Consistency Check =
| |
| − | A ''Terminology User'' is needswants to be able to run a consistency check on a code system. This would be used to validate the code system content looking for violations of terminology best practices such as:
| |
| − |
| |
| − | * duplicates concepts in the code system
| |
| − | * orphaned concepts
| |
| − | * ''get more best practices…''
| |
| − |
| |
| − |
| |
| − | = Search / Query Scenarios =
| |
| − | The scenarios in this section describe the ability to query code system and value set meta-data and contents. These scenarios attempt to outline the information requirements for querying. The detailed function models in section 5.2 call out the distinct functional requirements.
| |
| − |
| |
| − |
| |
| − | 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.
| |
| − |
| |
| − |
| |
| − | = 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.
| |
| − |
| |
| − |
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | ! <center>Match Algorithm Code</center>
| |
| − | ! <center>Description</center>
| |
| − |
| |
| − | |-
| |
| − | | IdenticalIgnoreCase
| |
| − | | The lower case representation of the target text must match the lower case representation matchText exactly.
| |
| − |
| |
| − | |-
| |
| − | | 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 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.
| |
| − |
| |
| − | <nowiki><<include component definitions from Senthil >></nowiki>
| |
| − |
| |
| − | = 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.
| |
| − |
| |
| − | <nowiki><add xref to information model when we have it></nowiki>
| |
| − |
| |
| − |
| |
| − | = 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.
| |
| − |
| |
| − | '''<nowiki><include diagram> </nowiki>'''
| |
| − |
| |
| − |
| |
| − | = 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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ==
| |
| − | === Code System Search / Access ===
| |
| − | === Resolve Available Code Systems ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ==
| |
| − | === Concept Relationship ===
| |
| − | === Create RelationshipMap Between Coded Concepts ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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'''
| |
| − | |
| |
| − | {| class="prettytable"
| |
| − | ! <center>Match Algorithm Code</center>
| |
| − | ! <center>Description</center>
| |
| − |
| |
| − | |-
| |
| − | | 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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''Description'''
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | '''Inputs'''
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | '''Outputs'''
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | Invariants
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | '''Precondition'''
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | Postconditions
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | '''Exception Conditions'''
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | '''Aspects left to RFP Submitters'''
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | Relationship to levels of conformance
| |
| − | | Relationship
| |
| − |
| |
| − | |-
| |
| − | | Miscellaneous notes
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | | '''Other relevant content'''
| |
| − | |
| |
| − |
| |
| − | |}
| |
| − | === Concept Mappings ===
| |
| − | === Create Mapping Between Coded Concepts ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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'''
| |
| − | |
| |
| − | {| class="prettytable"
| |
| − | ! <center>Match Algorithm Code</center>
| |
| − | ! <center>Description</center>
| |
| − |
| |
| − | |-
| |
| − | | 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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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 ===
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | '''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:
| |
| − |
| |
| − | # SFMs shall provide a conformance profile supporting HL7 content where relevant
| |
| − | # We shall not preclude the use of non-HL7 content
| |
| − | # SFMs will reuse to the maximum extent possible the content models as defined in other standards (for example, HL7 RMIMs)
| |
| − | # Information content representations shall be represented in platform-agnostic formalisms (e.g., UML)
| |
| − | # 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).
| |
| − | # 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.)
| |
| − | # 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
| |
| − |
| |
| − | [http://informatics.mayo.edu/LexGrid/downloads/CTS/specification/ctsSpec/cts.htm HL7 Common Terminology Services]The 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.
| |
| − |
| |
| − | [http://informatics.mayo.edu/ The Lexical Grid]The 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.
| |
| − |
| |
| − | [http://www.omg.org/technology/documents/formal/lexicon_query_service.htm The OMG Terminology Query Services (TQS) specification]TQS 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 terminologies'''An example of this is the [http://www.clinical-info.co.uk/ct3.htm "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 [http://www.clininfo.co.uk/clue5/index.htm (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 [http://jterm.ucdavis.edu/ 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) 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 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.
| |
| − |
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | 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:
| |
| − |
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | 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 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.''
| |
| − |
| |
| − |
| |
| − |
| |
| − | {| class="prettytable"
| |
| − | | EHR Function ID
| |
| − | | EHR Function Name
| |
| − | | EHR Function Statement
| |
| − | | Notes
| |
| − |
| |
| − | ''For every row, explain the rationale for including in this specification.''
| |
| − |
| |
| − | |-
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − |
| |
| − | |-
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − |
| |
| − | |}
| |
| − |
| |
| − |
| |
| − | ----
| |
| − | <references/>
| |
