As references to terminology codes may exist in both health records and CDS artifacts, the inference engine needs to be able to access terminology services to execute CDS logic. Furthermore, to maximize the benefits of using SNOMED CT, additional terminology operations, such as finding descendants of a concept and finding the value of a defining relationship, can be used. For example, a CDS rule may refer to all the descendants of 56265001 |Heart disease|to ensure that a specific cardiology CDS rule is applied to all applicable diagnoses. Similarly, a CDS rule may need to find all the active ingredients in a medication, to ensure that a contra-indication does not occur.
This section discusses some of the options that a CDS inference engine can use to access terminology content.
As discussed in section 2.1. EHR System Architecture, terminology services are those services required to load, update, access and make effective use of terminology content. Terminology services provide important functions to CDSSs, such as term searching (i.e. synonyms), definitional and reference set querying, and retrieval of map data. It is also useful if Terminology Services support the execution of the Expression Constraint Language, as this is a standardized way of representing terminology queries in CDS rules. For more information on Terminology services, please refer to the SNOMED CT Terminology Services Guide.
SNOMED CT APIs
An application programming interface (API) for a SNOMED CT enabled terminology server can be used to execute SNOMED CT searches and queries. The principle benefit of using a terminology server API is the reusability. Other systems are able to access terminology services without having to re-implement their functionality. Another key benefit is that the internal workings of the solution can be modified, improved, upgraded without impacting the external interfaces. For example, SNOMED CT can be updated, without necessitating any changes to the external systems which use terminology services. A number of commercial terminology servers offer proprietary APIs that enable SNOMED CT search and query. These include Dataline’s SnAPI solution and B2i’s Snow Owl Terminology Server.1 The following diagram depicts how the individual terminology services interact with the terminology store:
Figure 4.3-1: Terminology services and terminology store interactionsServices that load the terminology data into the server, either for installation or updating are illustrated on the left, while services which search and query over the installed terminology content are depicted on the right. The diagram also shows how the services depicted on the right could be made available to other services and components such as a CDS inference engine through the use of an API.
Standardized Terminology APIs
Standardized APIs for terminology services are also available. For example, HL7's specification for a FHIR Terminology Service, which is described as a service that lets healthcare applications make use of codes, code systems, and value sets without having to become experts in the fine details of terminology.2 The services provided include code lookup and validation, value set expansion, subsumption testing, and maintaining a transitive closure table. HL7 has also published Common Terminology Services 2 ( CTS2) which provides a standardized API that supports access to terminology servers which may contain a variety of code systems, including SNOMED CT.