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.
Outgoing data destined for external consumers may need to be translated to other coding systems.
in relation to working with interoperability layer (IOL)? - 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)