Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Below is a list of presumptions around the terminology services layout that the OHIE-Terminology Services community is debating and cultivating.

Info
titleThis is a DRAFT list and is under construction.

 

The OHIE Terminology Service (TS) 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 TS.   Here are some areas that the OHIE-Terminology Services community has been discussing.

 

...

For discussion purposes, consider that a typical patient encounter may have say 5 to 20 individual concepts, with each

...

 
-Process for continual periodic updates to common coding systems (ICD 9, ICD 10, LOINC, RXNORM, SNOMED CT, etc).
The TS is typically updated via an external, and unique to the TS implementation, load process. Input data files can be taken directly from an SDO distribution, or post-processed by an application that puts the varied source formats into a standard load file format appropriate for the TS. Update scheduling is usually driven more by HIE operational procedures and policies than by the (greatly varying) distribution cycles of the SDOs. In complex environments, loads may be cycled through separate Q/A, Testing, and Production TS platforms to ensure data integrity.

...

Please note that the Google Doc below can be used to add comments/feedback for discussion. Access the live document via this link.

Iframe Macro
srchttps://docs.google.com/document/d/18V3o_hp4s-GNfR0HZD3OlIf-grmyf9G8I1Qh94ikBfI/edit?usp=drive_web

 

...

- The mapping could be initiated by the IOL when an encounter is sent by a PoC. This means that the TS would need to manage the PoC's interface terminology as well the mappings to the reference terminology. The IOL takes the responsibility of providing the SHR with a normalized encounter.

...

- The PoC itself takes on the burden of mapping the codes it sends to the IOL by storing the reference terminology mappings in it's own data model. These mappings are informed by the TS Implementers supporting these PoC systems would need methods for periodically querying the TS for code updates or exports of terminology spaces.

...