...
- TS Service Levels
- Does the TS support only simple (unstructured) queries, or does it accept a structured message, and potentially acts on the message appropriately?
It is assumed that the interoperability layer (IOL) will orchestrate much of the interaction with the TS.
Incoming data destined for the SHR will need to be validated against existing terminology standards in the TS.
Outgoing data destined for external consumers may need to be translated to other coding systems via the TS.
So the TS may need to be consulted many times for an incoming message or an outgoing message.
For discussion purposes, consider that 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 that may need validation.
Units and reference ranges are closely related to interface terminology, and not reference terminology, so where these two reside
could depend on which service model the TS uses.
In an unstructured query service scenario, the IOL would make a call to the TS for each data item in the incoming message.
The IOL would loop through these items and validate that terminology standardization had been achieved.
In this scenario, the TS only has to respond to simple queries for terminology and does not need to understand
the complexities of the message being processed.
In a structured query service scenario, the incoming message could be passed off to the TS, which could perform predefined terminology validation protocols
on the message.
These predefined protocols would be based on message structure (HL7 v2, HL7 v3, etc) and message type (ORU, CDA, CCD, etc).
An example protocol might be: If it is a HL7 v2 ORU message, validate OBX 3, OBX 5, OBX 6, and OBX 7. [how does the TS known which segments to validate? is this based on a supplied user "profile? - jeb] The Where these protocols would reside will need to be
determined. The terminology validation needed would be the
same as in the unstructured query service scenario,
but the structured service would not rely on the IOL and instead do all the parsing necessary to validate the
terminology in the message.
The TS may also be required to append/integrate the standardized codes to the message and return the "normalized" message to the SHR.
Much of the same parsing and validating machinery needed for this would be the same as the IOL requires.
The question becomes whether this terminology parsing and validation machinery should reside in the TS as well as the SHR. - Approaches to Scalability
-How to improve message throughput
As larger countries implement OpenHIE, one important metric to consider is message throughput.
Message volumes of greater than 250 messages/minute might be expected. This should influence the
architectural questions that relate to message throughput.
The following two approaches are being discussed.
Applications access the TS in real time
In this scenario, the TS is fully integrated in the operational infrastructure of the HIE, and must be online and available
any time other components are in operation. Applications don't maintain a copy of standard terminology, but query the
TS in real time when needed. This is easiest in terms of overall terminology standardization and deployment, but adds
some complexity in terms of network connectivity and the need for real-time terminology updates to a live system.
Applications use curated copy of terminology
In this scenario, the TS is still the source of truth for all terminology, but it is not required to be online and available all the time.
It would be an integral part of disseminating terminology throughout the enterprise by creating curated copies of terminology that
would be consumed and incorporated by applications. The two important applications that would use these curated copies
would be the SHR and the Point-of-Care systems.
One advantage of this curated copy approach is that network infrastructure is not as critical to operations, since Point-of-Care systems
could continue without a network connection to the central system. They could continue with the latest update they had received from
the central system. Another advantage of this approach is that updates by terminologists can be staged for deployment with less
interference with the live system.
Real-time access optimized for certain pipelines
In this scenario, as with the real-time scenario, the TS is an integrated component of the HIE that's always online and available. Most applications will interact with the TS directly. However the pipelines in the HIE that have high-performance requirements are optimized by using cache servers and/or curated copies of the terminology (as with the second scenario). One example of such a high-performance pipeline is terminology validation for incoming encounters. One way in which to optimize this validation could be to use an in-memory cache (such as memcached) placed in between the IOL and the TS. A validation query would therefore hit the cache first for a code, and only query the TS in the event of a cache miss. Since terminology tends to be static (in the sense that the content doesn't change multiple times per second, but rather periodically (hours, days or even months)) caching may be highly suitable. A downside to this approach however is that when a change does occur on the TS, the cache will be out of date for a certain period of time. - Change management
-How to handle life cycle of terms/codes.
All standard Code Systems change over time. While most modern Code Systems no longer actually DELETE concepts/codes, many do change concept names and/or inactive/retire codes. A retired code should not be used past its effective date. Thus a TS must maintain a history of all codes in a code system and be able to respond to queries based on the code's date, or version. The type of queries used will typically vary according to the specific use cases of the HIE (or SHR). Validation of a new code entry, for example, would normally be performed against on the most recent ("active") version of a Code System, but validation/conversion for an historical (longitudinal) query may depend on the date the code was originally entered into the system. It is generally not practical, or clinically correct, to convert historical codes "en-mass" to their their "modern" counterparts.
-How to mark terms that are deprecated or superceded.
The TS will typically maintain a Status attribute on code/concepts to determine their state. This Status will be associated with a date or version and will be updtaed when the Code System is updated as a result of a release from its SDO. In addition to updating the Code System history, these releases often invoke a workflow to update any existing mapping to (from) the Code System (if such mappings are not supplied by the Code System developer.) So -called "local" mappings are a good case in point. If any targets of a local mapping are retired, the workflow supports clinical review and curation of updates to the mapping to bring it in line with the new state of the Code System. The reverse process can occur with updates to the local terminology. Different TS implementations will typically address this workflow in different ways. .
...