IOL Value Proposition Discussion and Contributions

[Tariro Mandevani]

Dear All 

In the previous IOL meeting on the 22nd of May 2018, the community discussed the need for a Value Proposition for IOL.  It was agreed by the community that a google document should be created to share thoughts and content. 

Please find a link to the google document for your contributions:  https://docs.google.com/document/d/15xwLqugbw2mmasCHkmDUcgonnl0D3Xo9lBjEcKj9kFA/edit

The content will be reviewed in our next community call dated 19 June 2018.

Thanking you.

Regards

Tariro Mandevani

Project Officer|Jembi Health Systems|South Africa

Cape Town Office: 

Tel: +27(0)21 701 0939

Skype: tariro.mandevani2

Email: tariro.m...@jembi.org

[Tariro Mandevani]

Dear All 

Recognizing your very busy schedule, I’m sending you this note as a reminder to share your thoughts and contribute to the Value Proposition for IOL. Please use the following link to add your contribution:

​

 https://docs.google.com/document/d/15xwLqugbw2mmasCHkmDUcgonnl0D3Xo9lBjEcKj9kFA/edit

We value your contributions. 

Thank you

Regards

Tariro Mandevani

Project Officer|Jembi Health Systems|South Africa

Cape Town Office: 

Tel: +27(0)21 701 0939

Skype: tariro.mandevani2

Email: tariro.m...@jembi.org

[Tony Shannon]

thanks Tariro,

I had asked a question on the document which I thought was needed to guide this discussion paper.

Key question please;

Is the mission of openHIE to; (?)

Grow the community around a platform of interchangeable open source components that will transform healthcare

OR 

Grow the community around a set of open standards that will transform healthcare?

IMHO that is somewhat unclear to me at this point in time , yet is  central to the value proposition of openHIE

Hope that helps

Tony

Dr. Tony Shannon

Director, Ripple Foundation   ripple.foundation

Director, Apperta Foundation apperta.org

tony.s...@ripple.foundation

+44.789.988.5068 (UK)

+353.89.457.6011 (Ireland)

--
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.

[Carl Fourie]

Hi Tony

I think your question is a little beyond the scope of what the document is looking to elicit. In the document, we are looking to lift out the boilerplate text of why on a conceptual and architectural component level (not for a pariticular tool) do we believe there is value in having an interoperability layer to mediate and facilitate health information exchange?

To the broader question of "OpenHIE Mission," I look at it more as aligned to the latter point -- OpenHIE is firstly an architectural approach that highlights both the components (not the tools) and suggested data exchange patterns that are required for HIEs for low resource settings. To Derek's point in the doc, we also wanted to be able to point groups to reference tools that we believe(d) carried the core functionality of the components within the Architecture. OpenHIE has been very focused (sometimes to our own detriment) to point out that we are not a technology stack (or my term, an "OpenHIE.exe") that is shrink wrapped and ready to go -- doing this would be an interesting and possibly difficult conversation to have when other tools stand up and say "hey I do that, why didn't you select me?" and or may create the message that we are 100% open or not at all. As such OpenHIE is firstly an architecture that has given countries a common language and framework to communicate and bring peers together to talk about; it has highlighted the availability of international standards to support data exchange and still promotes a context-aware selection of them and then tries to maintain options of tools that could be seen as reference technologies.

With that stage set, I believe what we are trying to bring into this document is some thinking from those who've gone before us as to why we believe that deploying an IOL (whichever tool is selected) within your implementation is a good value proposition and also when to "not bother".

Hope that helps?

Carl Fourie

Senior Programmes Coordinator

Jembi Health Systems NPC | SOUTH AFRICA

Office: +27 21 701 0939 | Skype: carl.fourie17

E-mail: carl....@jembi.org

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 are not liable for the security of information sent by e-mail and accepts no liability whatsoever for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperabil...@googlegroups.com.

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

--
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-interoperabil...@googlegroups.com.

[Tony Shannon]

thanks Carl

Please forgive me if I'm coming at this from an unusual/unhelpful angle.

I think I get where you are coming from... I'll add a few more comments and then leave you craft the paper between you for now.

The case for an Interoperability Layer is a given/no-brainer/unavoidable/key aspect/central etc etc in all the work we do, so in all our projects within those implementations an IOL is always a very good value proposition.

... but I understand the point you're making about needing to make the case for others who may not have that perspective/be coming at this from a very different angle.

If openHIE is an "architectural approach"/"firstly an architecture" ..

In this part of the world we/I have seen many architectural approaches come and go and have little impact on the ground.

Case in point the latest Target Architecture for the NHS in England of 2017, see attached pdf from NHS England or here https://medconfidential.org/wp-content/uploads/2017/09/2017-07-13-Target-Architecture.pdf

The Enterprise Architect for the NHS England thinks that document represents a vision of a healthcare IT architecture, I'm afraid I do not.

Similar issues during NPfIT with the Zachman Framework https://en.wikipedia.org/wiki/Zachman_Framework and even my work with openEHR on the openEHR specification/architecture led me to the same conclusion...

IMHO any credible architecture/framework/standard needs an open source reference implementation to make it real and help others make a "value judgement" on its merits.

My sense is its the blend of architecture AND particularly your commitment to an open source reference implementation of that architecture, that sets openHIE apart, from anyone else doing this, on the planet (ie a unique value proposition).

https://wiki.ohie.org/display/documents/Reference+Technologies

I'll leave my comments there for now.. I hope those points are helpful in some way, i.e. I'm trying to commend and encourage the important openHIE effort.

(going on leave v shortly and happy to pick discussion back up on return)

Kind regards,

Tony

Dr. Tony Shannon

Director, Ripple Foundation   ripple.foundation

Director, Apperta Foundation apperta.org

tony.s...@ripple.foundation

+44.789.988.5068 (UK)

+353.89.457.6011 (Ireland)

On 13 June 2018 at 09:57, Carl Fourie <carl....@jembi.org> wrote:

Hi Tony

I think your question is a little beyond the scope of what the document is looking to elicit. In the document, we are looking to lift out the boilerplate text of why on a conceptual and architectural component level (not for a pariticular tool) do we believe there is value in having an interoperability layer to mediate and facilitate health information exchange?

To the broader question of "OpenHIE Mission," I look at it more as aligned to the latter point -- OpenHIE is firstly an architectural approach that highlights both the components (not the tools) and suggested data exchange patterns that are required for HIEs for low resource settings. To Derek's point in the doc, we also wanted to be able to point groups to reference tools that we believe(d) carried the core functionality of the components within the Architecture. OpenHIE has been very focused (sometimes to our own detriment) to point out that we are not a technology stack (or my term, an "OpenHIE.exe") that is shrink wrapped and ready to go -- doing this would be an interesting and possibly difficult conversation to have when other tools stand up and say "hey I do that, why didn't you select me?" and or may create the message that we are 100% open or not at all. As such OpenHIE is firstly an architecture that has given countries a common language and framework to communicate and bring peers together to talk about; it has highlighted the availability of international standards to support data exchange and still promotes a context-aware selection of them and then tries to maintain options of tools that could be seen as reference technologies.

With that stage set, I believe what we are trying to bring into this document is some thinking from those who've gone before us as to why we believe that deploying an IOL (whichever tool is selected) within your implementation is a good value proposition and also when to "not bother".

Hope that helps?

Carl Fourie

Senior Programmes Coordinator

Jembi Health Systems NPC | SOUTH AFRICA

Office: +27 21 701 0939 | Skype: carl.fourie17

E-mail: carl....@jembi.org

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 are not liable for the security of information sent by e-mail and accepts no liability whatsoever for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

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.

--
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.

[Derek Ritz]

Hi Tony. 

The architecture part gives us a way to decouple product from "role". The US CONNECT platform, for example, could play the role of the Interoperability Layer. So could the OpenHIM product. Both operationalize the same standards and behaviors. 

Hope this helps. 

Warmest regards, 

Derek 

Sent from my mobile phone
+1(905)515-0045

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperabil...@googlegroups.com.

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

--
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-interoperabil...@googlegroups.com.

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

--
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-interoperabil...@googlegroups.com.

[Tony Shannon]

thanks Derek

I get the idea of course, its the right idea, and I trust that both US Connect and openHIM could play that IOL role.

FYI There is a most interesting project you may/may not have seen that is a showcase of compatible open source frontends + backends that I think healthcare has something to learn from.

https://github.com/gothinkster/realworld

"See how the exact same Medium.com clone (called Conduit) is built using any of our supported frontends and backends. Yes, you can mix and match them, because they all adhere to the same API spec"

Its obviously a trivial example compared to the scope that the openHIE mission is addressing, yet I cant help thinking that in time to come developers of the future will be able to pick up a set pf components to spin up a version of openHIE.

Its a nice mix of open source components & open standards in action... again something we can learn from I think.

regards for now

Tony

On 13 June 2018 at 14:56, Derek Ritz <derek...@ecgroupinc.com> wrote:

Hi Tony. 

The architecture part gives us a way to decouple product from "role". The US CONNECT platform, for example, could play the role of the Interoperability Layer. So could the OpenHIM product. Both operationalize the same standards and behaviors. 

Hope this helps. 

Warmest regards, 

Derek 

Sent from my mobile phone
+1(905)515-0045

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.

--
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.

--
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.

[Derek Ritz]

Tony – I completely agree with you!

And to be honest, we kinda have done this with various OpenHIE iterations. We’ve been able to plug in either OpenEMPI or MEDIC CR to play the role of the client registry… and since both supported the PIX/PDQ profile, all we have to change on the OpenHIM side is the IP address (and the trusted PKI certificate). Likewise, at a Connectathon a few years ago, both DHIS2 and Resource Mapper were able to play the role of underlying Facility Directory to the OpenInfoMan (the interlinked registry). These solutions were completely interchangeable because they both supported the IHE CSD spec.

We have some miles to travel yet, but who knows… some future OpenHIE “demo version” might be built at runtime by selecting the IOL, and then selecting the components that should plug into the IOL to operationalize the HIE. How wicked cool would that be?!

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 unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperabil...@googlegroups.com.

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

--
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-interoperabil...@googlegroups.com.

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

--
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-interoperabil...@googlegroups.com.

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

--
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-interoperabil...@googlegroups.com.

[Tony Shannon]

thanks Derek

That would be super  cool indeed.

If you could point us to anything that we could consider aiming our QEWDjs tool at, as a swappable component for the IOL layer, that would greatly help us explore how our whole stack could begin to align with the openHIE effort.

Ideally an open source "openHIE instance" we could spin up would allow us to experiment towards that end goal.

Not sure such a thing exists and it wouldnt be a trivial activity, but would help move us all towards..

realworldhealthcare.io :o)

Heading on leave shortly, happy to come back to this type of discussion another time.

Best wishes for your forthcoming event

Tony

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.

--
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.

--
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.

--
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.