Cross-Registery Services provided by HIM

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

heavy lifting.

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

still there.

Using the distinctions…

Transparent Service – (we will make

authorization,security,logging work)

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.

  1. [Send-Receive Clinical Data]

  2. [Normalize Messages]

  3. [Care Rules]

  4. [Register Encounter]

  5. [Master File Updates]

  6. [Quality Measures]

  7. [Multi-Use Message Routing]

  8. [Exception Handling]

[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

  1. Find the proper Patient/Provider/Facility

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

[Normalize Messages]

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.

Normalization includes

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

[b] Restructuring

Imposes the standard use of OBX’s and NTE’s for reports.

[Care Rules]

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.

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

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

[Register Encounter]

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

ORU/MDM.

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

[Quality Measures]

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)

[Exception Handling]

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.

···

Mark Tucker

Systems Engineer

Regenstrief Institute

(317)423-5552

mtucker2@regenstrief.org

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

Hi Mark,

I’ve added some comments inline in blue:

Cheers,

Ryan

···

On Wed, May 15, 2013 at 9:43 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

We decided to try out the word “service” instead of “orchestration”.

I think the word “orchestration” is still correct to use, but we should note that these orchestrations could be implemented as separate independent services.

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

heavy lifting.

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

still there.

I like this metaphor, it expresses what the HIM would be quite well. The “membrane” could be as thin or as thick as we need it to be. Either it will just perform the transparent services or it could perform more complex orchestration if it is configured to do so for a specific transaction.

Using the distinctions…

Transparent Service – (we will make

authorization,security,logging work)

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.

  1. [Send-Receive Clinical Data]
  1. [Normalize Messages]
  1. [Care Rules]
  1. [Register Encounter]
  1. [Master File Updates]
  1. [Quality Measures]
  1. [Multi-Use Message Routing]
  1. [Exception Handling]

[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

  1. Find the proper Patient/Provider/Facility
  1. 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.

So, I would view 1 as an orchestration step and 2 as a normalization step in the HIM, these could be implemented as small modular services to perform these functions.

[Normalize Messages]

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.

Normalization includes

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

[b] Restructuring

Imposes the standard use of OBX’s and NTE’s for reports.

This seems similar to the normalization step discussed in the previous section. Is there anything extra that I’m missing or are they quite related?

[Care Rules]

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.

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

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

Thanks for this explanation, it was very interesting. It seems like having an external service to do this sort of processing would be the best way to go, this allows the data that need to be stored to execute the rules may be stored in a way that makes this querying efficient. Doing this sort of processing in the SHR may prove to be difficult in the long run. Having a dedicated service for this seems to make sense.

[Register Encounter]

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

ORU/MDM.

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

I’m not familiar with HL7 master file messages, what do you mean by this. Is it loading of bulk data from a HL7 message?

[Quality Measures]

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.

Is this similar to a data warehouse or similar reporting solution? Capturing these sort of quality measures seems essential for a healthy HIE. I would also imagine a separate service to be used for this in OpenHIE.

[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)

[Exception Handling]

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.

This is important and perhaps we don’t have enough in the requirements for a interoperability layer about this. I’l try add a bit about exception handling. I think your ESS is great. We are finding similar problems in RHEA. We have a bunch of exception occurring and many of them are from the same underlying reason, so being able to group messages by a exception type would be highly beneficial.

Mark Tucker

Systems Engineer

Regenstrief Institute

(317)423-5552

mtucker2@regenstrief.org

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

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org