We decided to try out the word “service” instead of “orchestration”.
The big question is
“What are the services provided by the Central Node?”
I use the phrase “Central Node” because sometimes it is good to think
of the HIM + Registries + SHR + CareRules all as one big abstraction
from the point of view of the Edge Nodes. Usually, for any given
service of the Central Node, it is obvious which component does the
I think that the HIM is the actual outer layer of the
Central node. We talked about how to use tiny proxies around the core
Registries: The proxy might handle the HIE-wide authentication service
before passing the call off to the registry. In that case, the HIM is
very thin, but the client is touching the proxy, not the
registry itself. The interface between an Edge Node and the Central
Node is like a “membrane”. The membrane can be very thin, but it is
Using the distinctions…
Transparent Service – (we will make
Single Registry Services – each sub-group will create a
nicely defined abstraction and clean interface
to their abstraction.
Cross Registry Services – (everything else ?)
… the intent here is to list out some important services.
[Send-Receive Clinical Data]
[Master File Updates]
[Multi-Use Message Routing]
[Send-Receive Clinical Data]
The bread and butter of the information exchange is receiving new clinical data.
At Regenstrief, this task is largely implemented by our SHR (which has
plenting of code mapping rules. It also relies on a pre-processor
(which would be part of the HIM) that will re-write the incoming HL7 message.
The pre-processor can be thought of as doing two main tasks
Find the proper Patient/Provider/Facility
Changing the structure of the incoming message to make
it conform to our HL7 Conventions. (For example, some
senders send the actual microbiology data in NTE’s, so the
pre-processor moves it into the OBX.) In the worst case,
each pre-processor might be sender-specific.
Use Case: Edge system creates a local message, and hasn’t been
able to abide by all the HIE-wide conventions.
It passes the message to the HIM, and the HIM returns a
“normalized version of the message.”
We might imagine that the client says: Please fix up my message,
and this service returns it, all spiffed up, with the information
“easily accessible” in the HL7 message.
In this use case, the goal of the Normalization Service is to do
all the pre-processing and message enrichment (ie, with proper
patient, provider, and observation terminology codes) so that we
the message would be “consumable” without further pre-processing.
[a] Enrichment ( Patient/Provider/Facility “enrichment”. HIM
consults the registry, and returns the standard codes and
the standard display names. For Patients, it may return
the set of known registrations. For terms, it may map
local to international code sets.)
Imposes the standard use of OBX’s and NTE’s for reports.
We know that we want the entire health system to operate with a
focus on Treatment Protocols. One function of the HIM will be to
track the progress of a patient through the assigned protocol, and
generate reminders (etc) to help keep him on track.
How this might work:
[1: Real Time] The Edge node sends in a checkin message.
We run rules, and create a form with suggestions on care.
We send this suggestion back to the Edge Node along with the
Continuity of Care Synopsis data.
[2: Batch] On a regular basis, we compute that status of all
patients with respect to their treatment protocol. We initiate
reminders, and push them, unsolicted, to Edge Nodes.
We can imagine this service being implemented in two ways.
- In the SHR – If your deployment has a sophisticated rules
engine built into the SHR, the rules can be encoded and
executed there. If so, then the HIM is responsible for
invoking/trigger the SHR rules, and then bundling off the
alerts, and perhaps making the appropriate HL7 message to
send to the Edge Node.
- As an external Rules Service.
The idea here is that the HIM will have the rules
engine. Roughly, it will ask the SHR for data, and then the
HIM will crunch that data in its own rule engine.
When the rules are done, the HIM then generates the
appropriate HL7 messages, as in case #1.
At Regenstrief, we have experience with two “external rules”
systems. In one case, upon certain triggers, we bundle up
our clinical data into an XML package, and send it to Boston
to have some rules run.
In the other case, the “external system” is really just
DROOLS – we mine our SHR, and re-represent the relevant portion
as DROOLS objects, and load it into DROOLS working memory.
OpenMRS does a similar thing.
This is “external” in the sense that the rules engine can be
fiddled or exchanged without a change to the SHR.
This discussion suggests that one component of the HIE ,
besides the registries, might be a RulesEngine.
It may be too much effort to define a standard-generic
interface to such an Engine. Perhaps it has been done by
some of the JSRs.
Chris mentioned this use case. I prefer to role example up into use
case 1 : Send-Recieve clinical data. All the specific medical
domains will just be examples of standard HL7 messages.
(ORU, ORM and RDS …)
We can express the clinical scope of what we cover by describing
which HL7 chapters we cover. Most clinic data just falls into
[Master File Updates]
This “service” can be thought of as the HL7 expression (as MFN
messages) of one aspect of a Single Registry Service.
For example, the ClientRegistry will have its own cute Restful
interface, but it would also define how to use HL7 master file
messages to do loading.
So, this is not really a MultiRegistry service.
One “service” of the Indiana Health Information Exchange is to run
“quality measures” that rank the care of individual patients with
respect to “good practice” criteria.
In our world, quality metrics are implemented by running a special
outside-the-SHR application that heavily mines the data of the SHR,
but is itself independent of the SHR.
In the OpenHIE world, the QM application would be inside the
Central node, but outside the SHR and other Registries.
It may itself be complicated, but, in terms of orchestration, it is
not complicated. In our implementation, it runs as a periodic
batch job. If we tried to maintain these measures incrementally,
then it might want to monitor a “Dirty Patient” notification
stream, or even monitor the individual data updates within the SHR.
A simple Dirty Patient service can be implemented by skimming the
HL7 streams. A sophisticated term-by-term data update feed
requires hooks in the SHR.
[Multi-Use Message Routing]
A final function that the Regenstrief system does is "Route message
streams to ‘downline’ consumers." We have a number of external
systems that need copies of certain messages. For example, all
emergency room admissions are routed to the department of state.
This is exactly the kind of routing that interface engines such as
Mirth are good at. The engine doesn’t really transform the message,
but mainly sorts out the stream. My personal bias is not to do any
interesting transformations in the engine. My motto is pretty
extreme: "Anything worth doing is worth doing in a java call that I
can reuse and re-apply without the need to pass my special case
through a special case Mirth channel."
A little message tweak that only applies to a particular downline
system I might do in the engine.
I think the HIM should include an Interface Engine. Ones like Mirth
have nice user interfaces, and make simple things simple. I prefer to
use Mirth to do my LLP listening and sending, but have the channels
read and write to SQL based persistent message stores. (Basically, a
table indexed by sequence number and having a message body)
The final function of the HIM is to do a good job of Hl7 Exception Handling.
Perhaps this is part of the SHR. We haven’t mentioned it before.
In our world, we have an elaborate “Exception Handling Subsystem”
[ESS] that let users see and manipulate sets of messages. For
example, all messages with appfac AAA|BBB, that have an unknown code
OBX “C1312” would be in one “line” of the display. Term Mapping
experts examine message, define mappings, and then order the
re-execution of messages once the new mappings are in place.
The exception mechanism of Mirth, for example, is ludicrously
underpowered for the task.
Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended
solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from
making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not
sufficient for this purpose.
If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited