Second Amen.
···
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:
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.