Hi All,
Just thinking about the discussion that we had on the SHR community call yesterday regarding terminology services in OpenHIE 1.0, I thought I would share what we’ve done with the MEDIC reference implementation.
In our previous implementations of the EHRS RI (Versions 1 & 2) we used to use a highly regulated orchestration pattern (similar to the way OHIE 1.0 is designed) whereby the HIAL would orchestrate resolution of identifiers and terminology using CTS 1.2 (mostly aimed at validating code and code structure) for every clinical transaction. We experimented with Apelon DTS and the 3M Health Data Dictionary for this. We found that the majority of data sources below the HIAL that we were experimenting with would do code resolution on their own (simply asking for the TS as a service from the HIAL) or would just use codes provided in the base standards. We also found a few issues with this:
- It was impossible (or difficult) for the HIAL to know which valuesets it should validate/translate for every context of data in every message type for every system in the HIAL (or any combination),
- Validating was typically duplicated either at runtime or duplicated in terms of functionality as the infrastructure components (example: CR or SHR) would do a sanity checks or could translate anyways,
- Because the HIAL wasn’t the expert system, it would have to validate every code on every message which was slow, and the real expert system (the drug repository or shared health record) may have already been able to do this work locally, much faster.
For our current version of the HIAL (Version 3) we decided to take a more bus based approach whereby the HIAL merely provides services to point of care systems or infrastructure, and the decision to resolve or use that service is made by the line of business system (to use Erl nomenclature) based on what it deems necessary at the time. In our prototyping we found only three real use cases for TS were necessary on version 3 of our HIAL for day to day operations:
- Line of business system needs to translate a code for canonical purposes or to cross system boundaries (example: CR may use the TS to resolve ISO 639 2 or 3 codes used in v3 messages to ISO 639-1 codes used in v2 messages). This was only done of the line of business system couldn’t do this mapping on its own (which most simple cases were handled, with the exception of the SHR which used CTS for ICD->SNOMED translating),
- Line of business system needs to validate a code in a particular context (the SHR, on occasion would do this if it didn’t have the code in its local code tables or memory cache, I’d be comfortable saying this was a < 40% of time use case),
- Line of business system wants to be merciful to a client and fill in details of a code, or display a code in a different language (example: data source submits information with only mnemonic and code system, the SHR would fill in the display name for the code when returning results or the data source submitted data with display name in French but the consumer wishes for English).
There were other use cases such as distributing value sets we used to partners or developing the value sets to be distributed to partners/line of business systems, however this was typically a rare event and out of band, many times it also required changes to user interfaces and/or configurations. We took the stance that if a system wanted to play with our RI it had to adapt to the standardized code sets (and standards) used in the RI and it could use the TS service provided by the HIAL in a self-service mode to do this if it wished to.
Cheers
-Justin