scope:

This material seeks to establish an international framework for the development of an application programming interface (API) that can be used by messaging software when accessing terminological content. It is not intended to be a complete terminology service in and of itself. Health Level Seven (HL7) Version 3 (XML-based) standards are based on a reference information model (RIM) which is flexible and general in structure. Representation of information within this model is dependent on the availability of terminological resources which can be used to populate the properties of the model with appropriate semantic content. Whenever possible, the HL7 Version 3 standard references existing terminological resources instead of attempting to create a new resource within the standard itself. Because exernal terminological resources can vary considerably in both content and structure, the CTS identifies 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. l The current version is not intended to be a complete terminology service. The scope of CTS is restricted to the functionality needed to design, implement and deploy an HL7 Version 3 compliant software package. In much the same spirit as the XML/SGML relationship, the HL7 CTS is meant to represent a proper subset of functionality that may be provided by more sophisticated APIs such as that represented by the OMG TQS specification. l It is not intended to be a general purpose query language. It is intended to specify only the specific services needed in the HL7 implementation. l It does not specify how the service is to be implemented. It is intentionally silent when it comes to service advertising and discovery, establishing and maintaining connections, and the delivery and routing of messages. It is presumed that a CTS implementation will use the underlying architecture that is most appropriate for the given implementation circumstances. The following general principles were used while developing the HL7 CTS specification: 1. It shall be easy to write programs that use HL7 CTS. 2. The intent of the HL7 CTS is to specify core services only. 3. The design of HL7 CTS shall be formal and concise 4. The initial implementation technology for HL7 CTS will include XML. 5. HL7 CTS shall be compatible with the nomenclature, model and approach expressed in the HL7 vocabulary document, the Version 3 RIM and its derivative structures. 6. Whenever possible, the HL7 CTS shall remain a consistent subset of the Object Management Group (OMG) Terminology Query Services (TQS) provided that the TQS terminology model does not conflict with other HL7 CTS design principles. If it is discovered that the TQS model is conflicting with HL7 CTS design principles or is incomplete, or incorrect, good faith efforts should be made to notify the appropriate revision task force. 7. HL7 CTS should limit the assumptions about the form and structure of a terminology to those necessary to support HL7 implementations. There is no generally accepted standard for terminology services but there are several sources of material on this topic. l 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. l The DAML + OIL and OWL Web Ontology Language While this is not strictly a terminology server specification it contains elements from the representation of ontological aspects that are relevant to some of the large scale terminologies such as SNOMED Clinical Terms, NHS Clinical Terms Version 3 and GALEN. However, this web based proposal is also a heavy weight specification that is unlikely to facilitate early widespread implementation. l API specifications specific to individual terminologies An example of this is the "Read Code - Version 3 API" specified for the NHS Clinical Terms in 1996 and revised in 1998. Work is proceeding to develop a SNOMED CT API based on similar principles. There is an informal understanding that this specific API will converge with or utlize elements of the CTS where these are appropriate. A COM implementation of this is supported by at least one freeware coding engine (CLUE). Specifications of this type identify many of the general functions needed to access a terminology. However, they are inevitably specific to the needs of a particular terminology. Explicit support for a single defined terminology model allows efficient implementation within an operational environment at the expense of the flexibility to access other terminologies. l General purpose RDBS interfaces including SQL and ODBC For "simple" code lists, a simple SQL query may be the most efficient way to look up a code. In addition to the code-value / code-meaning pairs, however, many coding schemes have other relevant properties that may only be accessed through a secondary service. This does not prevent the use of SQL but it requires a common model against which queries can be run and an efficient means of returning the properties required. These additional properties apply to the scheme as a whole as well as to individual entries in the terminology. l 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. TQL provides a rich mechanism that deals specifically with common properties and relationships in terminological models. A working Java-based implementation of TQL can be downloaded for free from the web.