What would make OHIE easier to adopt

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.

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.

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/CAFNRjWjX4xNpwuvTUEzw-f0v294j4dYdE_%3Dr86EWPGJeWsVxeQ%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: ryan@jembi.org

I would also think about aggregate data reporting to an HMIS with a TS as an intermediary to handle indicator mapping, would be a common use case. This is outlined here for # of HWs -> HMIS:
https://wiki.ohie.org/display/documents/Provide+Aggregate+Health+Worker+Information+Statistics

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.

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/CAFNRjWjX4xNpwuvTUEzw-f0v294j4dYdE_%3Dr86EWPGJeWsVxeQ%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: ryan@jembi.org

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/CABh-%2BTJgGVv_ZnR%3DuFWR77HWZAwy%2B4Ujp0LxAH2ZNzYvOXNB1Q%40mail.gmail.com.

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

Thanks all, started listing them here: https://wiki.ohie.org/display/SUB/OpenHIE+Implementers

Are there others?

···

On Thu, Oct 6, 2016 at 4:14 PM, Carl Leitner litlfred@gmail.com wrote:

I would also think about aggregate data reporting to an HMIS with a TS as an intermediary to handle indicator mapping, would be a common use case. This is outlined here for # of HWs -> HMIS:
https://wiki.ohie.org/display/documents/Provide+Aggregate+Health+Worker+Information+Statistics

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.

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/CAFNRjWjX4xNpwuvTUEzw-f0v294j4dYdE_%3Dr86EWPGJeWsVxeQ%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: ryan@jembi.org

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/CABh-%2BTJgGVv_ZnR%3DuFWR77HWZAwy%2B4Ujp0LxAH2ZNzYvOXNB1Q%40mail.gmail.com.

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

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.