Skip to end of metadata
Go to start of metadata

Overview

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:

  • Standard Data:  Using common terminology is vital for knowledge sharing over multiple locations. National and international code systems and value sets should be readily available for validation, comparison and aggregation with local data.
  • Improved Care:  Accurate and consistent data collection improves patient care analysis. Comparable patient data within and between patient populations leads to more consistent care delivery.
  • Better Reporting: Standardized data element representations result in consistent and accurate reporting.
  • Coordinated Care: Consistent and comparable analysis of healthcare utilization data leads to more informed decisions about resource allocation.

Standards and Workflows

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’?


Note: Defining these are OHIE workflows is currently in progress.  

Requirements

Support of OpenHIE Non-functional Requirements 

An OpenHIE component should consider the following OpenHIE Non-Functional Requirements - Draft

  • No labels