Below is a list of presumptions around the terminology services layout that the OHIE-Terminology Services community is debating and cultivating.
This is a DRAFT list and is under construction.
The Data Terminology Service (DTS) is assumed to be the source of truth for all terminology, nomenclature, and coded data within the OpenHIE shared health record. It will play a central role in terminology standardization and implementation throughout the HIE. However, it is only one component of the several components that comprise the OpenHIE. There are various ways the other components could interact with the DTS. Here are some areas that the OHIE-Terminology Services community has been discussing.
- Dumb vs. Smart Service
- Is DTS a dumb service (told what to do) or smart service (see message and know what to do)
Incoming data destined for the SHR will be validated against existing terminology standards in the DTS.
Outgoing data destined for external consumers may need to be translated to other coding systems by the DTS.
So the DTS may need to be consulted many times for a single message coming in or a message
going out. It is assumed that the interoperability layer (IOL) will orchestrate much of the interaction with the DTS.
For discussion purposes, a typical patient encounter may have say 5 to 20 individual concepts, with each
concept possibly having a coded answer with corresponding units and a reference range.
In the DTS dumb service scenario, the IOL would make a call to DTS for each data item in the incoming message.
The IOL would loop through these items and validate that terminology standardization had been achieved.
In the DTS smart service scenario, the incoming message could be sent to DTS which could perform defined protocols on the message.
These predefined protocols would be based message structure and message type. - Approaches to Scalability
-How to improve message throughput - applications access DTS in real time or use curated copy of terminology. - Change management
-How to handle life cycle of terms. Continual periodic updates. Terms that are deprecated, superceded. - Deployment
- How terminology is disseminated throughout enterprise - via api call or sftp file transfer - SHR's persistence model
- single code or multiple codes
-only 1 cardinal code stored or 1 cardinal code plus 1 equivalence code stored (Ministry 1 coding system, Insurance other coding system)