Point of Service engagements with the HIE

[Carl Fourie]

Hi Craig

Thanks for raising the Point of service applications connecting to the OpenHIE. I know that this is something that a few of the team members have been talking about. @Ryan C: I know you have had a few ideas around this too as well as Derek Ritz (cc'd here). @Pierre Dane: you shared previously some of the work you've been thinking about with Asynchronous data exchange - would you mind sharing your thoughts around this here too?

The concept of offline caching is something to think about, I wonder how many implementations or potential implementations are considering this question at this stage?

WRT to the mapping aspect I'm curious as to what this mapping would look like? Do you have an example or a format that you could share?

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems |  SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Mon, May 16, 2016 at 6:08 AM, Craig A <ca...@grameenfoundation.org> wrote:

Hi Carl,

I'll answer the questions inline

On Thursday, May 12, 2016 at 12:32:06 AM UTC-7, carl wrote:

Hi Craig

Great to have you weighing in here.

I think you have a good point here about the different types of implementers - are you looking at this from a technical level of those who need to "wire up" the tools primarily or a more holistic approach as from "what governance and agreements do we need in place to implement a central HIE"? I think there is definitely scope for us to understand what both groups would be looking to get from OpenHIE and what information they would find most useful.

Craig: Many point of service systems aren't setup to interact with a live HIE and there will need to be significant technical development to integrate new HIE workflows in these Point of Service Systems. For example, it would be great if OpenMRS could query OpenHIE when a new patient is being registered to see if there is an existing registration in the HIE. This would require some type of hook in their registration app that does the query. But what happens when there's no internet connection? What workflows do implementers need to perform on their systems to accommodate the HIE? Do we need to cache data for offline use?

Additionally, the OpenHIE 1.0 workflows require a point of service system to speak a number of IHE standards like PDQ and XDS. It would be really good to map human workflows like "register patient" "Provider Encounter" etc. to these standards to it's easy for an implementer to evaluate the technical merit of an existing system they're planning to adopt. This could also inform gaps in the OpenHIM mediators, or represent a clear use case for implementing MOTECH between the POS system and OpenHIM.

On Wed, May 11, 2016 at 7:39 PM, Craig A <ca...@grameenfoundation.org> wrote:

Hi Carl,

I have a few items for group discussion:

- I feel that there are two distinct groups of implementers. The first focuses on implementing the OpenHIE infrastructure (everything above OpenHIM). The second group focuses on implementing to integrate the point of service with OpenHIM. This second group includes finding benefit from OpenHIE from point of service systems like OpenMRS, CommCare, ODK, etc.

​​

Sincerely,

Craig

On Tuesday, May 10, 2016 at 11:22:20 PM UTC-7, carl wrote:

Good day all

As our introductions start kicking up it is a good time to start asking some questions of the growing network. The first is:

"What are we missing?" - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions

There is a page on the wiki - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions with some initial ideas and we would encourage the network to discuss these here on the list and make suggestions.

Looking forward to the feedback (here and wiki)

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems |  SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implement...@googlegroups.com.
To post to this group, send email to ohie-imp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/7eac3f08-3ead-4303-b6aa-101263cbecc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implement...@googlegroups.com.
To post to this group, send email to ohie-imp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/a62ed55a-0e2e-4f0f-bfda-58bcaeec208f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ryan Crichton]

Hi Carl,

Thanks for splitting this out. I definitely think that having a reference PoC application would help implementers understand what OHIE can provide as well as ensuring that we keep the clinical workflow goals of OHIE in the front of our minds while developing the workflows.

Unfortunately, many of the potential implementers of OHIE are put off when we only have web services to point them at when testing an OHIE reference implementation in a lab environment. Being able to show something close to the clinical reality would be much more demonstrative and would provide a base to start off if an implementation so wishes.

Cheers,

Ryan

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjcY-Od3hcYSbrLX%3DyfKLNrOo1xNAduwkR_NQMWBm8VAQ%40mail.gmail.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: ry...@jembi.org

[Carl Fourie]

Just re-sending this to the Group as Derek's email has bounced.

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems |  SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Fri, May 20, 2016 at 3:28 PM, Derek Ritz <derek...@ecgroupinc.com> wrote:

Hi all.

At the AeHIN general meeting and conference in Bali last October we did a live demonstration in one of the plenary sessions. This demo was a short 3-act play that illustrated: maternal care with PMTCT, child immunization, and malaria care. For each of these 3 scenarios, we had point of service applications (OpenMRS, RapidPro's mHealth platform, OSCAR, the GIIS immunization registry, the MEDIC form scanner application, DHIS2) playing their care delivery / system management roles with OpenHIE managing the message traffic between them to support care continuity. At the front, we had the MEDIC lab's "visualizer" so that plenary attendees could literally watch the transaction traffic as it traversed the HIE on it's orchestrated path.

I can say, unequivocally, that being able to show the plenary attendees how the health information exchanged "works", from the perspective of the care providers, was very powerful. There was a collective a-ha moment when everyone was able to "connect the dots into a picture" and the power of health information sharing was obvious and its value was easily recognized.

To do this demo, we had assistance onsite from members the MEDIC lab team (Justin and Duane), from AIRIS solutions (Dori and Klaidi) and from DHIS2's Vietnam dev office (John). The entire software stack that we used is in the hands of AeHIN's new COIL lab. A PPT deck is attached that describes the workflows and the underlying transactions that made it "go". (A link to this deck has been included in the minutes of a number of OpenHIE community meetings; a PDF of it can be found at the AeHIN Hingx site, here: https://aehin.hingx.org/4thGMLiveDemo).

My sense is that we can, and should, build on this work as a running start. It will also give us an immediate collaboration opportunity with the new AeHIN lab. :-)

Warmest regards,

Derek.

--

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

[Craig A]

Thanks Derek,

This slide deck was really helpful. One challenge I'd like to discuss is the assumption of the capabilities of the PoC system to speak IHE standards. The v1.0 workflows assume that the PoC system can communicate PIX, PDQ, XDS.b, CDA, etc. A PoC system developer has the following options when trying to communicate with OpenHIE:

1) Build the capability to speak the standards to achieve integration

2) Build an OpenHIM mediator to translate outgoing API posts to standardized messages

3) Use a system between the PoC system and OpenHIM that mediates the movement between non-standard and standardized information.

Each PoC implementer will need to identify the lowest barrier of entry from the these. I think it would be good to document some of the benefits and limitations of each of these options.

I have been positioning our MOTECH platform to act as #3. There are instances when we need to act on trigger events within the PoC system and there is nightly syncing and maintenance that needs to be performed between the PoC and HIE. I hope to document that workflows as part of this implementers group.

Some questions moving forward:

- Do these three seem reasonable? Are there further options that I'm missing?

- Does this seem like a worthwhile exercise (identifying benefits/limitations and documenting when trigger events and syncing should be done)?

Craig

--

Ryan Crichton

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: r...@jembi.org

[Derek Ritz (ecGroup)]

Hi Craig.

 

The 3 options you outline seem reasonable to me. Option 1 is for a POS system to natively speak the standards-based interface. What is powerful is the fact that any applications that already do speak these can connect to the HIE without needing any modification at all. This was the case, for example, for the open source OSCAR EMR (https://oscar-emr.com/). It connected to OpenHIE with zero code mods.

 

Options 2 and 3 are both façade pattern approaches. In one case, the façade is on the IL… in the other the façade is a hosted 3^rd party service. To be honest, the façade could also be local to the application and this application is actually quite powerful, too. Many of the open source frameworks (e.g. EVEREST, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html) could be thought of as local façade applications that abstract the standards-based interfaces on behalf of the developer.

 

I will be interested to learn more about how you plan to position MOTECH. That sounds very cool. :-)

 

Warmest regards,

 

Derek.

 

 

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

 

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/6a456fec-4c8c-40f4-beba-d983296505a6%40googlegroups.com.

[Craig A]

Hi Derek,

Hi Derek,

Thanks for your message. Our team is squarely focused on supporting systems that interact with last mile populations. From my experience, there are a number of mobile platforms and clinic based systems that will be late adopters of IHE standards. For these systems, the facade pattern approaches seem most appropriate because they reduce the burden on each system. I see the recent adoption of PDQm and other FHIR standards as reducing that barrier and we're currently specing features for MOTECH that could work to adapt those.

As I mentioned in my previous message, I'm working on documentation that identifies where MOTECH fits into OpenHIE. The first part of that is defining a Point of Service implementers perspective and identifying how that differs from an OpenHIE implementer. I created this draft document on the wiki for member review. It would be great to get your feedback on the page, or to directly edit it. 

Sincerely,

Craig

[Scott Teesdale]

Hi Craig and Others,  

Thanks for getting this wiki page started for the point-of-service.  I added a few comments; focusing on the principles and I also am suggesting we lead with the value proposition for POS tools . Would love to hear what you and others think.  

Best,

Scott