Hi all
I thought I’d drop a line to the community / network at the end of the week to kick off your “weekend brains” and get some thoughts and ideas/input back. One one of the other mailing lists we had a question around the topic of (and excuse me for paraphrasing poorly if I do) "Does OpenHIE just support Open Source tools? What if there is a non-open/propriatory tool that is needing or wanting to be used? Is it only OpenHIE if we use the technologies that are listed as reference technologies on the OpenHIE websites/wiki?"
I think this is something that is great to clarify and make sure we are all “thinking along the same lines”. Short answer: It doesn’t have to be open source to be OpenHIE 
… now for those who want to read a bit more …
This comes down to OpenHIE being first and foremost an architectural approach to health information exchanges as well as its mission of serving in the underserved. To me the “Open” in OpenHIE really referes to the “Architecture”. To me that means, you are open to engage and play the roles and functions of any of the architectural components regardless of your software license etc.
There are many reasons to select a particular solution to play one or many of the architectural components of OpenHIE and I’m sure we could discuss those (not a bad idea) to a good degree. But I’d like to hear from teh community:
"Have you/your organization used/planning to/considering to use technologies that are not Open Source or not one of the reference technologies in your current implementation?" If so would you be open to share what it is and how you see it fitting into your architecture?
···
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.fourie@jembi.org
Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)
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.
Hi Carl,
Thanks for the question. I believe there will be n+1 responses to this with n = list of subscribers of this list. And it’s hard to judge who is more right or wrong.
I guess it all boils down to institutional vision, mission, and goals. For example, at the AeHIN Interoperability Lab (official name: Standards andand Interoperability Lab for Asia), we aim to understand interoperability at all levels (process, semantic, syntax, etc). In order to do this, we need transparency in all that we do and use. Ergo, using open source will be preferable.
Having said that, we also have business priorities. And if proprietary solutions will bring us faster to our goals without compromising our objectives then I see no problem with that.
Some examples:
Terminology service: Apelon and OCL are candidates. Our goal in the lab is to show how TS play a role in the larger OpenHIE framework. If both of them can do the job, our lab should know how to use either.
HMIS: DHIS2 and Tableau separately or together. Which is better for ministries? Labs should know both and gather test data and share.
Ultimately, we succeed or fail based on pre-set vision, mission, goals, and we become accountable to our stakeholders for it.
I hope OpenHIE will always be an open framework and for FOSS reference implementations to be always available. But proprietary solutions are welcome as long as they comply with the framework.
Alvin
···
On 24 Feb 2017 16:24, “Carl Fourie” carl@jembi.org wrote:
Hi all
I thought I’d drop a line to the community / network at the end of the week to kick off your “weekend brains” and get some thoughts and ideas/input back. One one of the other mailing lists we had a question around the topic of (and excuse me for paraphrasing poorly if I do) “Does OpenHIE just support Open Source tools? What if there is a non-open/propriatory tool that is needing or wanting to be used? Is it only OpenHIE if we use the technologies that are listed as reference technologies on the OpenHIE websites/wiki?”
I think this is something that is great to clarify and make sure we are all “thinking along the same lines”. Short answer: It doesn’t have to be open source to be OpenHIE 
… now for those who want to read a bit more …
This comes down to OpenHIE being first and foremost an architectural approach to health information exchanges as well as its mission of serving in the underserved. To me the “Open” in OpenHIE really referes to the “Architecture”. To me that means, you are open to engage and play the roles and functions of any of the architectural components regardless of your software license etc.
There are many reasons to select a particular solution to play one or many of the architectural components of OpenHIE and I’m sure we could discuss those (not a bad idea) to a good degree. But I’d like to hear from teh community:
“Have you/your organization used/planning to/considering to use technologies that are not Open Source or not one of the reference technologies in your current implementation?” If so would you be open to share what it is and how you see it fitting into your architecture?
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.fourie@jembi.org
Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)
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-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjMwL7b7LC9hTdT%3Dv%2BDjWpu_tZzDux5DOtJCeaUfuGVQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Hi Carl,
Thanks for your question. I believe that OpenHIE’s use of IHE profiles and open medical standards makes it easier for proprietary systems to interact with OpenHIE. We have a use case in Haiti where we need to push lab orders from local clinics to the national laboratory. We’re using OpenMRS in the clinics and the national lab is using SCC’s Softlab, which is a proprietary system that utilizes IHE lab profiles using medical standards. This integration will utilize a number of OpenHIE reference applications and workflows. We’re in the planning stages right now and expect to make all of these workflows available to the community so they can be used as an example and built upon.
I agree with your statement around the “open” architecture. Any technology can be used for any component of the HIE as long as they conform to the standards outlined in a particular OpenHIE workflow version.
I appreciate how the community and all information is freely available through the website, wiki and google groups. I have learned a great deal from this community over the past two years, which is directly linked to this openness.
Sincerely,
Craig
···
On Thursday, February 23, 2017 at 11:24:21 PM UTC-8, carl wrote:
Hi all
I thought I’d drop a line to the community / network at the end of the week to kick off your “weekend brains” and get some thoughts and ideas/input back. One one of the other mailing lists we had a question around the topic of (and excuse me for paraphrasing poorly if I do) “Does OpenHIE just support Open Source tools? What if there is a non-open/propriatory tool that is needing or wanting to be used? Is it only OpenHIE if we use the technologies that are listed as reference technologies on the OpenHIE websites/wiki?”
I think this is something that is great to clarify and make sure we are all “thinking along the same lines”. Short answer: It doesn’t have to be open source to be OpenHIE
… now for those who want to read a bit more …
This comes down to OpenHIE being first and foremost an architectural approach to health information exchanges as well as its mission of serving in the underserved. To me the “Open” in OpenHIE really referes to the “Architecture”. To me that means, you are open to engage and play the roles and functions of any of the architectural components regardless of your software license etc.
There are many reasons to select a particular solution to play one or many of the architectural components of OpenHIE and I’m sure we could discuss those (not a bad idea) to a good degree. But I’d like to hear from teh community:
“Have you/your organization used/planning to/considering to use technologies that are not Open Source or not one of the reference technologies in your current implementation?” If so would you be open to share what it is and how you see it fitting into your architecture?
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
Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)
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.