So, for best results, the local SHR should keep information about the people it has seen as long as possible.
Then, when they need to see a patient, try to refresh it from the SHR.
Else, go with the local copy.
If people don’t move around, then the local copy will have everything.
Poor connectivity suggests keeping as much data in the edge node as possible, since you might be cut off for a long time.
···
From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Derek Ritz (ecGroup)
Sent: Tuesday, June 04, 2013 2:28 PM
To: Biondich, Paul G
Cc: ‘James Kariuki’; ‘Chris Ford’; ‘openhie-shr’
Subject: RE: Distributed health records
Hi Paul.
Like I said – trickier math changes nothing about the conclusion. To make the argument for multiple federated vs. a single SHR I’d have to believe:
·
network connectivity to the federated SHR is different than (or somehow better than) my connectivity to the single centralized SHR; and
·
I don’t travel… but of course I might… and so my single federated SHR really cannot provide better than an opportunistic health record.
My point is that the math, although counterintuitive, is what it is. If you have network availability issues, federating does not help you it makes it worse.
This is a counterintuitive truth because people think in terms of near and far; a database in the local city is “easier” to access than one in the nation’s
capital… because it is closer. The IT reality is much more binary.
Re: the definitive vs. opportunistic record – Paul, you are most certainly correct that many issues affect the usefulness of a clinical record that are totally
unrelated to arcane network architecture. Both a definitive design and an opportunistic design will suffer foibles. The key difference is that addressing these foibles only accrues an efficiency benefit in a definitive record design.
J
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 Paul Biondich
Sent: June 4, 2013 2:04 PM
To: Derek Ritz (ecGroup)
Cc: James Kariuki; Chris Ford; openhie-shr
Subject: Re: Distributed health records
Derek, the only part of your email I’d quibble with is the extent of an individual’s health record being distributed equally amongst different regions.
The adage that “healthcare is local” applies fairly often in my experience, and as such, regional HIEs often do a credible job of being “definitive” for an individual, if they are organized around medical service areas
(which most often cluster around population centers). I would imagine in resource-constrained environments that this might even be more true.
However, most of the historical context around environments and how they lump or split almost always is a product of the socio-political context within an environment, and less about the technical convenience of one approach
vs. another.
-Paul
PS: Good luck getting to a true “definitive” health record, as almost all health environments struggle to document what happens within their own environment effectively. 
Gathering electronic clinical data is opportunistic
almost by definition, as a result… but I agree with your general sentiment about trying to push towards as complete as possible.
On Tue, Jun 4, 2013 at 1:52 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
I want to put a thought out there re: decentralized vs. centralized – mostly because there is a
counterintuitive aspect to this.
In a decentralized model, it is very different to look at local data plus a replica that is centralized
(single SHR) vs. local data plus a replica that is federated (multiple SHRs). The “math” of this is negatively impacted by the very thing that incents us to federate – the problem of “poor/spotty connectivity”. Here’s why:
-
assume the definitive health record for Derek, at some arbitrary time and place, is defined as the SHR content plus the local content
-
because it makes the math easy to illustrate, assume the network availability is 90%
-
assume local data is available at some reliability R where R<=100%
In a single SHR scenario, the likelihood that Derek’s definitive health record will be available
is 0.9R.
In a federated SHR scenario with 4 regional SHRs, the likelihood that Derek’s definitive health
record will be available is R * .9 * .9 * .9 *.9 = 0.63R.
There are all kinds of ways to make the math more accurate by making it trickier (e.g. what is the
statistical expectation that Derek travels outside the region covered by his local SHR? What is the expectation that he travels to more than one region? Etc.). None of this trickiness will change the fact, however, that if your likelihood of having network
access is 90%, your highest likelihood of being able to develop Derek’s definitive health record will come from having a single SHR. It is also the easiest situation to determine whether you have Derek’s entire record or not since you simply need to answer:
“did you or did you not reach the SHR?” (as opposed to: “how many SHRs are there… and did I hear back from all of them?”).
Hope this helps our discussion,
Derek.
PS: A definitive health record is one you can make a medical decision from; it may be contrasted
with an opportunistic health record that “might” provide you with content, or might have bits missing… and you make the best use you can of what you get. Basically, you always practice “defensive medicine” in the face of an opportunistic health record so you
never enjoy economic efficiencies (e.g. reduced lab testing).
**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 James Kariuki
Sent: June 4, 2013 1:16 PM
To: Chris Ford
Cc: openhie-shr
Subject: Re: Distributed health records
Hi Chris,
Using decentralized or federated systems could be one way to share records in low resource settings.
Something to also consider is the amount of data exchanged or shared between the system. For example, in places where the infrastructure is not well established
or developed, is it ok to send only records required for patient care?
Thanks
James
On Tue, Jun 4, 2013 at 12:11 PM, Chris Ford christophertford@gmail.com wrote:
Hi all,
I was discussing with some of my colleagues who are involved with health records systems, and they mentioned an implication of our “low resource setting” NFR.
Connectivity between hospitals can be intermittent and low bandwidth, as we have discussed. That could challenge any solution’s ability to keep data synchronised
across the entire system. For example, it might not be feasible to continuously push large files e.g. from radiology to the central node.
Could we cope with a system where some artefacts or even records are decentralised/federated? Would a country with such a system be able to integrate with OpenHIE,
perhaps with extra development effort on their part?
This is based on a real scenario we’ve encountered recently.
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.
–
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.
Gathering electronic clinical data is opportunistic almost by definition, as a result… but I agree with your general sentiment about trying to push towards as complete as possible.