As we are becoming more and more aware the OpenHIE Sandbox Community has undergone a revamp to the DevOps Community. This is to better reflect the goals of:
Validating connectivity and interoperabilty of tools
Showcasing OpenHIE in Action
Supporting implementers in getting started with OpenHIE etc
So with that said there is a question that I have to ask: What would make OpenHIE easier to implement for yourselves?
Some ideas that have popped up are: packaging - making OHIE easier to deploy; Reference application - is there a “vanilla” OpenHIE that I can tweak to get started? ; mediators and adaptors - I need to easily connect OpenMRS, <> to a particular service (MPI) in OpenHIE; mobile tool integrations.
I hope the theme is coming through, the DevOps community is looking for priority areas of work where we can focus that makes OpenHIE easier to enage with.
Looking forward to hearing your inputs and ideas! Be creative and dream big!
···
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
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.
Thanks for raising this. I think we should also have some tools that we can show off that solve common problem implementations face. For example the most obvious to me is enabling automatic retires of requests to OpenHIE services when there are connection issues/outages. Another would be having reference implementation/tooling for connecting to common key partner platforms like OpenMRS.
Just some thoughts.
Cheers,
Ryan
···
On Wed, Oct 5, 2016 at 9:18 AM Carl Fourie carl@jembi.org wrote:
Hi All
As we are becoming more and more aware the OpenHIE Sandbox Community has undergone a revamp to the DevOps Community. This is to better reflect the goals of:
Validating connectivity and interoperabilty of tools
Showcasing OpenHIE in Action
Supporting implementers in getting started with OpenHIE etc
So with that said there is a question that I have to ask: What would make OpenHIE easier to implement for yourselves?
Some ideas that have popped up are: packaging - making OHIE easier to deploy; Reference application - is there a “vanilla” OpenHIE that I can tweak to get started? ; mediators and adaptors - I need to easily connect OpenMRS, <> to a particular service (MPI) in OpenHIE; mobile tool integrations.
I hope the theme is coming through, the DevOps community is looking for priority areas of work where we can focus that makes OpenHIE easier to enage with.
Looking forward to hearing your inputs and ideas! Be creative and dream big!
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
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.
A similar workflow could apply where we are looking at aggregating data from a POS or SHR.
This hasn’t been stood up yet, but I think would be worth the effort.
Cheers,
-carl
···
On Oct 6, 2016, at 3:05 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Carl,
Thanks for raising this. I think we should also have some tools that we can show off that solve common problem implementations face. For example the most obvious to me is enabling automatic retires of requests to OpenHIE services when there are connection issues/outages. Another would be having reference implementation/tooling for connecting to common key partner platforms like OpenMRS.
Just some thoughts.
Cheers,
Ryan
On Wed, Oct 5, 2016 at 9:18 AM Carl Fourie carl@jembi.org wrote:
Hi All
As we are becoming more and more aware the OpenHIE Sandbox Community has undergone a revamp to the DevOps Community. This is to better reflect the goals of:
Validating connectivity and interoperabilty of tools
Showcasing OpenHIE in Action
Supporting implementers in getting started with OpenHIE etc
So with that said there is a question that I have to ask: What would make OpenHIE easier to implement for yourselves?
Some ideas that have popped up are: packaging - making OHIE easier to deploy; Reference application - is there a “vanilla” OpenHIE that I can tweak to get started? ; mediators and adaptors - I need to easily connect OpenMRS, <> to a particular service (MPI) in OpenHIE; mobile tool integrations.
I hope the theme is coming through, the DevOps community is looking for priority areas of work where we can focus that makes OpenHIE easier to enage with.
Looking forward to hearing your inputs and ideas! Be creative and dream big!
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
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.
A similar workflow could apply where we are looking at aggregating data from a POS or SHR.
This hasn’t been stood up yet, but I think would be worth the effort.
Cheers,
-carl
On Oct 6, 2016, at 3:05 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Carl,
Thanks for raising this. I think we should also have some tools that we can show off that solve common problem implementations face. For example the most obvious to me is enabling automatic retires of requests to OpenHIE services when there are connection issues/outages. Another would be having reference implementation/tooling for connecting to common key partner platforms like OpenMRS.
Just some thoughts.
Cheers,
Ryan
On Wed, Oct 5, 2016 at 9:18 AM Carl Fourie carl@jembi.org wrote:
Hi All
As we are becoming more and more aware the OpenHIE Sandbox Community has undergone a revamp to the DevOps Community. This is to better reflect the goals of:
Validating connectivity and interoperabilty of tools
Showcasing OpenHIE in Action
Supporting implementers in getting started with OpenHIE etc
So with that said there is a question that I have to ask: What would make OpenHIE easier to implement for yourselves?
Some ideas that have popped up are: packaging - making OHIE easier to deploy; Reference application - is there a “vanilla” OpenHIE that I can tweak to get started? ; mediators and adaptors - I need to easily connect OpenMRS, <> to a particular service (MPI) in OpenHIE; mobile tool integrations.
I hope the theme is coming through, the DevOps community is looking for priority areas of work where we can focus that makes OpenHIE easier to enage with.
Looking forward to hearing your inputs and ideas! Be creative and dream big!
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
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.
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
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.