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 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.

 

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 Warning! Do not forget to enter a URL within the iframe!

 

  • No labels

1 Comment

  1. David Aronow

    I have a bunch of comments about this excellent draft laying out the assumptions and context for TS.

    • 1 TS Service Levels: bullet 2 - 'will need to be validated against' - does this mean will be normalized to also, or should that be a separate bullet?
    • 1 TS Service Levels: paragraph 2 - 'units...are...not reference terminology' - I believe units need to be recognized as a highly managed reference terminology in themselves
    • 2 Approaches: Applications use curated - in my work, we completely uncouple the TS from production and operational applications, with scheduled updates published to the development and production environments, as well as a process for ad hoc push of urgent updates from the TS to those environments.
    • 3 Change: How to mark terms - need to support additional terminology 'calculus', such as merge and split of concepts
    • 5 SHR's persistence: first sentence - suggest we add numeric data type and maybe get the phrase Controlled vocabulary in the sentence, maybe as elaboration on coded data
    • 5 SHR's persistence: Store both - is this a discussion of whether feeder systems will all be normalized to the SHR standard (which I see as a combo of industry standards and SHR extensions)?  I might be talking about something different, but in my experience, it is optimal to store the local/feeder/native format representations (code, description, metadata), plus the transitional states that might be needed in normalization/transformation steps, and finally the HIE standard representation.  Does OpenMRS support this?   Also, we find in not uncommon for local systems to provide a primary and an alternate representation, both of which need to be documented in some fashion.

    Thanks, David

This work is licensed under a Creative Commons Attribution 4.0 International License.