The Terminology Services component of the Open HIE Architecture provides a centralized source for the HIE’s standards and definitions, including terminologies, ontologies, dictionaries, code systems, and value sets. Other HIE components can use these standards and definitions to normalize clinical data and achieve consistent aggregation and reporting.
By using Terminology Services, an HIE can achieve semantic interoperability of its data. Semantic interoperability (or interoperability of meaning) enables accurate, consistent reporting and aggregation of clinical data. It also enables accurate exchange of information among members of the provider community, including labs, clinics, pharmacies, hospitals and imaging centers, which leads to improved patient care decisions.
Benefits of the use of a Terminology Service include:
A Terminology Service exposes a set of run-time functions (services) that support other OHIE components. These Terminology Service functions are typically actions found in the primary OHIE Workflows (see example below). Four primary functions have been identified. Depending upon the specific Workflows required in an implementation, not all of these functions may be required, but an OHIE-compliant Terminology Service should support all of these features.
To be OHIE TS component, the TS application must be able to support the OHIE workflows listed below. Implementations may support only the workflows needed to support their use case. All of the required functions below are to be implemented using the associated HL7 FHIR Terminology Service specifications, e.g. Resources and Operations:
Code Existence: Is ‘123XYZ’ an ICD-10 code?
Code Membership: Is ‘123XYZ’ in the HIV ValueSet?
Value Set Expansion: Get the codes in the HIV ValueSet.
Code Mapping: What is the SNOMED CT code for ‘123XYZ’?
An OpenHIE component should consider the following OpenHIE Non-Functional Requirements - Draft