Contribution request for OpenIOL & SHR topics not discussed today

tariro.mandevani · September 19, 2017, 3:14pm

Dear All

As we have run out of time without discussing the 2 point below. Please feel free to send your contribution via email.

Discussion on IHE Connectathon
Automated Testing

Thanks

···

Regards
Tariro Mandevani

Project Officer|Jembi Health Systems|South Africa

Cape Town Office:

Tel: +27(0)21 701 0939

Skype: tariro.mandevani2

Email: tariro.mandevani@jembi.org

dritz · September 19, 2017, 4:16pm

Hi all.

I am an advocate for having our OpenHIE reference software participate in IHE Connectathon testing. As a top-level message, it demonstrates the importance of “interoperability” to the implementing communities (MOHs) we serve. Ideally, we want MOHs to expect that any products they implement in their jurisdictions should be demonstrably interoperable using international digital health standards. Of course, at a more basic level, the act of participating in Connectathon also ensures our reference products do strictly adhere to the profiles to which we claim conformance. This “eating our own cooking” aspect is also valuable.

As a reference product, OpenHIM is a foundational infrastructure element for OpenHIE. From the point of view of the outside world, it impersonates every element in the OpenHIE architecture. The testing burden on OpenHIM is therefore very tall. Because of OpenHIE’s architecture design, OpenHIM has to be able to do “both sides” of all of our workflow-spec’d profiles (e.g. PIX, PDQ, PIXm, PDQm, CSD, mCSD, XDS.b, MHD, ADX). It also can’t pass any test without being partnered with the appropriate underlying component. I’m pointing all of this out because it speaks to the resources we’ll need in order to have OpenHIM pass all its necessary tests at a CAT. We’ll need a team of at least 3 engineers, IMHO, to be able to just get all the tests done during the allotted 5 days.

Re: SHR reference components, I think it is important for us to decide as an OpenHIE community if we’re abandoning support for XDS.b or not. Certainly, if we’re testing the HEARTH, we are testing MHD alone. One of our challenges is that there are a number of CDA-based content profiles that OpenHIE has adopted and which our reference SHR (OpenSHR) has been tested against. These content profiles are connected to real-world workflows (e.g. ANC encounters; vaccination events, etc.). We have not, as a community, come to consensus regarding FHIR profiles that are functionally equivalent to the XDS.b/CDA profiles that are denoted, today, in our workflows. This is problematic because an MOH-level decision-maker doesn’t care what protocols we’re using on the wire… they care about what it is that the infrastructure can do. We have work to undertake in our Architecture community; we shouldn’t (I don’t think) abandon workflows until we have new ones that do that same functionally-equivalent thing. I’m raising this because I think any CAT testing plan of our SHR should identify the content profiles… not just the message envelope profile. (e.g. https://www.hl7.org/fhir/immunization.html).

I’m sorry this is a long post. Thank you to any readers who are still hanging in and have read this far. Here is what I think are the implications of the preceding blah blah blah:

···

We should probably expect to disaggregate our components and test specific isolated profiles rather than trying to test “OpenHIE” and the full scope of what the architecture does. Pragmatically… I just don’t think we’ll be able to coordinate ourselves and resource for accomplishing the latter (much as I wish we could). A focus on mCSD, CSD, and ADX seems doable to me.
We should consider splitting our participation across both the US and EU Connectathons. It seems mCSD and CSD’s “centre of gravity” prefers testing at the US CAT while ADX’s prefers the EU CAT.
We know we can get scholarships for participation in the US CAT. We need to definitely establish the same is true for the EU CAT. If we cannot… and we must pay registration fees… it likely makes the case for testing all profiles at the US CAT.
OpenHIM’s participation on these workflows is as a pass-thru. That said… the IOL is a fundamental puzzle piece to OpenHIE’s architecture and I think it should be tested in these workflows as both a creator and a consumer.

Time is short. The deadline for US CAT registration closes October 6, 2017. I hope we can have an active discussion on this topic and inform our OpenHIE leadership with a consensus view in short order.

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.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Tariro Mandevani
Sent: September 19, 2017 11:15 AM
To: Openhie-interoperability-layer@googlegroups.com; openhie-shr@googlegroups.com
Subject: Contribution request for OpenIOL & SHR topics not discussed today