Strawman V2 Backbone

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

strawman_v2_backbone.txt (6.17 KB)

figure1_v2_backbone.pdf (37.4 KB)

figure2_making_perfect_edge.pdf (33.5 KB)

figure3_exceptions.pdf (37 KB)

···

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

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures and orchestration of messages. This is exactly where I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

···

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.

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

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


Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Ryan,

While I agree with you in principle that the central component does orchestration and is in principle independent of the message format, I just want to reiterate
that my intent was to press the point that the central component ought not be considered too abstractly. That if you use V2 messages, then the thrust of the central node is to normalize the incoming messages, and even that may be unnecessary *if *
your edge nodes are already consulting the registries when then construct their messages.

I find the simplicity and concreteness of V2 helps me move forward.

Mark

On Behalf Of Ryan

···

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures and orchestration of messages. This is exactly where
I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.

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

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

Ch. 3 In What format should data be handled?

S. Preamble.

Basically, I want to argue in favor of the use of Hl7 V2 as the

lingua franca of the OHIE. Within INPC in Indiana, we have 30 years

of experience with it, and 15 years of using it in a multi-institution

exchange. V2, as opposed to V3, is easy to pick up. It is easy for

new developers to work with, and does not require sophisticated

tooling.

When I first saw HL7, I thought: "You call this mess a standard?

(Everyting is optional)" Over the years, I found that I would not be

disappointed if I thought of HL7 not as a standard, but as "a starting

point for negotiations." You are so much better off with V2 than

nothing.

In recent years, things have gotten much better. Now, with

standard provider ID’s, LOINC, …, it has gotten much easier to

actually be able to process data from new institutions without alot of

negotiating. Now, in OpenHIE, with the prospect of national

registries for patients, providers and locations, and a Ministry of

Health mandating the use of code systems, and mandating the collection

of specific data elements, I stand aghast, and wonder if there is

anything left for me to do. It’s all been solved.

So, as we ponder the OpenHIE architecture, I constantly run a straw

man scenario in parallel with the discussion. It works like this:

If I had the V2 Backbone as sketched below, how would I solve problem X?

S. Strawman Backbone

Figure one shows the overall architecture.

The “V2 Backbone” is the combination of the registries

CR: Client Registry

PR: Provider Registry

FR: Facility Registry

TS: Terminology Server

SHR: Shared Health Record

WH: Warehouse

—: and the spine is the HIM backbone.

The out rounded rectangle is the boundary of the backbone.

Three Edge nodes are pictured.

Arc #1 shows a V2 message travelling

to the backbone. It represents the captured information from an

encounter. It is new information flowing into the SHR.

Arc #3 shows submissions actually flowing into the SHR, where they are stored.

Arc #2 shows a patient download being sent to a new edge node. A

patient has just arrived, and a full download of data is being sent to Edge2.

It is a pile of “perfectly formatted V2 messages”, having been

normalized by the central node.

Users interact with Edge2 to provide care, and, presumably, new

submissions like message#1 flow from that encounter.

The messages of arc#2 are exactly the outbound messages “regurgitated”

by the SHR based on already known data.

Finally, Edge3 shows a system that acts as a concentrator/server for

hand held devices. The point is that Edge3 needs to know V2. The

protocol for the interactions (arc#4) with the handsets does not have

to be V2. Edge3 holds the smarts.

When I see this picture, I want to say:

[1] Suppose Message arc#1 is “perfect” V2. That is, it has

the patient, provider, facility, and codes already correct,

and the clinical segments are properly shaped. (That is, the

proper OBX’s are used to represent laboratory panels,

documents, annotated documents, and micro results. The

software that generates message#1 has been validated at build

time to use the HL7 implementation guides defined by the

backbone.)

With this perfect message, the HIM mediator needs do nothing:

Just send it to SHR.

[2] Likewise, the downloads arc#2 are easily handled, since

they are perfect messages by construction. There

are no surprises to Edge2. Once it has been built to handle

the three shapes of data, it easily consumes a long string of

patient backload messages.

[3] Much of the hard work of the OHIE effort is encapulsated in

establishing the CR,PR, and FR registries.

[Figure 2]

But, how did message#1 become “Perfect?”

The hard part is getting the patient and provider correct.

The software is designed to build properly shaped messages, and the

master files for observations are pre-loaded with the proper LOINC codes.

Figure 2 shows the “Choose Pt” dialog box.

Behind it is a controller. It may need to consult the Client Registry

“at runtime” to help the user choose the right person. It seems

natural to say that the Client Registry is exposed with a simple

restful interface. Code inside the controller would invoke restful calls.

When the user makes his choice, he has chosen a precise person, and

this person is inserted in the right place inside the perfect message#1.

This scenario suggests that we want to expose the internal Registries

to real-time access by modules within the edge nodes.

I would expose them with the simple restful interface.

[Figure 3] Imperfect Inbound Messages: Work by the Mediator

Suppose that Figure1’s message#1 was not perfect.

In this case, the flow is something like Figure 3.

Edge1 emits an imperfect message #1. It flows in V2 to the backbone.

The mediator then tries to make sense of it, invoking all the

registries that it can (Step #2). If it can make sense, it stores it

into the SHR. But, when there are errors, the mediator

(eventually/asychnronously) emits a V2 exception report message#3 that

flows back to the edge node. The edge node then needs some sort of

“Exception-handling Sub System” that fields the exception report.

Users will have to fiddle with existing data (Step #3.b), to correct

for – react to – the exceptions. Once fixed, a corrected message

(#4) will be sent out, and, finally being perfect, it will be stored

in the SHR (#5).

In our world, the Exception SubSystem (ESS) is a big, big, part of our

workflow and the sucess of our HIE.

S. Summary

I had wanted to convince you, fellow OHIE’ers, that we should

think of our problem as the problem of creating perfect V2 messages to

flow from Edge nodes to Central Backbone, and from Backbone to

Edgenodes.

The process of solving the warts in V2 messages is tantamount

to solving the terminology and naming issues that make large system

hard. The process of making the use of OBR’s and OBX’s understandable

will mean we have solve the problem of data representation.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Mark et al.

I believe the premise of having an ESB (a HIM) is an architectural one. But it is a fundamental architectural element that, if you’re going to make it work, will enforce some important patterns. One of these is: everyone talks to the HIM. You don’t do an end-run around the HIM and start independently touching the registries – you always submit your unit of work to the HIM who executes it on your behalf against assets “above the HIM”. Absent that rigour, we really don’t have a way to do two important things:

  1. Centralize shared services (security, authentication, audit, etc.)

  2. Mitigate the rampant proliferation of many-to-many communications channels (the dreaded permutations and combinations problem).

I’m finding the commentary about how HL7v2-ish this needs to be a bit confusing. This pattern, if we embrace it, turns some (maybe all) of the issues about v2 vs. v3 (CDA) vs. DICOM into a “don’t care” proposition… which is another HUGE benefit, in my view.

Warmest regards,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

···

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Tucker, Mark
Sent: April 29, 2013 11:43 AM
To: openhie-shr
Subject: RE: Strawman V2 Backbone

Hi Ryan,

While I agree with you in principle that the central component does orchestration and is in principle independent of the message format, I just want to reiterate that my intent was to press the point that the central component ought not be considered too abstractly. That if you use V2 messages, then the thrust of the central node is to normalize the incoming messages, and even that may be unnecessary if your edge nodes are already consulting the registries when then construct their messages.

I find the simplicity and concreteness of V2 helps me move forward.

Mark

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Ryan
Sent: Monday, April 29, 2013 6:23 AM
To: Tucker, Mark
Cc: openhie-shr
Subject: Re: Strawman V2 Backbone

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures and orchestration of messages. This is exactly where I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ch. 3 In What format should data be handled?

S. Preamble.

Basically, I want to argue in favor of the use of Hl7 V2 as the

lingua franca of the OHIE. Within INPC in Indiana, we have 30 years

of experience with it, and 15 years of using it in a multi-institution

exchange. V2, as opposed to V3, is easy to pick up. It is easy for

new developers to work with, and does not require sophisticated

tooling.

When I first saw HL7, I thought: "You call this mess a standard?

(Everyting is optional)" Over the years, I found that I would not be

disappointed if I thought of HL7 not as a standard, but as "a starting

point for negotiations." You are so much better off with V2 than

nothing.

In recent years, things have gotten much better. Now, with

standard provider ID’s, LOINC, …, it has gotten much easier to

actually be able to process data from new institutions without alot of

negotiating. Now, in OpenHIE, with the prospect of national

registries for patients, providers and locations, and a Ministry of

Health mandating the use of code systems, and mandating the collection

of specific data elements, I stand aghast, and wonder if there is

anything left for me to do. It’s all been solved.

So, as we ponder the OpenHIE architecture, I constantly run a straw

man scenario in parallel with the discussion. It works like this:

If I had the V2 Backbone as sketched below, how would I solve problem X?

S. Strawman Backbone

Figure one shows the overall architecture.

The “V2 Backbone” is the combination of the registries

CR: Client Registry

PR: Provider Registry

FR: Facility Registry

TS: Terminology Server

SHR: Shared Health Record

WH: Warehouse

—: and the spine is the HIM backbone.

The out rounded rectangle is the boundary of the backbone.

Three Edge nodes are pictured.

Arc #1 shows a V2 message travelling

to the backbone. It represents the captured information from an

encounter. It is new information flowing into the SHR.

Arc #3 shows submissions actually flowing into the SHR, where they are stored.

Arc #2 shows a patient download being sent to a new edge node. A

patient has just arrived, and a full download of data is being sent to Edge2.

It is a pile of “perfectly formatted V2 messages”, having been

normalized by the central node.

Users interact with Edge2 to provide care, and, presumably, new

submissions like message#1 flow from that encounter.

The messages of arc#2 are exactly the outbound messages “regurgitated”

by the SHR based on already known data.

Finally, Edge3 shows a system that acts as a concentrator/server for

hand held devices. The point is that Edge3 needs to know V2. The

protocol for the interactions (arc#4) with the handsets does not have

to be V2. Edge3 holds the smarts.

When I see this picture, I want to say:

[1] Suppose Message arc#1 is “perfect” V2. That is, it has

the patient, provider, facility, and codes already correct,

and the clinical segments are properly shaped. (That is, the

proper OBX’s are used to represent laboratory panels,

documents, annotated documents, and micro results. The

software that generates message#1 has been validated at build

time to use the HL7 implementation guides defined by the

backbone.)

With this perfect message, the HIM mediator needs do nothing:

Just send it to SHR.

[2] Likewise, the downloads arc#2 are easily handled, since

they are perfect messages by construction. There

are no surprises to Edge2. Once it has been built to handle

the three shapes of data, it easily consumes a long string of

patient backload messages.

[3] Much of the hard work of the OHIE effort is encapulsated in

establishing the CR,PR, and FR registries.

[Figure 2]

But, how did message#1 become “Perfect?”

The hard part is getting the patient and provider correct.

The software is designed to build properly shaped messages, and the

master files for observations are pre-loaded with the proper LOINC codes.

Figure 2 shows the “Choose Pt” dialog box.

Behind it is a controller. It may need to consult the Client Registry

“at runtime” to help the user choose the right person. It seems

natural to say that the Client Registry is exposed with a simple

restful interface. Code inside the controller would invoke restful calls.

When the user makes his choice, he has chosen a precise person, and

this person is inserted in the right place inside the perfect message#1.

This scenario suggests that we want to expose the internal Registries

to real-time access by modules within the edge nodes.

I would expose them with the simple restful interface.

[Figure 3] Imperfect Inbound Messages: Work by the Mediator

Suppose that Figure1’s message#1 was not perfect.

In this case, the flow is something like Figure 3.

Edge1 emits an imperfect message #1. It flows in V2 to the backbone.

The mediator then tries to make sense of it, invoking all the

registries that it can (Step #2). If it can make sense, it stores it

into the SHR. But, when there are errors, the mediator

(eventually/asychnronously) emits a V2 exception report message#3 that

flows back to the edge node. The edge node then needs some sort of

“Exception-handling Sub System” that fields the exception report.

Users will have to fiddle with existing data (Step #3.b), to correct

for – react to – the exceptions. Once fixed, a corrected message

(#4) will be sent out, and, finally being perfect, it will be stored

in the SHR (#5).

In our world, the Exception SubSystem (ESS) is a big, big, part of our

workflow and the sucess of our HIE.

S. Summary

I had wanted to convince you, fellow OHIE’ers, that we should

think of our problem as the problem of creating perfect V2 messages to

flow from Edge nodes to Central Backbone, and from Backbone to

Edgenodes.

The process of solving the warts in V2 messages is tantamount

to solving the terminology and naming issues that make large system

hard. The process of making the use of OBR’s and OBX’s understandable

will mean we have solve the problem of data representation.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Derek and Everyone,

I agree with all your above points regarding the idea that nodes should never go around the HIM.

I would just add another important advantage, in line with with abstraction and your second point:

  • A central HIM means there only needs to be a central configuration point for the registries,

i.e. a node doesn’t need to know when we swap out a component for another one,

or if the IP changes, or we distribute the registry instance, or put a caching server in front of it, etc.

These are all standard “operations” issues that aren’t mitigated by using standards.

And the biggest advantage is that we’ll never place the “burden” of interoperability on the nodes themselves

(and of course it gives us flexibility; they don’t need to know that our new CR doesn’t actually support PIX or

that our TS lookups are actually all cached in-memory (just for e.g.)).

Cheers

Hannes

···

On Mon, Apr 29, 2013 at 6:31 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Mark et al.

I believe the premise of having an ESB (a HIM) is an architectural one. But it is a fundamental architectural element that, if you’re going to make it work, will enforce some important patterns. One of these is: everyone talks to the HIM. You don’t do an end-run around the HIM and start independently touching the registries – you always submit your unit of work to the HIM who executes it on your behalf against assets “above the HIM”. Absent that rigour, we really don’t have a way to do two important things:

  1. Centralize shared services (security, authentication, audit, etc.)
  1. Mitigate the rampant proliferation of many-to-many communications channels (the dreaded permutations and combinations problem).

I’m finding the commentary about how HL7v2-ish this needs to be a bit confusing. This pattern, if we embrace it, turns some (maybe all) of the issues about v2 vs. v3 (CDA) vs. DICOM into a “don’t care” proposition… which is another HUGE benefit, in my view.

Warmest regards,

Derek.


Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.


Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Tucker, Mark
Sent: April 29, 2013 11:43 AM
To: openhie-shr
Subject: RE: Strawman V2 Backbone

Hi Ryan,

While I agree with you in principle that the central component does orchestration and is in principle independent of the message format, I just want to reiterate that my intent was to press the point that the central component ought not be considered too abstractly. That if you use V2 messages, then the thrust of the central node is to normalize the incoming messages, and even that may be unnecessary if your edge nodes are already consulting the registries when then construct their messages.

I find the simplicity and concreteness of V2 helps me move forward.

Mark

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Ryan
Sent: Monday, April 29, 2013 6:23 AM
To: Tucker, Mark
Cc: openhie-shr
Subject: Re: Strawman V2 Backbone

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures and orchestration of messages. This is exactly where I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

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

Ch. 3 In What format should data be handled?
S. Preamble.
Basically, I want to argue in favor of the use of Hl7 V2 as the

lingua franca of the OHIE. Within INPC in Indiana, we have 30 years

of experience with it, and 15 years of using it in a multi-institution

exchange. V2, as opposed to V3, is easy to pick up. It is easy for

new developers to work with, and does not require sophisticated

tooling.

When I first saw HL7, I thought: "You call this mess a standard?

(Everyting is optional)" Over the years, I found that I would not be

disappointed if I thought of HL7 not as a standard, but as "a starting

point for negotiations." You are so much better off with V2 than

nothing.

In recent years, things have gotten much better. Now, with

standard provider ID’s, LOINC, …, it has gotten much easier to

actually be able to process data from new institutions without alot of

negotiating. Now, in OpenHIE, with the prospect of national

registries for patients, providers and locations, and a Ministry of

Health mandating the use of code systems, and mandating the collection

of specific data elements, I stand aghast, and wonder if there is

anything left for me to do. It’s all been solved.

So, as we ponder the OpenHIE architecture, I constantly run a straw

man scenario in parallel with the discussion. It works like this:

If I had the V2 Backbone as sketched below, how would I solve problem X?

S. Strawman Backbone
Figure one shows the overall architecture.

The “V2 Backbone” is the combination of the registries

CR: Client Registry
PR: Provider Registry
FR: Facility  Registry
TS: Terminology Server
SHR: Shared Health Record
WH: Warehouse
---: and the spine is the HIM backbone.

The out rounded rectangle is the boundary of the backbone.

Three Edge nodes are pictured.

Arc #1 shows a V2 message travelling

to the backbone. It represents the captured information from an

encounter. It is new information flowing into the SHR.

Arc #3 shows submissions actually flowing into the SHR, where they are stored.

Arc #2 shows a patient download being sent to a new edge node. A

patient has just arrived, and a full download of data is being sent to Edge2.

It is a pile of “perfectly formatted V2 messages”, having been

normalized by the central node.

Users interact with Edge2 to provide care, and, presumably, new

submissions like message#1 flow from that encounter.

The messages of arc#2 are exactly the outbound messages “regurgitated”

by the SHR based on already known data.

Finally, Edge3 shows a system that acts as a concentrator/server for

hand held devices. The point is that Edge3 needs to know V2. The

protocol for the interactions (arc#4) with the handsets does not have

to be V2. Edge3 holds the smarts.

When I see this picture, I want to say:

        [1] Suppose Message arc#1 is "perfect" V2.  That is, it has
        the patient, provider, facility, and codes already correct,
        and the clinical segments are properly shaped. (That is, the
        proper OBX's are used to represent laboratory panels,
        documents, annotated documents, and micro results.  The
        software that generates message#1 has been validated at build
        time to use the HL7 implementation guides defined by the
        backbone.)
        With this perfect message, the HIM mediator needs do nothing:
        Just send it to SHR.
        [2] Likewise, the downloads arc#2 are easily handled, since
        they are perfect messages by construction.  There
        are no surprises to Edge2.  Once it has been built to handle
        the three shapes of data, it easily consumes a long string of
        patient backload messages.
        [3] Much of the hard work of the OHIE effort is encapulsated in
        establishing the CR,PR, and FR registries.

[Figure 2]

But, how did message#1 become “Perfect?”

The hard part is getting the patient and provider correct.

The software is designed to build properly shaped messages, and the

master files for observations are pre-loaded with the proper LOINC codes.

Figure 2 shows the “Choose Pt” dialog box.

Behind it is a controller. It may need to consult the Client Registry

“at runtime” to help the user choose the right person. It seems

natural to say that the Client Registry is exposed with a simple

restful interface. Code inside the controller would invoke restful calls.

When the user makes his choice, he has chosen a precise person, and

this person is inserted in the right place inside the perfect message#1.

This scenario suggests that we want to expose the internal Registries

to real-time access by modules within the edge nodes.

I would expose them with the simple restful interface.

[Figure 3] Imperfect Inbound Messages: Work by the Mediator

Suppose that Figure1’s message#1 was not perfect.

In this case, the flow is something like Figure 3.

Edge1 emits an imperfect message #1. It flows in V2 to the backbone.

The mediator then tries to make sense of it, invoking all the

registries that it can (Step #2). If it can make sense, it stores it

into the SHR. But, when there are errors, the mediator

(eventually/asychnronously) emits a V2 exception report message#3 that

flows back to the edge node. The edge node then needs some sort of

“Exception-handling Sub System” that fields the exception report.

Users will have to fiddle with existing data (Step #3.b), to correct

for – react to – the exceptions. Once fixed, a corrected message

(#4) will be sent out, and, finally being perfect, it will be stored

in the SHR (#5).

In our world, the Exception SubSystem (ESS) is a big, big, part of our

workflow and the sucess of our HIE.

        S. Summary
        I had wanted to convince you, fellow OHIE'ers, that we should

think of our problem as the problem of creating perfect V2 messages to

flow from Edge nodes to Central Backbone, and from Backbone to

Edgenodes.

        The process of solving the warts in V2 messages is tantamount

to solving the terminology and naming issues that make large system

hard. The process of making the use of OBR’s and OBX’s understandable

will mean we have solve the problem of data representation.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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


Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

I feel that there is a middle ground between repetition, redundancy and complexity being pushed onto the end-user applications, and a single component that glues the whole system together.

To take Hannes’ example of routing, you don’t require an ESB to do name resolution, although it could serve that function. You could, for instance use DNS to map the names of services to IP addresses, which is an approach that works very well for the internet and LANs. Plain DNS could just as easily allow the introduction of caches or load balancing as an ESB.

So while it seems reasonable that we have concerns that cross-cut individual registries, it doesn’t follow to me that we need a single component responsible for all those concerns. I could easily envisage a system where authorisation is handled by an OAuth server, name resolution by a DNS server, a specific orchestration performed by a dedicated domain service etc.

In other words, the HIM doesn’t need to be a single application running on a single machine (or cluster). It could be a set of centralised services.

The two major challenges that a HIM will need to be resilient against in my opinion are:

  • Becoming a dependency knot that becomes difficult to change as the system evolves
  • Becoming a one-size-fits-all component that makes it difficult for OpenHIE to fulfill an individual country’s needs
    To me, the foundation of OpenHIE is that we want to take the success of projects like RHEA in Rwanda and make it possible for new countries to benefit from earlier hard work. The marginal cost of bringing a new country online will drop, and the cost of developing new features can be amortised across many different installations.

I don’t, however, think that we’ll ever overcome regional variation, and nor should we. There will always be unique requirements or systems to integrate with in every country. The more we build our system from composable subsystems with well-understood interfaces, the more resilient, flexible and therefore valuable OpenHIE will be.

Cheers,

Chris

···

On 30 April 2013 12:28, Hannes Venter hannes@jembi.org wrote:

Hi Derek and Everyone,

I agree with all your above points regarding the idea that nodes should never go around the HIM.

I would just add another important advantage, in line with with abstraction and your second point:

  • A central HIM means there only needs to be a central configuration point for the registries,

i.e. a node doesn’t need to know when we swap out a component for another one,

or if the IP changes, or we distribute the registry instance, or put a caching server in front of it, etc.

These are all standard “operations” issues that aren’t mitigated by using standards.

And the biggest advantage is that we’ll never place the “burden” of interoperability on the nodes themselves

(and of course it gives us flexibility; they don’t need to know that our new CR doesn’t actually support PIX or

that our TS lookups are actually all cached in-memory (just for e.g.)).

Cheers

Hannes

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

On Mon, Apr 29, 2013 at 6:31 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Mark et al.

I believe the premise of having an ESB (a HIM) is an architectural one. But it is a fundamental architectural element that, if you’re going to make it work, will enforce some important patterns. One of these is: everyone talks to the HIM. You don’t do an end-run around the HIM and start independently touching the registries – you always submit your unit of work to the HIM who executes it on your behalf against assets “above the HIM”. Absent that rigour, we really don’t have a way to do two important things:

  1. Centralize shared services (security, authentication, audit, etc.)
  1. Mitigate the rampant proliferation of many-to-many communications channels (the dreaded permutations and combinations problem).

I’m finding the commentary about how HL7v2-ish this needs to be a bit confusing. This pattern, if we embrace it, turns some (maybe all) of the issues about v2 vs. v3 (CDA) vs. DICOM into a “don’t care” proposition… which is another HUGE benefit, in my view.

Warmest regards,

Derek.


Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.


Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Tucker, Mark
Sent: April 29, 2013 11:43 AM
To: openhie-shr
Subject: RE: Strawman V2 Backbone

Hi Ryan,

While I agree with you in principle that the central component does orchestration and is in principle independent of the message format, I just want to reiterate that my intent was to press the point that the central component ought not be considered too abstractly. That if you use V2 messages, then the thrust of the central node is to normalize the incoming messages, and even that may be unnecessary if your edge nodes are already consulting the registries when then construct their messages.

I find the simplicity and concreteness of V2 helps me move forward.

Mark

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Ryan
Sent: Monday, April 29, 2013 6:23 AM
To: Tucker, Mark
Cc: openhie-shr
Subject: Re: Strawman V2 Backbone

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures and orchestration of messages. This is exactly where I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

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

Ch. 3 In What format should data be handled?
S. Preamble.
Basically, I want to argue in favor of the use of Hl7 V2 as the

lingua franca of the OHIE. Within INPC in Indiana, we have 30 years

of experience with it, and 15 years of using it in a multi-institution

exchange. V2, as opposed to V3, is easy to pick up. It is easy for

new developers to work with, and does not require sophisticated

tooling.

When I first saw HL7, I thought: "You call this mess a standard?

(Everyting is optional)" Over the years, I found that I would not be

disappointed if I thought of HL7 not as a standard, but as "a starting

point for negotiations." You are so much better off with V2 than

nothing.

In recent years, things have gotten much better. Now, with

standard provider ID’s, LOINC, …, it has gotten much easier to

actually be able to process data from new institutions without alot of

negotiating. Now, in OpenHIE, with the prospect of national

registries for patients, providers and locations, and a Ministry of

Health mandating the use of code systems, and mandating the collection

of specific data elements, I stand aghast, and wonder if there is

anything left for me to do. It’s all been solved.

So, as we ponder the OpenHIE architecture, I constantly run a straw

man scenario in parallel with the discussion. It works like this:

If I had the V2 Backbone as sketched below, how would I solve problem X?

S. Strawman Backbone
Figure one shows the overall architecture.

The “V2 Backbone” is the combination of the registries

CR: Client Registry
PR: Provider Registry
FR: Facility  Registry
TS: Terminology Server
SHR: Shared Health Record
WH: Warehouse
---: and the spine is the HIM backbone.

The out rounded rectangle is the boundary of the backbone.

Three Edge nodes are pictured.

Arc #1 shows a V2 message travelling

to the backbone. It represents the captured information from an

encounter. It is new information flowing into the SHR.

Arc #3 shows submissions actually flowing into the SHR, where they are stored.

Arc #2 shows a patient download being sent to a new edge node. A

patient has just arrived, and a full download of data is being sent to Edge2.

It is a pile of “perfectly formatted V2 messages”, having been

normalized by the central node.

Users interact with Edge2 to provide care, and, presumably, new

submissions like message#1 flow from that encounter.

The messages of arc#2 are exactly the outbound messages “regurgitated”

by the SHR based on already known data.

Finally, Edge3 shows a system that acts as a concentrator/server for

hand held devices. The point is that Edge3 needs to know V2. The

protocol for the interactions (arc#4) with the handsets does not have

to be V2. Edge3 holds the smarts.

When I see this picture, I want to say:

        [1] Suppose Message arc#1 is "perfect" V2.  That is, it has
        the patient, provider, facility, and codes already correct,
        and the clinical segments are properly shaped. (That is, the
        proper OBX's are used to represent laboratory panels,
        documents, annotated documents, and micro results.  The
        software that generates message#1 has been validated at build
        time to use the HL7 implementation guides defined by the
        backbone.)
        With this perfect message, the HIM mediator needs do nothing:
        Just send it to SHR.
        [2] Likewise, the downloads arc#2 are easily handled, since
        they are perfect messages by construction.  There
        are no surprises to Edge2.  Once it has been built to handle
        the three shapes of data, it easily consumes a long string of
        patient backload messages.
        [3] Much of the hard work of the OHIE effort is encapulsated in
        establishing the CR,PR, and FR registries.

[Figure 2]

But, how did message#1 become “Perfect?”

The hard part is getting the patient and provider correct.

The software is designed to build properly shaped messages, and the

master files for observations are pre-loaded with the proper LOINC codes.

Figure 2 shows the “Choose Pt” dialog box.

Behind it is a controller. It may need to consult the Client Registry

“at runtime” to help the user choose the right person. It seems

natural to say that the Client Registry is exposed with a simple

restful interface. Code inside the controller would invoke restful calls.

When the user makes his choice, he has chosen a precise person, and

this person is inserted in the right place inside the perfect message#1.

This scenario suggests that we want to expose the internal Registries

to real-time access by modules within the edge nodes.

I would expose them with the simple restful interface.

[Figure 3] Imperfect Inbound Messages: Work by the Mediator

Suppose that Figure1’s message#1 was not perfect.

In this case, the flow is something like Figure 3.

Edge1 emits an imperfect message #1. It flows in V2 to the backbone.

The mediator then tries to make sense of it, invoking all the

registries that it can (Step #2). If it can make sense, it stores it

into the SHR. But, when there are errors, the mediator

(eventually/asychnronously) emits a V2 exception report message#3 that

flows back to the edge node. The edge node then needs some sort of

“Exception-handling Sub System” that fields the exception report.

Users will have to fiddle with existing data (Step #3.b), to correct

for – react to – the exceptions. Once fixed, a corrected message

(#4) will be sent out, and, finally being perfect, it will be stored

in the SHR (#5).

In our world, the Exception SubSystem (ESS) is a big, big, part of our

workflow and the sucess of our HIE.

        S. Summary
        I had wanted to convince you, fellow OHIE'ers, that we should

think of our problem as the problem of creating perfect V2 messages to

flow from Edge nodes to Central Backbone, and from Backbone to

Edgenodes.

        The process of solving the warts in V2 messages is tantamount

to solving the terminology and naming issues that make large system

hard. The process of making the use of OBR’s and OBX’s understandable

will mean we have solve the problem of data representation.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

Software Developer, Jembi Health Systems | SOUTH AFRICA


Hannes VenterMobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

Amen Chris. Well said.

···

On Thu, May 2, 2013 at 10:35 AM, Chris Ford christophertford@gmail.com wrote:

I feel that there is a middle ground between repetition, redundancy and complexity being pushed onto the end-user applications, and a single component that glues the whole system together.

To take Hannes’ example of routing, you don’t require an ESB to do name resolution, although it could serve that function. You could, for instance use DNS to map the names of services to IP addresses, which is an approach that works very well for the internet and LANs. Plain DNS could just as easily allow the introduction of caches or load balancing as an ESB.

So while it seems reasonable that we have concerns that cross-cut individual registries, it doesn’t follow to me that we need a single component responsible for all those concerns. I could easily envisage a system where authorisation is handled by an OAuth server, name resolution by a DNS server, a specific orchestration performed by a dedicated domain service etc.

In other words, the HIM doesn’t need to be a single application running on a single machine (or cluster). It could be a set of centralised services.

The two major challenges that a HIM will need to be resilient against in my opinion are:

  • Becoming a dependency knot that becomes difficult to change as the system evolves
  • Becoming a one-size-fits-all component that makes it difficult for OpenHIE to fulfill an individual country’s needs
    To me, the foundation of OpenHIE is that we want to take the success of projects like RHEA in Rwanda and make it possible for new countries to benefit from earlier hard work. The marginal cost of bringing a new country online will drop, and the cost of developing new features can be amortised across many different installations.

I don’t, however, think that we’ll ever overcome regional variation, and nor should we. There will always be unique requirements or systems to integrate with in every country. The more we build our system from composable subsystems with well-understood interfaces, the more resilient, flexible and therefore valuable OpenHIE will be.

Cheers,

Chris

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine

Director, Indiana Center of Excellence in Public Health Informatics
410 West 10th Street, Suite 2000

Indianapolis, IN 46202
(317) 423-5523 (O)
(317) 423-5695 (F)

On 30 April 2013 12:28, Hannes Venter hannes@jembi.org wrote:

Hi Derek and Everyone,

I agree with all your above points regarding the idea that nodes should never go around the HIM.

I would just add another important advantage, in line with with abstraction and your second point:

  • A central HIM means there only needs to be a central configuration point for the registries,

i.e. a node doesn’t need to know when we swap out a component for another one,

or if the IP changes, or we distribute the registry instance, or put a caching server in front of it, etc.

These are all standard “operations” issues that aren’t mitigated by using standards.

And the biggest advantage is that we’ll never place the “burden” of interoperability on the nodes themselves

(and of course it gives us flexibility; they don’t need to know that our new CR doesn’t actually support PIX or

that our TS lookups are actually all cached in-memory (just for e.g.)).

Cheers

Hannes

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

On Mon, Apr 29, 2013 at 6:31 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Mark et al.

I believe the premise of having an ESB (a HIM) is an architectural one. But it is a fundamental architectural element that, if you’re going to make it work, will enforce some important patterns. One of these is: everyone talks to the HIM. You don’t do an end-run around the HIM and start independently touching the registries – you always submit your unit of work to the HIM who executes it on your behalf against assets “above the HIM”. Absent that rigour, we really don’t have a way to do two important things:

  1. Centralize shared services (security, authentication, audit, etc.)
  1. Mitigate the rampant proliferation of many-to-many communications channels (the dreaded permutations and combinations problem).

I’m finding the commentary about how HL7v2-ish this needs to be a bit confusing. This pattern, if we embrace it, turns some (maybe all) of the issues about v2 vs. v3 (CDA) vs. DICOM into a “don’t care” proposition… which is another HUGE benefit, in my view.

Warmest regards,

Derek.


Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.


Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Tucker, Mark
Sent: April 29, 2013 11:43 AM
To: openhie-shr
Subject: RE: Strawman V2 Backbone

Hi Ryan,

While I agree with you in principle that the central component does orchestration and is in principle independent of the message format, I just want to reiterate that my intent was to press the point that the central component ought not be considered too abstractly. That if you use V2 messages, then the thrust of the central node is to normalize the incoming messages, and even that may be unnecessary if your edge nodes are already consulting the registries when then construct their messages.

I find the simplicity and concreteness of V2 helps me move forward.

Mark

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Ryan
Sent: Monday, April 29, 2013 6:23 AM
To: Tucker, Mark
Cc: openhie-shr
Subject: Re: Strawman V2 Backbone

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures and orchestration of messages. This is exactly where I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

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

Ch. 3 In What format should data be handled?
S. Preamble.
Basically, I want to argue in favor of the use of Hl7 V2 as the

lingua franca of the OHIE. Within INPC in Indiana, we have 30 years

of experience with it, and 15 years of using it in a multi-institution

exchange. V2, as opposed to V3, is easy to pick up. It is easy for

new developers to work with, and does not require sophisticated

tooling.

When I first saw HL7, I thought: "You call this mess a standard?

(Everyting is optional)" Over the years, I found that I would not be

disappointed if I thought of HL7 not as a standard, but as "a starting

point for negotiations." You are so much better off with V2 than

nothing.

In recent years, things have gotten much better. Now, with

standard provider ID’s, LOINC, …, it has gotten much easier to

actually be able to process data from new institutions without alot of

negotiating. Now, in OpenHIE, with the prospect of national

registries for patients, providers and locations, and a Ministry of

Health mandating the use of code systems, and mandating the collection

of specific data elements, I stand aghast, and wonder if there is

anything left for me to do. It’s all been solved.

So, as we ponder the OpenHIE architecture, I constantly run a straw

man scenario in parallel with the discussion. It works like this:

If I had the V2 Backbone as sketched below, how would I solve problem X?

S. Strawman Backbone
Figure one shows the overall architecture.

The “V2 Backbone” is the combination of the registries

CR: Client Registry
PR: Provider Registry
FR: Facility  Registry
TS: Terminology Server
SHR: Shared Health Record
WH: Warehouse
---: and the spine is the HIM backbone.

The out rounded rectangle is the boundary of the backbone.

Three Edge nodes are pictured.

Arc #1 shows a V2 message travelling

to the backbone. It represents the captured information from an

encounter. It is new information flowing into the SHR.

Arc #3 shows submissions actually flowing into the SHR, where they are stored.

Arc #2 shows a patient download being sent to a new edge node. A

patient has just arrived, and a full download of data is being sent to Edge2.

It is a pile of “perfectly formatted V2 messages”, having been

normalized by the central node.

Users interact with Edge2 to provide care, and, presumably, new

submissions like message#1 flow from that encounter.

The messages of arc#2 are exactly the outbound messages “regurgitated”

by the SHR based on already known data.

Finally, Edge3 shows a system that acts as a concentrator/server for

hand held devices. The point is that Edge3 needs to know V2. The

protocol for the interactions (arc#4) with the handsets does not have

to be V2. Edge3 holds the smarts.

When I see this picture, I want to say:

        [1] Suppose Message arc#1 is "perfect" V2.  That is, it has
        the patient, provider, facility, and codes already correct,
        and the clinical segments are properly shaped. (That is, the
        proper OBX's are used to represent laboratory panels,
        documents, annotated documents, and micro results.  The
        software that generates message#1 has been validated at build
        time to use the HL7 implementation guides defined by the
        backbone.)
        With this perfect message, the HIM mediator needs do nothing:
        Just send it to SHR.
        [2] Likewise, the downloads arc#2 are easily handled, since
        they are perfect messages by construction.  There
        are no surprises to Edge2.  Once it has been built to handle
        the three shapes of data, it easily consumes a long string of
        patient backload messages.
        [3] Much of the hard work of the OHIE effort is encapulsated in
        establishing the CR,PR, and FR registries.

[Figure 2]

But, how did message#1 become “Perfect?”

The hard part is getting the patient and provider correct.

The software is designed to build properly shaped messages, and the

master files for observations are pre-loaded with the proper LOINC codes.

Figure 2 shows the “Choose Pt” dialog box.

Behind it is a controller. It may need to consult the Client Registry

“at runtime” to help the user choose the right person. It seems

natural to say that the Client Registry is exposed with a simple

restful interface. Code inside the controller would invoke restful calls.

When the user makes his choice, he has chosen a precise person, and

this person is inserted in the right place inside the perfect message#1.

This scenario suggests that we want to expose the internal Registries

to real-time access by modules within the edge nodes.

I would expose them with the simple restful interface.

[Figure 3] Imperfect Inbound Messages: Work by the Mediator

Suppose that Figure1’s message#1 was not perfect.

In this case, the flow is something like Figure 3.

Edge1 emits an imperfect message #1. It flows in V2 to the backbone.

The mediator then tries to make sense of it, invoking all the

registries that it can (Step #2). If it can make sense, it stores it

into the SHR. But, when there are errors, the mediator

(eventually/asychnronously) emits a V2 exception report message#3 that

flows back to the edge node. The edge node then needs some sort of

“Exception-handling Sub System” that fields the exception report.

Users will have to fiddle with existing data (Step #3.b), to correct

for – react to – the exceptions. Once fixed, a corrected message

(#4) will be sent out, and, finally being perfect, it will be stored

in the SHR (#5).

In our world, the Exception SubSystem (ESS) is a big, big, part of our

workflow and the sucess of our HIE.

        S. Summary
        I had wanted to convince you, fellow OHIE'ers, that we should

think of our problem as the problem of creating perfect V2 messages to

flow from Edge nodes to Central Backbone, and from Backbone to

Edgenodes.

        The process of solving the warts in V2 messages is tantamount

to solving the terminology and naming issues that make large system

hard. The process of making the use of OBR’s and OBX’s understandable

will mean we have solve the problem of data representation.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

Software Developer, Jembi Health Systems | SOUTH AFRICA


Hannes VenterMobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

Second Amen.

On Behalf Of Shaun Grannis

···

Amen Chris. Well said.

On Thu, May 2, 2013 at 10:35 AM, Chris Ford christophertford@gmail.com wrote:

I feel that there is a middle ground between repetition, redundancy and complexity being pushed onto the end-user applications, and a single component that glues the whole system together.

To take Hannes’ example of routing, you don’t require an ESB to do name resolution, although it could serve that function. You could, for instance use DNS to map the names of services to IP addresses, which is an approach that works very
well for the internet and LANs. Plain DNS could just as easily allow the introduction of caches or load balancing as an ESB.

So while it seems reasonable that we have concerns that cross-cut individual registries, it doesn’t follow to me that we need a single component responsible for all those concerns. I could easily envisage a system where authorisation is
handled by an OAuth server, name resolution by a DNS server, a specific orchestration performed by a dedicated domain service etc.

In other words, the HIM doesn’t need to be a single application running on a single machine (or cluster). It could be a set of centralised services.

The two major challenges that a HIM will need to be resilient against in my opinion are:

  • Becoming a dependency knot that becomes difficult to change as the system evolves

  • Becoming a one-size-fits-all component that makes it difficult for OpenHIE to fulfill an individual country’s needs

To me, the foundation of OpenHIE is that we want to take the success of projects like RHEA in Rwanda and make it possible for new countries to benefit from earlier hard work. The marginal cost of bringing a new country online will drop,
and the cost of developing new features can be amortised across many different installations.

I don’t, however, think that we’ll ever overcome regional variation, and nor should we. There will always be unique requirements or systems to integrate with in every country. The more we build our system from composable subsystems with
well-understood interfaces, the more resilient, flexible and therefore valuable OpenHIE will be.

Cheers,

Chris

On 30 April 2013 12:28, Hannes Venter hannes@jembi.org wrote:

Hi Derek and Everyone,

I agree with all your above points regarding the idea that nodes should never go around the HIM.

I would just add another important advantage, in line with with abstraction and your second point:

  • A central HIM means there only needs to be a central configuration point for the registries,

i.e. a node doesn’t need to know when we swap out a component for another one,

or if the IP changes, or we distribute the registry instance, or put a caching server in front of it, etc.

These are all standard “operations” issues that aren’t mitigated by using standards.

And the biggest advantage is that we’ll never place the “burden” of interoperability on the nodes themselves

(and of course it gives us flexibility; they don’t need to know that our new CR doesn’t actually support PIX or

that our TS lookups are actually all cached in-memory (just for e.g.)).

Cheers

Hannes

On Mon, Apr 29, 2013 at 6:31 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Mark et al.

I believe the premise of having an ESB (a HIM) is an architectural one. But it is a fundamental
architectural element that, if you’re going to make it work, will enforce some important patterns. One of these is: everyone talks to the HIM. You don’t do an end-run around the HIM and start independently touching the registries – you always submit your unit
of work to the HIM who executes it on your behalf against assets “above the HIM”. Absent that rigour, we really don’t have a way to do two important things:

Centralize shared services (security, authentication, audit, etc.)

Mitigate the rampant proliferation of many-to-many communications channels (the dreaded permutations and combinations problem).

I’m finding the commentary about how HL7v2-ish this needs to be a bit confusing. This pattern, if
we embrace it, turns some (maybe all) of the issues about v2 vs. v3 (CDA) vs. DICOM into a “don’t care” proposition… which is another HUGE benefit, in my view.

Warmest regards,

Derek.


**Derek Ritz,**P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain
information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender
immediately by return electronic mail and destroy the message and any attachments.


Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne
renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient,
par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From:
openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Tucker, Mark
Sent: April 29, 2013 11:43 AM
To: openhie-shr
Subject: RE: Strawman V2 Backbone

Hi Ryan,

While I agree with you in principle that the central component does orchestration and is in principle
independent of the message format, I just want to reiterate that my intent was to press the point that the central component *ought not * be considered too abstractly. That if you use V2 messages, then the thrust of the central node is to normalize
the incoming messages, and even that may be unnecessary if your edge nodes are already consulting the registries when then construct their messages.

I find the simplicity and concreteness of V2 helps me move forward.

Mark

From:
openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Ryan
Sent: Monday, April 29, 2013 6:23 AM
To: Tucker, Mark
Cc: openhie-shr
Subject: Re: Strawman V2 Backbone

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes
is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures
and orchestration of messages. This is exactly where I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.

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

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

Ch. 3 In What format should data be handled?



S. Preamble.



Basically, I want to argue in favor of the use of Hl7 V2 as the

lingua franca of the OHIE. Within INPC in Indiana, we have 30 years

of experience with it, and 15 years of using it in a multi-institution

exchange. V2, as opposed to V3, is easy to pick up. It is easy for

new developers to work with, and does not require sophisticated

tooling.

When I first saw HL7, I thought: "You call this mess a standard?

(Everyting is optional)" Over the years, I found that I would not be

disappointed if I thought of HL7 not as a standard, but as "a starting

point for negotiations." You are so much better off with V2 than

nothing.

In recent years, things have gotten much better. Now, with

standard provider ID’s, LOINC, …, it has gotten much easier to

actually be able to process data from new institutions without alot of

negotiating. Now, in OpenHIE, with the prospect of national

registries for patients, providers and locations, and a Ministry of

Health mandating the use of code systems, and mandating the collection

of specific data elements, I stand aghast, and wonder if there is

anything left for me to do. It’s all been solved.

So, as we ponder the OpenHIE architecture, I constantly run a straw

man scenario in parallel with the discussion. It works like this:

If I had the V2 Backbone as sketched below, how would I solve problem X?

S. Strawman Backbone



Figure one shows the overall architecture.

The “V2 Backbone” is the combination of the registries

CR: Client Registry

PR: Provider Registry

FR: Facility  Registry

TS: Terminology Server

SHR: Shared Health Record

WH: Warehouse

---: and the spine is the HIM backbone.

The out rounded rectangle is the boundary of the backbone.

Three Edge nodes are pictured.

Arc #1 shows a V2 message travelling

to the backbone. It represents the captured information from an

encounter. It is new information flowing into the SHR.

Arc #3 shows submissions actually flowing into the SHR, where they are stored.

Arc #2 shows a patient download being sent to a new edge node. A

patient has just arrived, and a full download of data is being sent to Edge2.

It is a pile of “perfectly formatted V2 messages”, having been

normalized by the central node.

Users interact with Edge2 to provide care, and, presumably, new

submissions like message#1 flow from that encounter.

The messages of arc#2 are exactly the outbound messages “regurgitated”

by the SHR based on already known data.

Finally, Edge3 shows a system that acts as a concentrator/server for

hand held devices. The point is that Edge3 needs to know V2. The

protocol for the interactions (arc#4) with the handsets does not have

to be V2. Edge3 holds the smarts.

When I see this picture, I want to say:

        [1] Suppose Message arc#1 is "perfect" V2.  That is, it has

        the patient, provider, facility, and codes already correct,

        and the clinical segments are properly shaped. (That is, the

        proper OBX's are used to represent laboratory panels,

        documents, annotated documents, and micro results.  The

        software that generates message#1 has been validated at build

        time to use the HL7 implementation guides defined by the

        backbone.)



        With this perfect message, the HIM mediator needs do nothing:

        Just send it to SHR.



       

        [2] Likewise, the downloads arc#2 are easily handled, since

        they are perfect messages by construction.  There

        are no surprises to Edge2.  Once it has been built to handle

        the three shapes of data, it easily consumes a long string of

        patient backload messages.



        [3] Much of the hard work of the OHIE effort is encapulsated in

        establishing the CR,PR, and FR registries.

[Figure 2]

But, how did message#1 become “Perfect?”

The hard part is getting the patient and provider correct.

The software is designed to build properly shaped messages, and the

master files for observations are pre-loaded with the proper LOINC codes.

Figure 2 shows the “Choose Pt” dialog box.

Behind it is a controller. It may need to consult the Client Registry

“at runtime” to help the user choose the right person. It seems

natural to say that the Client Registry is exposed with a simple

restful interface. Code inside the controller would invoke restful calls.

When the user makes his choice, he has chosen a precise person, and

this person is inserted in the right place inside the perfect message#1.

This scenario suggests that we want to expose the internal Registries

to real-time access by modules within the edge nodes.

I would expose them with the simple restful interface.

[Figure 3] Imperfect Inbound Messages: Work by the Mediator

Suppose that Figure1’s message#1 was not perfect.

In this case, the flow is something like Figure 3.

Edge1 emits an imperfect message #1. It flows in V2 to the backbone.

The mediator then tries to make sense of it, invoking all the

registries that it can (Step #2). If it can make sense, it stores it

into the SHR. But, when there are errors, the mediator

(eventually/asychnronously) emits a V2 exception report message#3 that

flows back to the edge node. The edge node then needs some sort of

“Exception-handling Sub System” that fields the exception report.

Users will have to fiddle with existing data (Step #3.b), to correct

for – react to – the exceptions. Once fixed, a corrected message

(#4) will be sent out, and, finally being perfect, it will be stored

in the SHR (#5).

In our world, the Exception SubSystem (ESS) is a big, big, part of our

workflow and the sucess of our HIE.

        S. Summary



        I had wanted to convince you, fellow OHIE'ers, that we should

think of our problem as the problem of creating perfect V2 messages to

flow from Edge nodes to Central Backbone, and from Backbone to

Edgenodes.

        The process of solving the warts in V2 messages is tantamount

to solving the terminology and naming issues that make large system

hard. The process of making the use of OBR’s and OBX’s understandable

will mean we have solve the problem of data representation.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out
.

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out
.


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out
.


Hannes Venter

Software Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:
+27 73 276 2848 | Office:
+27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out
.

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
Director, Indiana Center of Excellence in Public Health Informatics

410 West 10th Street, Suite 2000

Indianapolis, IN 46202
(317) 423-5523 (O)
(317) 423-5695 (F)


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

(coping this onto the HIM list to)

Thanks Chris, very thoughtful comments. I think you have have raised some important issues. I think there is benefit to not repeating some of the common functionality between difference services. Things like security, logging and auditing of messages and orchestration of common workflows. However, you are correct, this should not hamper the growth, evolution and flexibility of the HIE.

I like the notion of considering the HIM as a set of centralised services that provide common functionality. I think there are three things that we should add to the requirements for a HIM to ensure that we address these concerns:

  1. The HIM should provide a modular set of orchestration functionality such that it can easily extended to support a variety of country needs.
  2. The HIM should be able to be configured to transparently proxy services so that the HIM may be placed in front of existing service to provide useful functionality if desired
  3. The HIM should be able to provide service orchestration services to simplify workflow if desired
    Logically this could be could be considered as a single component but the physical implementation could be that the HIM is actually a set of separate services that work together.

Chris, does this kind of capture what you have in mind or is it something different?

Cheers,

Ryan

···

On Thu, May 2, 2013 at 4:43 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Second Amen.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Shaun Grannis
Sent: Thursday, May 02, 2013 10:42 AM
To: Chris Ford
Cc: Hannes Venter; Derek Ritz (ecGroup); openhie-shr

Subject: Re: Strawman V2 Backbone

Amen Chris. Well said.

On Thu, May 2, 2013 at 10:35 AM, Chris Ford christophertford@gmail.com wrote:

I feel that there is a middle ground between repetition, redundancy and complexity being pushed onto the end-user applications, and a single component that glues the whole system together.

To take Hannes’ example of routing, you don’t require an ESB to do name resolution, although it could serve that function. You could, for instance use DNS to map the names of services to IP addresses, which is an approach that works very
well for the internet and LANs. Plain DNS could just as easily allow the introduction of caches or load balancing as an ESB.

So while it seems reasonable that we have concerns that cross-cut individual registries, it doesn’t follow to me that we need a single component responsible for all those concerns. I could easily envisage a system where authorisation is
handled by an OAuth server, name resolution by a DNS server, a specific orchestration performed by a dedicated domain service etc.

In other words, the HIM doesn’t need to be a single application running on a single machine (or cluster). It could be a set of centralised services.

The two major challenges that a HIM will need to be resilient against in my opinion are:

  • Becoming a dependency knot that becomes difficult to change as the system evolves
  • Becoming a one-size-fits-all component that makes it difficult for OpenHIE to fulfill an individual country’s needs
    To me, the foundation of OpenHIE is that we want to take the success of projects like RHEA in Rwanda and make it possible for new countries to benefit from earlier hard work. The marginal cost of bringing a new country online will drop,
    and the cost of developing new features can be amortised across many different installations.

I don’t, however, think that we’ll ever overcome regional variation, and nor should we. There will always be unique requirements or systems to integrate with in every country. The more we build our system from composable subsystems with
well-understood interfaces, the more resilient, flexible and therefore valuable OpenHIE will be.

Cheers,

Chris

On 30 April 2013 12:28, Hannes Venter hannes@jembi.org wrote:

Hi Derek and Everyone,

I agree with all your above points regarding the idea that nodes should never go around the HIM.

I would just add another important advantage, in line with with abstraction and your second point:

  • A central HIM means there only needs to be a central configuration point for the registries,

i.e. a node doesn’t need to know when we swap out a component for another one,

or if the IP changes, or we distribute the registry instance, or put a caching server in front of it, etc.

These are all standard “operations” issues that aren’t mitigated by using standards.

And the biggest advantage is that we’ll never place the “burden” of interoperability on the nodes themselves

(and of course it gives us flexibility; they don’t need to know that our new CR doesn’t actually support PIX or

that our TS lookups are actually all cached in-memory (just for e.g.)).

Cheers

Hannes

On Mon, Apr 29, 2013 at 6:31 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Mark et al.

I believe the premise of having an ESB (a HIM) is an architectural one. But it is a fundamental
architectural element that, if you’re going to make it work, will enforce some important patterns. One of these is: everyone talks to the HIM. You don’t do an end-run around the HIM and start independently touching the registries – you always submit your unit
of work to the HIM who executes it on your behalf against assets “above the HIM”. Absent that rigour, we really don’t have a way to do two important things:

Centralize shared services (security, authentication, audit, etc.)

Mitigate the rampant proliferation of many-to-many communications channels (the dreaded permutations and combinations problem).

I’m finding the commentary about how HL7v2-ish this needs to be a bit confusing. This pattern, if
we embrace it, turns some (maybe all) of the issues about v2 vs. v3 (CDA) vs. DICOM into a “don’t care” proposition… which is another HUGE benefit, in my view.

Warmest regards,

Derek.


**Derek Ritz,**P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain
information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender
immediately by return electronic mail and destroy the message and any attachments.


Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne
renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient,
par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From:
openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Tucker, Mark
Sent: April 29, 2013 11:43 AM
To: openhie-shr
Subject: RE: Strawman V2 Backbone

Hi Ryan,

While I agree with you in principle that the central component does orchestration and is in principle
independent of the message format, I just want to reiterate that my intent was to press the point that the central component *ought not * be considered too abstractly. That if you use V2 messages, then the thrust of the central node is to normalize
the incoming messages, and even that may be unnecessary if your edge nodes are already consulting the registries when then construct their messages.

I find the simplicity and concreteness of V2 helps me move forward.

Mark

From:
openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Ryan
Sent: Monday, April 29, 2013 6:23 AM
To: Tucker, Mark
Cc: openhie-shr
Subject: Re: Strawman V2 Backbone

Thanks for this Mark. It was useful. HL7 v2 could definitely provide a good base for us to work off and currently in RHEA much of the messaging is done using v2. What you describes
is quite similar to what we have done in the Rwandan implementation.

There are some points that you captured that I wanted to point out more generally. You touched on the central component being responsible for both normalization of message structures
and orchestration of messages. This is exactly where I lie on this matter as well. I think these are common functions of a central component independent of the actual messaging format used.

Ryan

On Fri, Apr 19, 2013 at 10:13 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Suppose we use V2 for communication from edge nodes to the central node.

What problem’s remain once we get patients, doctors, facilities, terms and a consistent style of OBR/OBX in place ?

Are we done yet ?

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 “Shared Health Record (OpenHIE)” group.

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

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

Ch. 3 In What format should data be handled?
S. Preamble.
Basically, I want to argue in favor of the use of Hl7 V2 as the

lingua franca of the OHIE. Within INPC in Indiana, we have 30 years

of experience with it, and 15 years of using it in a multi-institution

exchange. V2, as opposed to V3, is easy to pick up. It is easy for

new developers to work with, and does not require sophisticated

tooling.

When I first saw HL7, I thought: "You call this mess a standard?

(Everyting is optional)" Over the years, I found that I would not be

disappointed if I thought of HL7 not as a standard, but as "a starting

point for negotiations." You are so much better off with V2 than

nothing.

In recent years, things have gotten much better. Now, with

standard provider ID’s, LOINC, …, it has gotten much easier to

actually be able to process data from new institutions without alot of

negotiating. Now, in OpenHIE, with the prospect of national

registries for patients, providers and locations, and a Ministry of

Health mandating the use of code systems, and mandating the collection

of specific data elements, I stand aghast, and wonder if there is

anything left for me to do. It’s all been solved.

So, as we ponder the OpenHIE architecture, I constantly run a straw

man scenario in parallel with the discussion. It works like this:

If I had the V2 Backbone as sketched below, how would I solve problem X?

S. Strawman Backbone
Figure one shows the overall architecture.

The “V2 Backbone” is the combination of the registries

CR: Client Registry
PR: Provider Registry
FR: Facility  Registry
TS: Terminology Server
SHR: Shared Health Record
WH: Warehouse
---: and the spine is the HIM backbone.

The out rounded rectangle is the boundary of the backbone.

Three Edge nodes are pictured.

Arc #1 shows a V2 message travelling

to the backbone. It represents the captured information from an

encounter. It is new information flowing into the SHR.

Arc #3 shows submissions actually flowing into the SHR, where they are stored.

Arc #2 shows a patient download being sent to a new edge node. A

patient has just arrived, and a full download of data is being sent to Edge2.

It is a pile of “perfectly formatted V2 messages”, having been

normalized by the central node.

Users interact with Edge2 to provide care, and, presumably, new

submissions like message#1 flow from that encounter.

The messages of arc#2 are exactly the outbound messages “regurgitated”

by the SHR based on already known data.

Finally, Edge3 shows a system that acts as a concentrator/server for

hand held devices. The point is that Edge3 needs to know V2. The

protocol for the interactions (arc#4) with the handsets does not have

to be V2. Edge3 holds the smarts.

When I see this picture, I want to say:

        [1] Suppose Message arc#1 is "perfect" V2.  That is, it has
        the patient, provider, facility, and codes already correct,
        and the clinical segments are properly shaped. (That is, the
        proper OBX's are used to represent laboratory panels,
        documents, annotated documents, and micro results.  The
        software that generates message#1 has been validated at build
        time to use the HL7 implementation guides defined by the
        backbone.)
        With this perfect message, the HIM mediator needs do nothing:
        Just send it to SHR.
        [2] Likewise, the downloads arc#2 are easily handled, since
        they are perfect messages by construction.  There
        are no surprises to Edge2.  Once it has been built to handle
        the three shapes of data, it easily consumes a long string of
        patient backload messages.
        [3] Much of the hard work of the OHIE effort is encapulsated in
        establishing the CR,PR, and FR registries.

[Figure 2]

But, how did message#1 become “Perfect?”

The hard part is getting the patient and provider correct.

The software is designed to build properly shaped messages, and the

master files for observations are pre-loaded with the proper LOINC codes.

Figure 2 shows the “Choose Pt” dialog box.

Behind it is a controller. It may need to consult the Client Registry

“at runtime” to help the user choose the right person. It seems

natural to say that the Client Registry is exposed with a simple

restful interface. Code inside the controller would invoke restful calls.

When the user makes his choice, he has chosen a precise person, and

this person is inserted in the right place inside the perfect message#1.

This scenario suggests that we want to expose the internal Registries

to real-time access by modules within the edge nodes.

I would expose them with the simple restful interface.

[Figure 3] Imperfect Inbound Messages: Work by the Mediator

Suppose that Figure1’s message#1 was not perfect.

In this case, the flow is something like Figure 3.

Edge1 emits an imperfect message #1. It flows in V2 to the backbone.

The mediator then tries to make sense of it, invoking all the

registries that it can (Step #2). If it can make sense, it stores it

into the SHR. But, when there are errors, the mediator

(eventually/asychnronously) emits a V2 exception report message#3 that

flows back to the edge node. The edge node then needs some sort of

“Exception-handling Sub System” that fields the exception report.

Users will have to fiddle with existing data (Step #3.b), to correct

for – react to – the exceptions. Once fixed, a corrected message

(#4) will be sent out, and, finally being perfect, it will be stored

in the SHR (#5).

In our world, the Exception SubSystem (ESS) is a big, big, part of our

workflow and the sucess of our HIE.

        S. Summary
        I had wanted to convince you, fellow OHIE'ers, that we should

think of our problem as the problem of creating perfect V2 messages to

flow from Edge nodes to Central Backbone, and from Backbone to

Edgenodes.

        The process of solving the warts in V2 messages is tantamount

to solving the terminology and naming issues that make large system

hard. The process of making the use of OBR’s and OBX’s understandable

will mean we have solve the problem of data representation.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

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

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out
.

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out
.


Hannes Venter

Software Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:
+27 73 276 2848 | Office:
+27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
Director, Indiana Center of Excellence in Public Health Informatics

410 West 10th Street, Suite 2000

Indianapolis, IN 46202
(317) 423-5523 (O)
(317) 423-5695 (F)


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+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