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