Hi Ryan (and all).
I think it is a matter of perspective. I’m looking at this issue from a national MOH standpoint. That is why I referred to this as an “ecosystem” choice.
If I were the government of _________ (fill in the blank here), and I were establishing the national eHealth norms and standards which will ensure broad interoperability across all my public and private sector care systems and provide the reportable indicators I need for health system management, I am at the same time choosing:
· The standards bodies I will participate in (are they easy/inexpensive to work with, or hard/expensive?)
· The specifications I will train my staff in (is training readily available?)
· The specifications I will want my technical institutions to provide health informatics education in (is this “mainstream” or will graduates be out of step with global marketplace?)
· The specifications I will write into procurement documents (is it easy for me, in legal language, to describe the properties of a “conformant”, interoperable eHealth product?)
· The economy of products and services in the private sector market that will I be supporting (is there a wealth of options to choose from… or am I left with few choices… or only one?)
· The burden of conformance testing (is there an easy way to do this, or do I have to establish my own testing and certification facilities?)
· The amount of risk I’m taking on (is this a new specification, or a mature one?)
· The amount of change I’m taking on (will existing health IT products be able to readily connect, or do they need to be modified… or replaced altogether?)
Strategically, what is OpenHIE – when looked at from the point of view of a national MOH? At the simplest level, it either is, or isn’t, a credible product candidate to be deployed as eHealth interoperability infrastructure. At this simple, product-choice level… OpenHIE is either consistent with the country’s existing eHealth standards or it isn’t.
But I feel there is (or should be) a taller aspect to the OpenHIE initiative, taller than just the product aspect. Quite a significant number of countries in our “target market” are only just now approaching the issue of establishing a national set of eHealth norms and standards. That is why I think our choices regarding eHealth standards should not be treated as software programmer choices… I think they should be treated as “national eHealth ecosystem” choices.
This is also why I think the selection of a stack-of-standards is a strategic, pan-OHIE decision.
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: Ryan Crichton [mailto:ryan@jembi.org]
Sent: August 6, 2013 4:47 AM
To: Derek Ritz (ecGroup)
Cc: openhie-shr; ohie-architecture@googlegroups.com; ohie-leadership@googlegroups.com
Subject: Re: Standard for the SHR
Hi Derek,
Do you think it needs to be as black and white as that? That we can only use a single standards stack? I understand that for particular domains within the exchange it makes sense to use a specific standards stack. For example, for the provider registry and facility registry we could use the IHE CSD profile for interregistry communication but for communicating clinical data from point of care systems to the SHR we could, say, use FHIR. Why would we need to just use a single stack when the purposes are different?
It seems to me that the world is moving in a direction where many simple things (standards, services, technologies, software libraries etc.) can be combined as needed to provide higher level functions. Is this not the same in this case? Could we not combine the use of multiple simple standards with particular purposes to gain the overall required functionality of OpenHIE?
Perhaps, I am naiive here, but I don’t see the how this need to all be the same stack. Could you explain your reasoning?
I do agree that we need to define what the standard(s) are that we plan to use under OpenHIE and the define the interactions that we wish to support between service requesters and inter-registry.
Cheers,
Ryan
On Mon, Aug 5, 2013 at 6:07 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
There are two considerations which I believe are important for us. Our choice of a standard for SHR (or any other element) should be consistent with our overall choice of a standards “stack”. I don’t think these choices are community choices in isolation. For the OpenHIE puzzle pieces to be interoperable with each other, and with the world outside the datacentre, they will all need to be adherent to the same stack.
This brings in the second consideration. Which stack is strategically the right one for OpenHIE? I’ve not seen a directive yet resulting from our strategy session in Indy – but I know that the stack of standards choice strategically “positions” us within our target community of MOH and implementing stakeholders. In that regard, one could make a case that it is in scope for the executive leadership to decide.
Importantly, I believe this should be treated as an “ecosystem” decision. I can also tell you from first-hand experience that the ecosystem matters more than the technological “beauty” of the standards spec itself. Canada’s national experience is very informative on this point.
In my view, the stack-of-standards choice is one which I think should be made as a pan-OHIE choice. All of our communities have the technical skill to work within the chosen spec, no matter what it is. But we should all be singing off the same songsheet; it makes no sense to do otherwise.
DJ
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 Ryan Crichton
Sent: August 5, 2013 9:47 AM
To: openhie-shr@googlegroups.com
Subject: Standard for the SHR
Hi all,
I have started a wiki page on the OHIE wiki that puts together some of our discussions of the different standard that we could use for exchanging information with the SHR.
I’ve drawn from our previous discussion and my personal experience to create the first version of this page. This is only an initial draft, please let me know if you agree, or disagree with any of the content or if you have something else that you would like to see added and we can iterate on this content.
The idea with this page is to summarise our feeling about each standards in relation to the SHR so we can come to a decision on what standard makes the most sense to implement for the SHRs service interface.
Here is the link to the wiki page: https://wiki.ohie.org/display/SUB/Standards+for+the+Shared+Health+Record
Cheers,
Ryan
–
Ryan Crichton
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.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org