How closely tied should the HIM and SHR be? *Sometimes* transforms messages

I realize that many people, Odysseas and Hannes in particular, see the HIM as providing significant orchestration.

I’m coming to think of as sometimes providing orchestration

The point of my naming it “a V2 Backbone” was to emphasize the role of V2.

It seems true to me that if the edge nodes create “perfect HL7” for insertion into the SHR, then there is nothing (little) for the HIM to do, and it seems natural
that that SHR accept the V2 and process it. . I think it is important for the SHR and the edge nodes to use the same representation (V2)

What I like about that story is that it focuses attention on the V2 HL7. Once it is perfect, we win. And, when there are problems, I want to see how the
problem (and its solution) is manifest in the V2 messages.

So, I think of the HIM as providing “orchestration” only to the extent that messages need it.

If the original message had good providers, facilities, patients and codes, and it used OBX’s properly, then there would be nothing to do in the HIM.

In the case of imperfect messages from, say disconnected edge nodes that could not consult the restfully-exposed Registries, or from pre-existing HL7 systems
that do their own thing, then the HIM will have plenty to do.

On Behalf Of Hannes Venter

···

Hi Odysseas, thank you for the great comments. Just cc’ing the list…

On Mon, Apr 22, 2013 at 1:07 PM, Odysseas Pentakalos, Ph.D. odysseas@sysnetint.com wrote:

Hi Hannes,

My view is that the HIM provides the “glue” that ties together all the other components of the OpenHIE.

  • It provides the data transformation services that may be needed to adapt the messages in and out of the overall exchange to the interfaces supported by
    any of the exchanges
  • It provides orchestration needed in the processing of individual messages by one or more registries
  • It can provide the distribution that may be needed to support multiple instances of the SHR (or the CR)
  • It provides centralized handling of security (and probably adapts to the security scheme of the individual CRs)
  • It can provide transaction monitoring and performance monitoring services since it sees every message go by

In summary, I see the HIM forming the perimeter around the other registries which would make the discussion
about how to best store the clinical data in the SHR the focus of only the SHR and which messaging format
to use to exchange data the focus of the HIM.

Best regards,
Odysseas

On 04/22/2013 06:22 AM, Hannes Venter wrote:

Hi Everyone,

I just wanted to kickoff the following question from Mark Tucker’s email threads on this list:

How closely should the HIM and SHR be tied together? Where should the boundary be around them?

My feeling is very closely, given the need for splitting data up to stores such discrete or document,

tasks which might be better in the HIM rather than a little “logic processor” as part of the SHR (or not?).

I look forward to all responses :slight_smile:

Regards

Hannes


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
.

--

Odysseas Pentakalos, Ph.D., PMP

Chief Technology Officer

SYSNET International, Inc.

2930 Oak Shadow Drive

Oak Hill, Virginia 20171

mailto:odysseas@sysnetint.com

(703) 855-2029


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.

Hmmm… it is my experience that the HIM’s orchestration is actually very important to sustained and managed interoperability. It is a big world out there, and the HIM can help by exposing the underlying eHealth infrastructure to this world via a set of interfaces expressed in “business” terms, and which hide the underlying complexities.

Canada’s first provincial implementation of the Infoway eHealth “blueprint” was done by a company that felt that not much value was added by the health information access layer (Infoway’s HIAL, what we call the HIM). They set it up as not much more than a message router and felt that all the real work would be done by the registries and repositories and/or by the client applications. Theirs is a cautionary tale… the project success was undermined by the absence of a centralized place to do things like terminology resolution, end-point authentication, consent management, etc. Needless to say, subsequent provincial implementations paid much more attention to the role of the HIAL/HIM.

The preceding airing of dirty laundry was NOT approved by Canada Health Infoway nor by the province in question, whose name is withheld to protect the innocent… and the guilty! :wink:

Hope this helps the discussion…

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 22, 2013 1:35 PM
To: openhie-shr
Subject: RE: How closely tied should the HIM and SHR be? Sometimes transforms messages

I realize that many people, Odysseas and Hannes in particular, see the HIM as providing significant orchestration.

I’m coming to think of as sometimes providing orchestration

The point of my naming it “a V2 Backbone” was to emphasize the role of V2.

It seems true to me that if the edge nodes create “perfect HL7” for insertion into the SHR, then there is nothing (little) for the HIM to do, and it seems natural that that SHR accept the V2 and process it. . I think it is important for the SHR and the edge nodes to use the same representation (V2)

What I like about that story is that it focuses attention on the V2 HL7. Once it is perfect, we win. And, when there are problems, I want to see how the problem (and its solution) is manifest in the V2 messages.

So, I think of the HIM as providing “orchestration” only to the extent that messages need it.

If the original message had good providers, facilities, patients and codes, and it used OBX’s properly, then there would be nothing to do in the HIM.

In the case of imperfect messages from, say disconnected edge nodes that could not consult the restfully-exposed Registries, or from pre-existing HL7 systems that do their own thing, then the HIM will have plenty to do.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter
Sent: Monday, April 22, 2013 9:07 AM
To: Odysseas Pentakalos, Ph.D.; openhie-shr
Subject: Re: How closely tied should the HIM and SHR be?

Hi Odysseas, thank you for the great comments. Just cc’ing the list…

On Mon, Apr 22, 2013 at 1:07 PM, Odysseas Pentakalos, Ph.D. odysseas@sysnetint.com wrote:

Hi Hannes,

My view is that the HIM provides the “glue” that ties together all the other components of the OpenHIE.

  • It provides the data transformation services that may be needed to adapt the messages in and out of the overall exchange to the interfaces supported by
    any of the exchanges
  • It provides orchestration needed in the processing of individual messages by one or more registries
  • It can provide the distribution that may be needed to support multiple instances of the SHR (or the CR)
  • It provides centralized handling of security (and probably adapts to the security scheme of the individual CRs)
  • It can provide transaction monitoring and performance monitoring services since it sees every message go by

In summary, I see the HIM forming the perimeter around the other registries which would make the discussion
about how to best store the clinical data in the SHR the focus of only the SHR and which messaging format
to use to exchange data the focus of the HIM.

Best regards,
Odysseas

On 04/22/2013 06:22 AM, Hannes Venter wrote:

Hi Everyone,

I just wanted to kickoff the following question from Mark Tucker’s email threads on this list:

How closely should the HIM and SHR be tied together? Where should the boundary be around them?

My feeling is very closely, given the need for splitting data up to stores such discrete or document,

tasks which might be better in the HIM rather than a little “logic processor” as part of the SHR (or not?).

I look forward to all responses :slight_smile:

Regards

Hannes


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.

--

Odysseas Pentakalos, Ph.D., PMP

Chief Technology Officer

SYSNET International, Inc.

2930 Oak Shadow Drive

Oak Hill, Virginia 20171

mailto:odysseas@sysnetint.com

(703) 855-2029


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.

Thanks Derek.

I want to understand in some concreteness what business function is being done in the HIM.

I would like to understand how Province X’s message router failed.

Mind you, it is just my starting point to say: If the messages look good from the edge nodes, we can pass them directly to the SHR.

In the INPC, we so much believe in “orchestration” that we do our orchestration in Java Code. Then, we can do arbitrary computations. But, a hand full of
interfaces are just “pass through”. The original HL7 works perfectly, and we step aside.

···

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Derek Ritz (ecGroup)
Sent: Monday, April 22, 2013 1:47 PM
To: Tucker, Mark; ‘openhie-shr’
Subject: RE: How closely tied should the HIM and SHR be? Sometimes transforms messages

Hmmm… it is my experience that the HIM’s orchestration is actually very important to sustained and managed interoperability. It is a big world out there, and
the HIM can help by exposing the underlying eHealth infrastructure to this world via a set of interfaces expressed in “business” terms, and which hide the underlying complexities.

Canada’s first provincial implementation of the Infoway eHealth “blueprint” was done by a company that felt that not much value was added by the health information
access layer (Infoway’s HIAL, what we call the HIM). They set it up as not much more than a message router and felt that all the real work would be done by the registries and repositories and/or by the client applications. Theirs is a cautionary tale… the
project success was undermined by the absence of a centralized place to do things like terminology resolution, end-point authentication, consent management, etc. Needless to say, subsequent provincial implementations paid much more attention to the role of
the HIAL/HIM.

The preceding airing of dirty laundry was NOT approved by Canada Health Infoway nor by the province in question, whose name is withheld to protect the innocent…
and the guilty! :wink:

Hope this helps the discussion…

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 22, 2013 1:35 PM
To: openhie-shr
Subject: RE: How closely tied should the HIM and SHR be? Sometimes transforms messages

I realize that many people, Odysseas and Hannes in particular, see the HIM as providing significant orchestration.

I’m coming to think of as sometimes providing orchestration

The point of my naming it “a V2 Backbone” was to emphasize the role of V2.

It seems true to me that if the edge nodes create “perfect HL7” for insertion into the SHR, then there is nothing (little) for the HIM to do, and it seems natural
that that SHR accept the V2 and process it. . I think it is important for the SHR and the edge nodes to use the same representation (V2)

What I like about that story is that it focuses attention on the V2 HL7. Once it is perfect, we win. And, when there are problems, I want to see how the
problem (and its solution) is manifest in the V2 messages.

So, I think of the HIM as providing “orchestration” only to the extent that messages need it.

If the original message had good providers, facilities, patients and codes, and it used OBX’s properly, then there would be nothing to do in the HIM.

In the case of imperfect messages from, say disconnected edge nodes that could not consult the restfully-exposed Registries, or from pre-existing HL7 systems
that do their own thing, then the HIM will have plenty to do.

From:
openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Hannes Venter
Sent: Monday, April 22, 2013 9:07 AM
To: Odysseas Pentakalos, Ph.D.; openhie-shr
Subject: Re: How closely tied should the HIM and SHR be?

Hi Odysseas, thank you for the great comments. Just cc’ing the list…

On Mon, Apr 22, 2013 at 1:07 PM, Odysseas Pentakalos, Ph.D. odysseas@sysnetint.com wrote:

Hi Hannes,

My view is that the HIM provides the “glue” that ties together all the other components of the OpenHIE.

  • It provides the data transformation services that may be needed to adapt the messages in and out of the overall exchange to the interfaces supported by
    any of the exchanges
  • It provides orchestration needed in the processing of individual messages by one or more registries
  • It can provide the distribution that may be needed to support multiple instances of the SHR (or the CR)
  • It provides centralized handling of security (and probably adapts to the security scheme of the individual CRs)
  • It can provide transaction monitoring and performance monitoring services since it sees every message go by

In summary, I see the HIM forming the perimeter around the other registries which would make the discussion
about how to best store the clinical data in the SHR the focus of only the SHR and which messaging format
to use to exchange data the focus of the HIM.

Best regards,
Odysseas

On 04/22/2013 06:22 AM, Hannes Venter wrote:

Hi Everyone,

I just wanted to kickoff the following question from Mark Tucker’s email threads on this list:

How closely should the HIM and SHR be tied together? Where should the boundary be around them?

My feeling is very closely, given the need for splitting data up to stores such discrete or document,

tasks which might be better in the HIM rather than a little “logic processor” as part of the SHR (or not?).

I look forward to all responses :slight_smile:

Regards

Hannes


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
.

--

Odysseas Pentakalos, Ph.D., PMP

Chief Technology Officer

SYSNET International, Inc.

2930 Oak Shadow Drive

Oak Hill, Virginia 20171

mailto:odysseas@sysnetint.com

(703) 855-2029


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.


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.

Some context would likely help. This provincial eHealth implementation serves a population of 4.5 million. Supported health services include primary, specialist and acute care; radiology and lab orders and reporting; drug prescriptions and dispensing; telehealth; and public health (including surveillance). The provincial EHR (in Canada, EHR means longitudinal, shared health record) supports both active care delivery and is also used to feed data warehouses for health system management by the provincial MOH. The scope, therefore, includes secure connections to the province’s 95 hospitals, 33 extended care hospitals and health centres and 11 health outposts. It also includes secure connections to 10,000 physicians (via their EMRs or the provincial EHR portal), 1116 community and 68 hospital pharmacies (with ~5000 total users) and 106 public labs and 137 private lab collection points (with ~4200 lab technicians using, sadly, more than 27 different LMISs). All of these users from all of these points of access are potential sources of eHealth content and potential consumers. There are also patient portals (more than one) which provide secure consumer access to the EHR, or subsets of it.

In supporting such an EHR, the role of a HIM is to centralize important shared services like node authentication, auditing, provider authentication, role-based access control, the management of patient consent directives, etc. From an orchestration standpoint, inbound messages are normalized regarding clinical terminologies and the message identifiers (client, provider and location) are resolved to enterprise IDs (ECID, ELID, EPID) before records are written to the respective repositories. Where the inbound message is a query to the shared health record, patient consent directives are applied to the outbound result set, as appropriate. Importantly, where an inbound query requires content from multiple repositories to be combined (e.g. a patient summary which would include information from the shared health record, the lab repository, DI repository and the drug repository), it is the role of the HIM to fetch this information and collate it into a single response message. There are also cases (but not many, yet) where system-level logic is triggered to support clinical decision support (such as warnings about drug-drug interactions, for example).

Of course, a province could choose (initially, at least), to NOT employ a HIM in the ways described above. The HIM could simply route inbound messages to the appropriate registry or repository – nothing more. In fact, in its pilot phase, such a design could even appear to have excellent performance (nothing in the “middle” to slow things down).

As the number of repositories increased to include labs and DI and drugs and public health surveillance, however, this meant that each of these above-the-HIM assets needed to be able to separately do all the centralized services (do their own authentication, and RBAC, and auditing, and consent management, etc.). Each repository had to do its own ID resolution and terminology normalization, too. And the challenge of doing a summary record, where information was needed from multiple repositories, proved genuinely challenging.

Mark, it is harsh to say that province X’s eHealth infrastructure failed because of its original HIM design. It didn’t fail. It was just that things that initially looked like they were a good idea proved not to be as good an idea when:

· The program scaled from its initial pilot to a full rollout; and

· The program matured from its implementation phase to its operation/maintenance phase.

In its initial (pilot) phase – things that had a point-to-point, light-in-the-middle “feel” to them worked just fine. Soon, however, the shared “utility” aspect of a HIM was sorely missing as the challenges of many-to-many connections and the maintenance of multiple redundant services started to make management truly difficult and began to negatively impact system performance. These issues were addressed; sometimes elegantly, sometimes not. Eventually it was all got to a working state, albeit at the expense of added project time and cost.

To be clear, if none of this is applicable to the deployment scenarios we are contemplating then these issues may not bear consideration. Canada and Rwanda are different in many respects. FWIW, these are insights into challenges that beset one of our Canadian eHealth implementations and which were not EVER included in the Ministry’s press releases or official updates. :wink:

Hope this is helpful…

Derek.

PS: It varies, but some Canadian provinces allow client applications (below the HIM) to cache the ECID, EPID and ELID values. Others, like my province (Ontario) simply decided to use the provincial health ID number as the ECID. These tactics help, but it is still very difficult to get the point where all the HL7 messages (v3 or v2) are perfect and there is no need for the HIM to do any work. We’ve not been able to get there; or not yet, anyway.

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 22, 2013 1:56 PM
To: ‘openhie-shr’
Subject: RE: How closely tied should the HIM and SHR be? Sometimes transforms messages

Thanks Derek.

I want to understand in some concreteness what business function is being done in the HIM.

I would like to understand how Province X’s message router failed.

Mind you, it is just my starting point to say: If the messages look good from the edge nodes, we can pass them directly to the SHR.

In the INPC, we so much believe in “orchestration” that we do our orchestration in Java Code. Then, we can do arbitrary computations. But, a hand full of interfaces are just “pass through”. The original HL7 works perfectly, and we step aside.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Derek Ritz (ecGroup)
Sent: Monday, April 22, 2013 1:47 PM
To: Tucker, Mark; ‘openhie-shr’
Subject: RE: How closely tied should the HIM and SHR be? Sometimes transforms messages

Hmmm… it is my experience that the HIM’s orchestration is actually very important to sustained and managed interoperability. It is a big world out there, and the HIM can help by exposing the underlying eHealth infrastructure to this world via a set of interfaces expressed in “business” terms, and which hide the underlying complexities.

Canada’s first provincial implementation of the Infoway eHealth “blueprint” was done by a company that felt that not much value was added by the health information access layer (Infoway’s HIAL, what we call the HIM). They set it up as not much more than a message router and felt that all the real work would be done by the registries and repositories and/or by the client applications. Theirs is a cautionary tale… the project success was undermined by the absence of a centralized place to do things like terminology resolution, end-point authentication, consent management, etc. Needless to say, subsequent provincial implementations paid much more attention to the role of the HIAL/HIM.

The preceding airing of dirty laundry was NOT approved by Canada Health Infoway nor by the province in question, whose name is withheld to protect the innocent… and the guilty! :wink:

Hope this helps the discussion…

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 22, 2013 1:35 PM
To: openhie-shr
Subject: RE: How closely tied should the HIM and SHR be? Sometimes transforms messages

I realize that many people, Odysseas and Hannes in particular, see the HIM as providing significant orchestration.

I’m coming to think of as sometimes providing orchestration

The point of my naming it “a V2 Backbone” was to emphasize the role of V2.

It seems true to me that if the edge nodes create “perfect HL7” for insertion into the SHR, then there is nothing (little) for the HIM to do, and it seems natural that that SHR accept the V2 and process it. . I think it is important for the SHR and the edge nodes to use the same representation (V2)

What I like about that story is that it focuses attention on the V2 HL7. Once it is perfect, we win. And, when there are problems, I want to see how the problem (and its solution) is manifest in the V2 messages.

So, I think of the HIM as providing “orchestration” only to the extent that messages need it.

If the original message had good providers, facilities, patients and codes, and it used OBX’s properly, then there would be nothing to do in the HIM.

In the case of imperfect messages from, say disconnected edge nodes that could not consult the restfully-exposed Registries, or from pre-existing HL7 systems that do their own thing, then the HIM will have plenty to do.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter
Sent: Monday, April 22, 2013 9:07 AM
To: Odysseas Pentakalos, Ph.D.; openhie-shr
Subject: Re: How closely tied should the HIM and SHR be?

Hi Odysseas, thank you for the great comments. Just cc’ing the list…

On Mon, Apr 22, 2013 at 1:07 PM, Odysseas Pentakalos, Ph.D. odysseas@sysnetint.com wrote:

Hi Hannes,

My view is that the HIM provides the “glue” that ties together all the other components of the OpenHIE.

  • It provides the data transformation services that may be needed to adapt the messages in and out of the overall exchange to the interfaces supported by
    any of the exchanges
  • It provides orchestration needed in the processing of individual messages by one or more registries
  • It can provide the distribution that may be needed to support multiple instances of the SHR (or the CR)
  • It provides centralized handling of security (and probably adapts to the security scheme of the individual CRs)
  • It can provide transaction monitoring and performance monitoring services since it sees every message go by

In summary, I see the HIM forming the perimeter around the other registries which would make the discussion
about how to best store the clinical data in the SHR the focus of only the SHR and which messaging format
to use to exchange data the focus of the HIM.

Best regards,
Odysseas

On 04/22/2013 06:22 AM, Hannes Venter wrote:

Hi Everyone,

I just wanted to kickoff the following question from Mark Tucker’s email threads on this list:

How closely should the HIM and SHR be tied together? Where should the boundary be around them?

My feeling is very closely, given the need for splitting data up to stores such discrete or document,

tasks which might be better in the HIM rather than a little “logic processor” as part of the SHR (or not?).

I look forward to all responses :slight_smile:

Regards

Hannes


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.

--

Odysseas Pentakalos, Ph.D., PMP

Chief Technology Officer

SYSNET International, Inc.

2930 Oak Shadow Drive

Oak Hill, Virginia 20171

mailto:odysseas@sysnetint.com

(703) 855-2029


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.


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.

Mark,

Thanks for sharing the information about the internal operation of the INPC. It is good to learn more about the internals of this well known HIE.

My point was not so much that the HIM will provide a lot of orchestration but rather that if there is orchestration needed in a particular use
case, then that orchestration should reside on the HIM and not the individual registries. Each of the registries and other services of the HIE
should be really good at what they do and the design decisions used to put them together should be made independently of the the particular
messaging technologies that will be used by external entities to interact with them.

By requiring the SHR to deal with HL7 v2 we are in my opinion unnecessarily tying its operation to a particular messaging standard. If we
can dictate that all the consumers of the HIE will have to use HL7 v2 to interact with the HIE then that may not be an issue. If we anticipate
that we may run into HIE consumers that will prefer some other messaging technology, it becomes important to keep the SHR focused
on efficiently storing and providing access to clinical (and maybe financial data) and let the HIM deal with adapting external messaging standards
to internal APIs.

I am curious at to what message rates are you processing on a daily basis from all the data providers, if you don't mind sharing?

Thanks,
Odysseas

···

On 04/22/2013 01:34 PM, Tucker, Mark wrote:

I realize that many people, Odysseas and Hannes in particular, see the HIM as providing significant orchestration.

I'm coming to think of as **sometimes providing orchestration** --

The point of my naming it "a V2 Backbone" was to emphasize the role of V2.

It seems true to me that if the edge nodes create "perfect HL7" for insertion into the SHR, then there is nothing (little) for the HIM to do, and it seems natural that that SHR accept the V2 and process it. . I think it is important for the SHR and the edge nodes to use the same representation (V2)

What I like about that story is that it focuses attention on the V2 HL7. Once it is perfect, we win. And, when there are problems, I want to see how the problem (and its solution) is manifest in the V2 messages.

So, I think of the HIM as providing "orchestration" only to the extent that messages need it.

If the original message had good providers, facilities, patients and codes, and it used OBX's properly, then there would be nothing to do in the HIM.

In the case of imperfect messages from, say disconnected edge nodes that could not consult the restfully-exposed Registries, or from pre-existing HL7 systems that do their own thing, then the HIM will have plenty to do.

*From:*openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] *On Behalf Of *Hannes Venter
*Sent:* Monday, April 22, 2013 9:07 AM
*To:* Odysseas Pentakalos, Ph.D.; openhie-shr
*Subject:* Re: How closely tied should the HIM and SHR be?

Hi Odysseas, thank you for the great comments. Just cc'ing the list...

On Mon, Apr 22, 2013 at 1:07 PM, Odysseas Pentakalos, Ph.D. > <odysseas@sysnetint.com <mailto:odysseas@sysnetint.com>> wrote:

Hi Hannes,

My view is that the HIM provides the "glue" that ties together all the other components of the OpenHIE.

- It provides the data transformation services that may be needed to adapt the messages in and out of the overall exchange to the interfaces supported by
any of the exchanges
- It provides orchestration needed in the processing of individual messages by one or more registries
- It can provide the distribution that may be needed to support multiple instances of the SHR (or the CR)
- It provides centralized handling of security (and probably adapts to the security scheme of the individual CRs)
- It can provide transaction monitoring and performance monitoring services since it sees every message go by

In summary, I see the HIM forming the perimeter around the other registries which would make the discussion
about how to best store the clinical data in the SHR the focus of only the SHR and which messaging format
to use to exchange data the focus of the HIM.

Best regards,
Odysseas

On 04/22/2013 06:22 AM, Hannes Venter wrote:

    Hi Everyone,

    I just wanted to kickoff the following question from Mark Tucker's
    email threads on this list:

    /How closely should the HIM and SHR be tied together? Where should
    the boundary be around them?/

    My feeling is very closely, given the need for splitting data up
    to stores such discrete or document,

    tasks which might be better in the HIM rather than a little "logic
    processor" as part of the SHR (or not?).

    I look forward to all responses :slight_smile:

    Regards

    Hannes

    -- /Hannes Venter
    Software Developer, Jembi Health Systems | SOUTH AFRICA
    Mobile: +27 73 276 2848 <tel:%2B27%2073%20276%202848> | Office:
    +27 21 701 0939 <tel:%2B27%2021%20701%200939> | Skype: venter.johannes
    E-mail: hannes@jembi.org <mailto: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
    <mailto:openhie-shr+unsubscribe@googlegroups.com>.
    For more options, visit https://groups.google.com/groups/opt_out
    <https://groups.google.com/groups/opt_out>.

--
Odysseas Pentakalos, Ph.D., PMP
Chief Technology Officer
SYSNET International, Inc.
2930 Oak Shadow Drive
Oak Hill, Virginia 20171
mailto:odysseas@sysnetint.com
(703) 855-2029

--
/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 <mailto: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 <mailto: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.

--
Odysseas Pentakalos, Ph.D., PMP
Chief Technology Officer
SYSNET International, Inc.
2930 Oak Shadow Drive
Oak Hill, Virginia 20171
mailto:odysseas@sysnetint.com
(703) 855-2029

Let’s keep this going.

him_and_shr_and_v2.txt (2.56 KB)

···

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Odysseas Pentakalos, Ph.D.
Sent: Monday, April 22, 2013 9:05 PM
To: openhie-shr@googlegroups.com
Subject: Re: How closely tied should the HIM and SHR be? Sometimes transforms messages

Mark,

Thanks for sharing the information about the internal operation of the INPC. It is good to learn more about the internals of this well known HIE.

My point was not so much that the HIM will provide a lot of orchestration but rather that if there is orchestration needed in a particular use
case, then that orchestration should reside on the HIM and not the individual registries. Each of the registries and other services of the HIE
should be really good at what they do and the design decisions used to put them together should be made independently of the the particular
messaging technologies that will be used by external entities to interact with them.

By requiring the SHR to deal with HL7 v2 we are in my opinion unnecessarily tying its operation to a particular messaging standard. If we
can dictate that all the consumers of the HIE will have to use HL7 v2 to interact with the HIE then that may not be an issue. If we anticipate
that we may run into HIE consumers that will prefer some other messaging technology, it becomes important to keep the SHR focused
on efficiently storing and providing access to clinical (and maybe financial data) and let the HIM deal with adapting external messaging standards
to internal APIs.

I am curious at to what message rates are you processing on a daily basis from all the data providers, if you don’t mind sharing?

Thanks,
Odysseas

Hi all,

This is a great discussion!

I wanted to summarise what I’m hearing here. I think we are all actually in a agreement. The base concept is that the HIM should be responsible for performing orchestration to the services of the HIE so that that logic does not have to be replicated between the actual services. However, it is also noted that there will be times when orchestration isn’t required and the HIM in that case should be able to just forward on the message on to the correct service. As a minimum the HIM must always handle security, logging and auditing and it shall provide for advanced orchestration if it is required. Is this captured correctly?

Mark, I agree HL7v2 is easy to learn and is very pervasive. It is a good contender to be included in the OpenHIE architecture. We have begun creating a standards evaluation tool so that we can see what different standards offer. v2 and XDS seems to be a good complimentary set so far, with FHIR looking interesting as well as it can do both discrete and document based data. Perhaps, the answer is not to support a single standard but to add support for multiple standards as over time different standards may need to be supported.

Cheers,

Ryan

···

On Tue, Apr 23, 2013 at 3:35 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Let’s keep this going.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Odysseas Pentakalos, Ph.D.
Sent: Monday, April 22, 2013 9:05 PM
To: openhie-shr@googlegroups.com
Subject: Re: How closely tied should the HIM and SHR be? Sometimes transforms messages

Mark,

Thanks for sharing the information about the internal operation of the INPC. It is good to learn more about the internals of this well known HIE.

My point was not so much that the HIM will provide a lot of orchestration but rather that if there is orchestration needed in a particular use
case, then that orchestration should reside on the HIM and not the individual registries. Each of the registries and other services of the HIE
should be really good at what they do and the design decisions used to put them together should be made independently of the the particular
messaging technologies that will be used by external entities to interact with them.

By requiring the SHR to deal with HL7 v2 we are in my opinion unnecessarily tying its operation to a particular messaging standard. If we
can dictate that all the consumers of the HIE will have to use HL7 v2 to interact with the HIE then that may not be an issue. If we anticipate
that we may run into HIE consumers that will prefer some other messaging technology, it becomes important to keep the SHR focused
on efficiently storing and providing access to clinical (and maybe financial data) and let the HIM deal with adapting external messaging standards
to internal APIs.

I am curious at to what message rates are you processing on a daily basis from all the data providers, if you don’t mind sharing?

Thanks,
Odysseas

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