Hi Ryan.
Thanks for getting the conversation started! 
I deliberated quite a long while on whether to recommend using on-demand docs to share the antepartum summary (APS) info. An alternative is to manage the CDA as a ‘static’ CDA – and that is actually the assumed deployment model in the IHE spec. The problem is, it would require every POS to fetch the CDA, update it as a document with new content, and submit it back to the HIE as a “replacement” document to the one that was downloaded. Although many EMRs are document-centric, that isn’t the case for OpenMRS and I didn’t think it would be an elegant way to try to do it (for that reason, and others).
The on-demand document idea is one that I like very much as a way for a point of service (POS) application to get “the latest” clinical info from the HIE. From work Justin is doing, we know OpenMRS can manage IDs (for provenance) alongside every data element. We also have all been following Suranga’s successes (and occasional trials) as the GSoC project moves forward with CDA generation from within OpenMRS. These two aspects pointed to on-demand docs as a quite viable option. Basically, I believe OpenMRS can readily generate an APS on demand and share it (either from the SHR side, or the POS side) and this APS will have the “provenance” of the data elements that make it up – so we can tell what’s “new” from what was from before. Being able to re-use the identical functionality at the HIE and at the POS is attractive.
At a larger level, tho, I also very much like the idea of having the POS receive, not just the most up-to-date APS info, but the most up-to-date info from the HIE across all clinical domains/programmes. I’d like us to consider having the “get the latest” query return the more comprehensive XDS-MS CDA containing a complete health summary record – which will be a superset of what’s in the APS. This usefully would put ongoing management of a woman’s pregnancy into the context of any other care she may be receiving and which may be getting updated to her SHR (e.g. HIV care, TB care, asthma or diabetes, etc.). On-demand documents are perfect for generating health summary records; it is their bread-and-butter use case. 
Re: the CR… I regret now that I focused on the PAM ITI-30 transaction and not the PIX ITI-8 transaction. I did recommend ITI-8 for supporting the Merge functionality but I recalled (in error, as it turns out) that PAM was in the plans for the CR community. I think now that this maybe isn’t the case. I’m not at all sure whether it should be. My personal opinion is that the support in the PAM profile for link/unlink may be favour that one, but that is for the CR team to determine. We don’t today do either Merge or Split… but with ITI-8 we will never be able to do Split. If that is an important use case, I think ITI-30 may end up being “the right horse for the course”.
The document has a glaring gap re: alerts/messages. I’ve previously shared a PPT deck (two, actually) on this topic so I thought it best to not duplicate my thoughts in the present deck. Alerting is a very impactful eHealth intervention; my sense is that we really need to close this gap for our OpenHIE v1 to deliver on its mandate of improving health outcomes. I hope discussion on that topic will be re-ignited by this.
Warmest regards, and thanks again, Ryan.
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: Thursday, August 7, 2014 4:25 AM
To: Derek Ritz
Cc: openhie-interoperability-layer@googlegroups.com; openhie-shr@googlegroups.com; ohie-architecture@googlegroups.com; ohie-sandbox@googlegroups.com
Subject: Re: What does OpenHIE v1.0 do?
Hi Derek,
This is a great resource, thanks for putting it together. In general this fit with my thinking of how the Rwanda use case can be covered. I have a few thoughts:
-
Maybe we don’t need to support the on-demand documents option for the SHR. We could just use the SHRs ability to store entire ‘as-is’ documents to enable the workflow. Generating APS documents that are a good reflection of the documents that we originally received may be a challenge with, at this stage, unknown difficulties associated with it.
-
I think you make some good point about the profiles about that the client registry should support. There are various merge or link and unlink options that need to be supported. It would be interesting to hear from the CR community about what they think of this and how/if the interactions that Derek describes can-be/are supported.
-
It seems there is a new workflow that I don’t think we have documented as an OpenHIE workflow around the merging of patients. It seems the SHR should be informed of a merge (from your interaction diagram). Perhaps that is a workflow that we need to add to OpenHIEs list of supported workflows?
Looking forward to hearing what people think.
Cheers,
Ryan
On Thu, Aug 7, 2014 at 1:27 AM, Derek Ritz derek.ritz@ecgroupinc.com wrote:
Hi all.
This is a discussion document. As I have said quite regularly, lately, I think we collectively need to figure out what OpenHIE v1.0 will do and (pretty quickly) build out a version of the overall infrastructure that “does that”.
This PPT deck is designed to move some of that discussion forward by unpacking what we would need, in terms of IHE profiles, to “do” the core processes that RHIE does today. This isn’t by any means a definitive design – there are still quite a few options for how we might leverage one profile or another. But I think this collection of profiles would probably “work”… and that’s a likable thing about any design…
This document needs the group’s “help”; I look forward to the conversations we will have on this topic.
Warmest regards,
Derek.
–
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
