Hi all. My sense is that we are well-served to keep in mind the interoperability mandate. Some of what we’re treating as our engineering constraints apply to our desire to be able to plug-and-play with standards-based components above the HIM. Ryan’s desire to treat the SHR as a black box reflects this. Our greatest challenge, however, is to be able to light up interoperability below the HIM; that’s where the tens of thousands of POSs are (hundreds of thousands or even millions, if we start to consider individuals’ mobile devices). For this reason, I think we need to think of exposing POS-facing functionality in terms of standards-based, conformance-testable interfaces that a broad range of commercial and open source applications can readily use/consume. I think, for the near term anyway, this might mean we focus on exposing discrete data using existing balloted interfaces – and for IHE, that means QED and CM (or those are the only ones I know about, anyway).
I know this next point sounds obvious – but we also need to ensure that our technology is able to do something important. On the one hand, as with any IT project, we need to keep a firm grip on scope creep – and I see this aspect being well focused upon. That said, if the functionality we’re implementing doesn’t yet do something that impacts health then we run the risk of chalking up technology successes that are not tied to health benefits. As an open-ended question, it is perhaps helpful to engage with our care delivery colleagues to help map out the minimum functionality we need to deploy for it to “matter” to the health of our served populations. This is, after all, the very core of our mission and vision.
As a note of interest – IHE’s next work item round has just opened. We have until mid-September to propose new profile or white paper projects to IHE committees; these will then be subject to IHE’s “work intake” ballot process starting in October. We can always propose change proposals (CPs) on existing profiles – and we should be continuously mindful of ways we can provide feedback to IHE re: the kinds of use cases and the technical issues we are seeing in our deployment environments. If we have engineering improvements to these profiles, there are about a half dozen of our OpenHIE organizations that can bring these to the appropriate IHE committee for ballot.
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: Friday, July 11, 2014 10:52 AM
To: Hannes Venter
Cc: Scott Teesdale; openhie-shr@googlegroups.com
Subject: Re: Specifying what a SHR does
I have been trying to look at the SHR as a black box as to not imply implementation, in that case it doesn’t make sense to process discrete data until we are planning to use it. However, you are right there are some additional tasks where discrete data is needed that we haven’t decided on yet.
I’m not a huge fan of the complexity increase from phase 0 to phase 1. Its quite a large increase, so finding a way to split QED out to a different phase would be ideal. I’m not really sure what the best option is here. Do others have better ideas?
Cheers,
Ryan
On Fri, Jul 11, 2014 at 4:40 PM, Hannes Venter hannes@jembi.org wrote:
Ok sure thanks Ryan.
Maybe it’s just isn’t too clear to me yet; but do we expect to only work with the discrete data via QED?
Well what I had in my head when thinking about implementing the “understanding”-bit before QED was that the discrete data would still be important,
e.g. the aggregating data flow for the data warehouse, which I assume wouldn’t depend on qed.
But yeah, no it certainly makes sense that we need to be able to use the data and we should be explicit about how in the document.
So if qed is the best way at phase 1, then it sounds good to me.
Cheers
Hannes
On 11 July 2014 15:59, Ryan Crichton ryan@jembi.org wrote:
@Hannes, thanks, that makes sense. I’m just wondering about moving QED to phase 2. If we do that then I don’t really see a benefit for understanding a PCC content profile. What will it do over an above a ‘blob-storing’ XDS.b registry and repository. Understanding the data has no meaning if we cannot query for that data. Maybe I am missing something though. The other changes I like, I’l update the wiki.
@Scott, thanks, those are some important points to consider. We already have a defined a number of requirements for the SHR and we have designed how the SHR should interact with the OpenHIE workflows. What we are trying to do here is more in the light of what we know a SHR should do then how can we specify this concretely so it is reapply-able for others to build their own SHR.
Cheers,
Ryan
On Fri, Jul 11, 2014 at 3:31 PM, Scott Teesdale steesdale@instedd.org wrote:
Hi All,
Justin and I briefly discussed this yesterday, so I thought I would pass this along to you guys too. In the FR community, we had broken out this question into the follow areas… just notional but this is where we are starting. Perhaps it will be helpful to promote discussion in your community.
What is an OHIE Facility Registry
- Capable: Implementing recurrently observed requirements
- We have a list of requirements or user stories generated across countries. Many of these are common/repeating and indicate the base functionality expected by countries around there master facility lists / facility registry. This also helps to promote our process, e.g., requirements based / country driven approach and the sustainability of that component.
-
Sustainable: Supported by MOH: Local ownership & capacity
-
Interoperable: Implements/supports OHIE APIs & Workflows
If something about our direction strikes you good or bad, I would be interested to get that feedback too. It is of course an ongoing iterative process from our perspective.
Best,
Scott
On Fri, Jul 11, 2014 at 9:12 AM, Hannes Venter hannes@jembi.org wrote:
Thanks Ryan, this makes a really good starting point. I really like the “phases” approach.
So far I just want to suggest the following:
- For phase 0 we just support XDS.b (this means a phase 0 SHR is just “blob-accepting” XDS.b repo/registry).
This would mean that any existing XDS.b implementations qualify at phase 0.
- We move QED to phase 2, leaving phase 1 as the minimal PCC stage.
So at a high-level the “degree of interoperability” would be
Phase 0 - XDS: can handle documents
Phase 1 - Minimal PCC: can understand those documents and support a basic maternal flow (history and summary)
Phase 2 - QED: can perform specific queries on the “understood” discrete data
Phase 3 - Expanded PCC: can understand more types.
I also just added in APS in at phase 1 on the wiki as another suggestion.
Thanks
Hannes
On 11 July 2014 12:48, Ryan Crichton ryan@jembi.org wrote:
Hi all,
On the previous call we discussed that we need to clearly specify what an OpenHIE SHR is and what it should do. I started to work on a wiki page to help describe this. This should be independent of the actual implementation of a SHR and just look at the general things an SHR should do.
Here is the link: What consitutes an OpenHIE SHR?
Please can you all read through this and comment on it. Also, feel free to go in a change any of this if you feel its not correct, this is just a stickman so that we may discuss this further. Some of the assumptions I have just made up, so feel free to call those assumptions out.
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/d/optout.
–
Hannes Venter
Senior 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/d/optout.
–
Scott Teesdale
Project Manager - InSTEDD
Email: steesdale@instedd.org
Skype: scott.teesdale
Social: Twitter / LinkedIn
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
Hannes Venter
Senior 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
–
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/d/optout.