OpenHIE demo strategy: What's your opinion?

Suranga_Kasthurirat1 · March 9, 2016, 5:39pm

Hi all,

There has been some discussion on how OpenHIE as a community would like to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a great demo of how the Oscar system integrated with OpenHIE. Prior to that, I presented a separate demo POC app which was built from scratch (I.e. vendor neutral).

During the meeting, we decided to discuss a common path ahead, and a strategy of what we would like to see. To move this forward, i’d like to hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?

a. Help clinicians / implementers understand how the systems works

b. help implementers / devs understand how the interactions between components work

c. Load / performance / application testing

How do we want to position this?

a. The demo app should be a neutral system that demonstrates how you can built your own POC app

b. The demo app could be existing POC apps that are already used by OpenHIE

···

Best Regards,
Suranga

Carl_Fourie1 · March 10, 2016, 7:12am

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi) have been thinking about this quite a bit and for sometime. I think understanding fundamentally what we are trying to demonstrate is important. I pretext this with the fact that I wan’t on the calls and have seen the recordings. Suranga your POC demo seemed to focus on showing what OpenHIE could provide to the POC - it was very focused at showing that you could get information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within a more clinical use case and show how it is / can be leveraged by tools prevalent in the low resource settings environment within which we work. The Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing how OHIE supports care and means that we can show just how OHIE impacts health/clinical use cases. From our experiences in running the first demo back in 2010 at Medinfo (learning from Mohawks team and their experiences) I think the value that we had was that the tools that were shown could be related to in the field systems and the “story” could be told that highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would propose the following:

We need to have a sandbox which provides accessible data endpoints for each of our OHIE workflows (that we have I believe – btw I want to better understand why you think the IOL was the cause of the delay in your demo - can we have a look at this? in our implementations we aren’t seeing it responding that slowly and it is not a fair representation of the tool or OHIE if it is doing that on our sandbox environment – please reach out to us if this is the case we all need to succeed here). But more so we need to guide people in following an illustrative use case for them to understand how it all comes together. Right now you can maybe knock on OHIE to register and resolve a patient but if we really want to show it we should say to ppl if you consume XX endpoints you can see your system contributing to a particular use case (maternal care for example). Having the wiring there is one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.

My view is the app should rather show how OpenHIE is consumed by an existing application(s) (not a new build, but one that is for low resource settings if possible) in a particular workflow. We can focus on technical documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this way) as the implementer community comes to life as it will bring us down to “real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

···

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a great demo of how the Oscar system integrated with OpenHIE. Prior to that, I presented a separate demo POC app which was built from scratch (I.e. vendor neutral).

During the meeting, we decided to discuss a common path ahead, and a strategy of what we would like to see. To move this forward, i’d like to hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?

a. Help clinicians / implementers understand how the systems works

b. help implementers / devs understand how the interactions between components work

c. Load / performance / application testing

How do we want to position this?

a. The demo app should be a neutral system that demonstrates how you can built your own POC app

b. The demo app could be existing POC apps that are already used by OpenHIE

Best Regards,
Suranga

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

Regards
Carl Fourie
Senior Program Manager

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.

Suranga_Kasthurirat2 · March 12, 2016, 9:27pm

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the performance of the IOL. They were raised before, and the Ryan C + Hannes combination fixed that issue very promptly. I cant guarantee this, but I believe that the delay still exists because either the changes didn’t go into the OpenHIE 1.0 release that we’re testing, or for some other reason… But again, don’t take my word for this, I will re-check and confirm when folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how OpenHIE is consumed by an existing application(s) (not a new build, but one that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail once we hear more opinions

···

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi) have been thinking about this quite a bit and for sometime. I think understanding fundamentally what we are trying to demonstrate is important. I pretext this with the fact that I wan’t on the calls and have seen the recordings. Suranga your POC demo seemed to focus on showing what OpenHIE could provide to the POC - it was very focused at showing that you could get information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within a more clinical use case and show how it is / can be leveraged by tools prevalent in the low resource settings environment within which we work. The Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing how OHIE supports care and means that we can show just how OHIE impacts health/clinical use cases. From our experiences in running the first demo back in 2010 at Medinfo (learning from Mohawks team and their experiences) I think the value that we had was that the tools that were shown could be related to in the field systems and the “story” could be told that highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would propose the following:

We need to have a sandbox which provides accessible data endpoints for each of our OHIE workflows (that we have I believe – btw I want to better understand why you think the IOL was the cause of the delay in your demo - can we have a look at this? in our implementations we aren’t seeing it responding that slowly and it is not a fair representation of the tool or OHIE if it is doing that on our sandbox environment – please reach out to us if this is the case we all need to succeed here). But more so we need to guide people in following an illustrative use case for them to understand how it all comes together. Right now you can maybe knock on OHIE to register and resolve a patient but if we really want to show it we should say to ppl if you consume XX endpoints you can see your system contributing to a particular use case (maternal care for example). Having the wiring there is one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.

My view is the app should rather show how OpenHIE is consumed by an existing application(s) (not a new build, but one that is for low resource settings if possible) in a particular workflow. We can focus on technical documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this way) as the implementer community comes to life as it will bring us down to “real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

–

Regards
Carl Fourie
Senior Program Manager

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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a great demo of how the Oscar system integrated with OpenHIE. Prior to that, I presented a separate demo POC app which was built from scratch (I.e. vendor neutral).

During the meeting, we decided to discuss a common path ahead, and a strategy of what we would like to see. To move this forward, i’d like to hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?

a. Help clinicians / implementers understand how the systems works

b. help implementers / devs understand how the interactions between components work

c. Load / performance / application testing

How do we want to position this?

a. The demo app should be a neutral system that demonstrates how you can built your own POC app

b. The demo app could be existing POC apps that are already used by OpenHIE

Best Regards,
Suranga

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

Best Regards,
Suranga

Suranga_Kasthurirat2 · March 16, 2016, 6:15pm

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low level implementers who want to understand how the system works, and look at its underbelly (transactions, messages etc) and (b) high level implementers/ministry/officials etc. who want to understand the clinical relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching / training tool - something that can be used to visualize transactions / show folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the ones involving OSCAR and OpenMRS - tools that demonstrate clinical relevance, and working use cases, and can directly plug and play with OpenHIE.

What do people think?

···

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the performance of the IOL. They were raised before, and the Ryan C + Hannes combination fixed that issue very promptly. I cant guarantee this, but I believe that the delay still exists because either the changes didn’t go into the OpenHIE 1.0 release that we’re testing, or for some other reason… But again, don’t take my word for this, I will re-check and confirm when folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how OpenHIE is consumed by an existing application(s) (not a new build, but one that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail once we hear more opinions

–

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi) have been thinking about this quite a bit and for sometime. I think understanding fundamentally what we are trying to demonstrate is important. I pretext this with the fact that I wan’t on the calls and have seen the recordings. Suranga your POC demo seemed to focus on showing what OpenHIE could provide to the POC - it was very focused at showing that you could get information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within a more clinical use case and show how it is / can be leveraged by tools prevalent in the low resource settings environment within which we work. The Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing how OHIE supports care and means that we can show just how OHIE impacts health/clinical use cases. From our experiences in running the first demo back in 2010 at Medinfo (learning from Mohawks team and their experiences) I think the value that we had was that the tools that were shown could be related to in the field systems and the “story” could be told that highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would propose the following:

We need to have a sandbox which provides accessible data endpoints for each of our OHIE workflows (that we have I believe – btw I want to better understand why you think the IOL was the cause of the delay in your demo - can we have a look at this? in our implementations we aren’t seeing it responding that slowly and it is not a fair representation of the tool or OHIE if it is doing that on our sandbox environment – please reach out to us if this is the case we all need to succeed here). But more so we need to guide people in following an illustrative use case for them to understand how it all comes together. Right now you can maybe knock on OHIE to register and resolve a patient but if we really want to show it we should say to ppl if you consume XX endpoints you can see your system contributing to a particular use case (maternal care for example). Having the wiring there is one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.

My view is the app should rather show how OpenHIE is consumed by an existing application(s) (not a new build, but one that is for low resource settings if possible) in a particular workflow. We can focus on technical documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this way) as the implementer community comes to life as it will bring us down to “real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

Best Regards,
Suranga

–

Regards
Carl Fourie
Senior Program Manager

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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a great demo of how the Oscar system integrated with OpenHIE. Prior to that, I presented a separate demo POC app which was built from scratch (I.e. vendor neutral).

During the meeting, we decided to discuss a common path ahead, and a strategy of what we would like to see. To move this forward, i’d like to hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?

a. Help clinicians / implementers understand how the systems works

b. help implementers / devs understand how the interactions between components work

c. Load / performance / application testing

How do we want to position this?

a. The demo app should be a neutral system that demonstrates how you can built your own POC app

b. The demo app could be existing POC apps that are already used by OpenHIE

Best Regards,
Suranga

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

Best Regards,
Suranga

pbiondich · March 16, 2016, 6:22pm

That makes a lot of sense to me, Suranga.

It seems like things like the “HIE Visualizer” and the mockup POC tool you’ve developed to send mock transactions for our workflows are much more relevant to the first audience.

OTOH, the OSCAR/OMRS integration activity around immunizations is more relevant to group b.

I suspect we ultimately need both audiences served in some capacity.

-Paul

···

On Wed, Mar 16, 2016 at 2:15 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low level implementers who want to understand how the system works, and look at its underbelly (transactions, messages etc) and (b) high level implementers/ministry/officials etc. who want to understand the clinical relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching / training tool - something that can be used to visualize transactions / show folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the ones involving OSCAR and OpenMRS - tools that demonstrate clinical relevance, and working use cases, and can directly plug and play with OpenHIE.

What do people think?

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the performance of the IOL. They were raised before, and the Ryan C + Hannes combination fixed that issue very promptly. I cant guarantee this, but I believe that the delay still exists because either the changes didn’t go into the OpenHIE 1.0 release that we’re testing, or for some other reason… But again, don’t take my word for this, I will re-check and confirm when folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how OpenHIE is consumed by an existing application(s) (not a new build, but one that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail once we hear more opinions

–
Best Regards,
Suranga

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi) have been thinking about this quite a bit and for sometime. I think understanding fundamentally what we are trying to demonstrate is important. I pretext this with the fact that I wan’t on the calls and have seen the recordings. Suranga your POC demo seemed to focus on showing what OpenHIE could provide to the POC - it was very focused at showing that you could get information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within a more clinical use case and show how it is / can be leveraged by tools prevalent in the low resource settings environment within which we work. The Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing how OHIE supports care and means that we can show just how OHIE impacts health/clinical use cases. From our experiences in running the first demo back in 2010 at Medinfo (learning from Mohawks team and their experiences) I think the value that we had was that the tools that were shown could be related to in the field systems and the “story” could be told that highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would propose the following:

We need to have a sandbox which provides accessible data endpoints for each of our OHIE workflows (that we have I believe – btw I want to better understand why you think the IOL was the cause of the delay in your demo - can we have a look at this? in our implementations we aren’t seeing it responding that slowly and it is not a fair representation of the tool or OHIE if it is doing that on our sandbox environment – please reach out to us if this is the case we all need to succeed here). But more so we need to guide people in following an illustrative use case for them to understand how it all comes together. Right now you can maybe knock on OHIE to register and resolve a patient but if we really want to show it we should say to ppl if you consume XX endpoints you can see your system contributing to a particular use case (maternal care for example). Having the wiring there is one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.

My view is the app should rather show how OpenHIE is consumed by an existing application(s) (not a new build, but one that is for low resource settings if possible) in a particular workflow. We can focus on technical documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this way) as the implementer community comes to life as it will bring us down to “real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

Best Regards,
Suranga

–

Regards
Carl Fourie
Senior Program Manager

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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a great demo of how the Oscar system integrated with OpenHIE. Prior to that, I presented a separate demo POC app which was built from scratch (I.e. vendor neutral).

During the meeting, we decided to discuss a common path ahead, and a strategy of what we would like to see. To move this forward, i’d like to hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?

a. Help clinicians / implementers understand how the systems works

b. help implementers / devs understand how the interactions between components work

c. Load / performance / application testing

How do we want to position this?

a. The demo app should be a neutral system that demonstrates how you can built your own POC app

b. The demo app could be existing POC apps that are already used by OpenHIE

Best Regards,
Suranga

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

bobj · March 16, 2016, 6:31pm

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don't get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

···

On 16 March 2016 at 19:15, Suranga Kasthurirathne <surangakas@gmail.com> wrote:

Hi everyone,

I've been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo's using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne > <surangakas@gmail.com> wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn't go
into the OpenHIE 1.0 release that we're testing, or for some other reason...
But again, don't take my word for this, I will re-check and confirm when
folks return to office on Monday.

I'll take note of your comment that 'the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible'.

I'm waiting to hear more comments, and we'll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie <carl@jembi.org> wrote:

Hi All

Thanks Suranga for "kicking the nest" here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan't on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the "story" could be told that
highlighted OHIE's (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe -- btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren't seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment -- please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to "juice" the system to make it meaningful.

Now all that on the page it brings us to "Demo App".
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on "how to build your own app / link my app to OHIE".

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
"real world" demonstrations.

Just my ZAR 0.02 and I hope it isn't TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne >>> <surangak@openmrs.org> wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i'd like to
hear your general input on the following:

Two very broad questions....

1) What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing

2) How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

--
Best Regards,
Suranga

--
You received this message because you are subscribed to the Google
Groups "OpenHIE Sandbox" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
"OpenHIE Sandbox" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Best Regards,
Suranga

--
Best Regards,
Suranga

--
You received this message because you are subscribed to the Google Groups
"OpenHIE Sandbox" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Scott_Teesdale · March 16, 2016, 10:28pm

I would echo bob's group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

- Scott

···

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe<bobjolliffe@gmail.com>, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don't get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne<surangakas@gmail.com>wrote:
>
> Hi everyone,
>
> I've been contemplating demo strategy based on what Carl proposed, and I
> want to suggest the following -
>
> Loosely, we can break our demo audience into two groups - (a) developers/low
> level implementers who want to understand how the system works, and look at
> its underbelly (transactions, messages etc) and (b) high level
> implementers/ministry/officials etc. who want to understand the clinical
> relevance/value/impact
>
> For group (a): Something thats designed more as a guide - as a teaching /
> training tool - something that can be used to visualize transactions / show
> folks where things failed and how messages travel etc.
>
> For group (b): We need demo's using existing tools/applications, such as the
> ones involving OSCAR and OpenMRS - tools that demonstrate clinical
> relevance, and working use cases, and can directly plug and play with
> OpenHIE.
>
> What do people think?
>
> On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne > > <surangakas@gmail.com>wrote:
> >
> >
> > Hi there,
> >
> > Thanks Carl,
> >
> > Firstly, I think I should apologize over my early statement on the
> > performance of the IOL. They were raised before, and the Ryan C + Hannes
> > combination fixed that issue very promptly. I cant guarantee this, but I
> > believe that the delay still exists because either the changes didn't go
> > into the OpenHIE 1.0 release that we're testing, or for some other reason...
> > But again, don't take my word for this, I will re-check and confirm when
> > folks return to office on Monday.
> >
> > I'll take note of your comment that 'the app should rather show how
> > OpenHIE is consumed by an existing application(s) (not a new build, but one
> > that is for low resource settings if possible'.
> >
> > I'm waiting to hear more comments, and we'll discuss them in more detail
> > once we hear more opinions
> >
> >
> > On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie<carl@jembi.org>wrote:
> > >
> > > Hi All
> > >
> > > Thanks Suranga for "kicking the nest" here to get this going. We (Jembi)
> > > have been thinking about this quite a bit and for sometime. I think
> > > understanding fundamentally what we are trying to demonstrate is important.
> > > I pretext this with the fact that I wan't on the calls and have seen the
> > > recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
> > > could provide to the POC - it was very focused at showing that you could get
> > > information from OHIE but you had to know what it was you were looking at.
> > >
> > > Personally I think we need to contextualize what OpenHIE provides within
> > > a more clinical use case and show how it is / can be leveraged by tools
> > > prevalent in the low resource settings environment within which we work. The
> > > Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
> > > how OHIE supports care and means that we can show just how OHIE impacts
> > > health/clinical use cases. From our experiences in running the first demo
> > > back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
> > > think the value that we had was that the tools that were shown could be
> > > related to in the field systems and the "story" could be told that
> > > highlighted OHIE's (then RHEA/RHIE) deployment.
> > >
> > > So again I come back to what are we wanting to demonstrate? I would
> > > propose the following:
> > > We need to have a sandbox which provides accessible data endpoints for
> > > each of our OHIE workflows (that we have I believe -- btw I want to better
> > > understand why you think the IOL was the cause of the delay in your demo -
> > > can we have a look at this? in our implementations we aren't seeing it
> > > responding that slowly and it is not a fair representation of the tool or
> > > OHIE if it is doing that on our sandbox environment -- please reach out to
> > > us if this is the case we all need to succeed here). But more so we need to
> > > guide people in following an illustrative use case for them to understand
> > > how it all comes together. Right now you can maybe knock on OHIE to register
> > > and resolve a patient but if we really want to show it we should say to ppl
> > > if you consume XX endpoints you can see your system contributing to a
> > > particular use case (maternal care for example). Having the wiring there is
> > > one thing, we need to "juice" the system to make it meaningful.
> > >
> > > Now all that on the page it brings us to "Demo App".
> > > My view is the app should rather show how OpenHIE is consumed by an
> > > existing application(s) (not a new build, but one that is for low resource
> > > settings if possible) in a particular workflow. We can focus on technical
> > > documentation on "how to build your own app / link my app to OHIE".
> > >
> > > This is going to be a very valuable direction (if we are able to go this
> > > way) as the implementer community comes to life as it will bring us down to
> > > "real world" demonstrations.
> > >
> > > Just my ZAR 0.02 and I hope it isn't TLDR
> > >
> > > Cheers
> > >
> > > Regards
> > > Carl Fourie
> > > Senior Program Manager
> > > Jembi Health Systems | SOUTH AFRICA
> > > Mobile:+27 71 540 4477(tel:+27%2071%20540%204477)| Office:+27 21 701 0939(tel:+27%2021%20701%200939)| 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.
> > >
> > > On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne > > > > <surangak@openmrs.org>wrote:
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > There has been some discussion on how OpenHIE as a community would like
> > > > to move forward with building / supporting demo systems.
> > > >
> > > > During the sandbox call held on the 7th of March, Mohawk presented a
> > > > great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
> > > > presented a separate demo POC app which was built from scratch (I.e. vendor
> > > > neutral).
> > > >
> > > > During the meeting, we decided to discuss a common path ahead, and a
> > > > strategy of what we would like to see. To move this forward, i'd like to
> > > > hear your general input on the following:
> > > >
> > > > Two very broad questions....
> > > >
> > > > 1) What is the purpose of the demo?
> > > > a. Help clinicians / implementers understand how the systems works
> > > > b. help implementers / devs understand how the interactions between
> > > > components work
> > > > c. Load / performance / application testing
> > > >
> > > > 2) How do we want to position this?
> > > > a. The demo app should be a neutral system that demonstrates how you can
> > > > built your own POC app
> > > > b. The demo app could be existing POC apps that are already used by
> > > > OpenHIE
> > > >
> > > >
> > > > --
> > > > Best Regards,
> > > > Suranga
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "OpenHIE Sandbox" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an email to ohie-sandbox+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
> > > "OpenHIE Sandbox" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to ohie-sandbox+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> >
> > --
> > Best Regards,
> > Suranga
>
>
>
>
> --
> Best Regards,
> Suranga
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenHIE Sandbox" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ohie-sandbox+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 "OpenHIE Sandbox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Carl_Fourie1 · March 17, 2016, 7:41am

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

···

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always

overlooked.

The ones who will manage the system, bring it to life in material form

and keep it going. CIOs, technical officers, sysadmins, network

admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and

things rapidly fall apart or don’t get started in the first place. I

suppose in a way the sandbox itself is the facilitator of this

seduction. Likes the systems-on-a-stick and demo systems of the past

which some folk will be familiar with from earlier WHO efforts. I

think probably the sandbox needs to also showcase itself (rather than

just the apps which are on it) in some way. To expose the hidden

labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I

want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low

level implementers who want to understand how the system works, and look at

its underbelly (transactions, messages etc) and (b) high level

implementers/ministry/officials etc. who want to understand the clinical

relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /

training tool - something that can be used to visualize transactions / show

folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the

ones involving OSCAR and OpenMRS - tools that demonstrate clinical

relevance, and working use cases, and can directly plug and play with

OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne

surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the

performance of the IOL. They were raised before, and the Ryan C + Hannes

combination fixed that issue very promptly. I cant guarantee this, but I

believe that the delay still exists because either the changes didn’t go

into the OpenHIE 1.0 release that we’re testing, or for some other reason…

But again, don’t take my word for this, I will re-check and confirm when

folks return to office on Monday.

I’ll take note of your comment that 'the app should rather show how

OpenHIE is consumed by an existing application(s) (not a new build, but one

that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail

once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)

have been thinking about this quite a bit and for sometime. I think

understanding fundamentally what we are trying to demonstrate is important.

I pretext this with the fact that I wan’t on the calls and have seen the

recordings. Suranga your POC demo seemed to focus on showing what OpenHIE

could provide to the POC - it was very focused at showing that you could get

information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within

a more clinical use case and show how it is / can be leveraged by tools

prevalent in the low resource settings environment within which we work. The

Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing

how OHIE supports care and means that we can show just how OHIE impacts

health/clinical use cases. From our experiences in running the first demo

back in 2010 at Medinfo (learning from Mohawks team and their experiences) I

think the value that we had was that the tools that were shown could be

related to in the field systems and the “story” could be told that

highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would

propose the following:

We need to have a sandbox which provides accessible data endpoints for

each of our OHIE workflows (that we have I believe – btw I want to better

understand why you think the IOL was the cause of the delay in your demo -

can we have a look at this? in our implementations we aren’t seeing it

responding that slowly and it is not a fair representation of the tool or

OHIE if it is doing that on our sandbox environment – please reach out to

us if this is the case we all need to succeed here). But more so we need to

guide people in following an illustrative use case for them to understand

how it all comes together. Right now you can maybe knock on OHIE to register

and resolve a patient but if we really want to show it we should say to ppl

if you consume XX endpoints you can see your system contributing to a

particular use case (maternal care for example). Having the wiring there is

one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.

My view is the app should rather show how OpenHIE is consumed by an

existing application(s) (not a new build, but one that is for low resource

settings if possible) in a particular workflow. We can focus on technical

documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this

way) as the implementer community comes to life as it will bring us down to

“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards

Carl Fourie

Senior Program Manager

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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne

surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like

to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a

great demo of how the Oscar system integrated with OpenHIE. Prior to that, I

presented a separate demo POC app which was built from scratch (I.e. vendor

neutral).

During the meeting, we decided to discuss a common path ahead, and a

strategy of what we would like to see. To move this forward, i’d like to

hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?

a. Help clinicians / implementers understand how the systems works

b. help implementers / devs understand how the interactions between

components work

c. Load / performance / application testing

How do we want to position this?

a. The demo app should be a neutral system that demonstrates how you can

built your own POC app

b. The demo app could be existing POC apps that are already used by

OpenHIE

–

Best Regards,

Suranga

–

You received this message because you are subscribed to the Google

Groups “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to ohie-sandbox+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

“OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to ohie-sandbox+unsubscribe@googlegroups.com.

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

–

Best Regards,

Suranga

–

Best Regards,

Suranga

–

You received this message because you are subscribed to the Google Groups

“OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to ohie-sandbox+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 “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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

Regards
Carl Fourie
Senior Program Manager

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.

Suranga_Kasthurirat1 · March 22, 2016, 5:44pm

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

···

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

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

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

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

Regards
Carl Fourie
Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always

overlooked.

The ones who will manage the system, bring it to life in material form

and keep it going. CIOs, technical officers, sysadmins, network

admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and

things rapidly fall apart or don’t get started in the first place. I

suppose in a way the sandbox itself is the facilitator of this

seduction. Likes the systems-on-a-stick and demo systems of the past

which some folk will be familiar with from earlier WHO efforts. I

think probably the sandbox needs to also showcase itself (rather than

just the apps which are on it) in some way. To expose the hidden

labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I

want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low

level implementers who want to understand how the system works, and look at

its underbelly (transactions, messages etc) and (b) high level

implementers/ministry/officials etc. who want to understand the clinical

relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /

training tool - something that can be used to visualize transactions / show

folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the

ones involving OSCAR and OpenMRS - tools that demonstrate clinical

relevance, and working use cases, and can directly plug and play with

OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne

surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the

performance of the IOL. They were raised before, and the Ryan C + Hannes

combination fixed that issue very promptly. I cant guarantee this, but I

believe that the delay still exists because either the changes didn’t go

into the OpenHIE 1.0 release that we’re testing, or for some other reason…

But again, don’t take my word for this, I will re-check and confirm when

folks return to office on Monday.

I’ll take note of your comment that 'the app should rather show how

OpenHIE is consumed by an existing application(s) (not a new build, but one

that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail

once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)

have been thinking about this quite a bit and for sometime. I think

understanding fundamentally what we are trying to demonstrate is important.

I pretext this with the fact that I wan’t on the calls and have seen the

recordings. Suranga your POC demo seemed to focus on showing what OpenHIE

could provide to the POC - it was very focused at showing that you could get

information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within

a more clinical use case and show how it is / can be leveraged by tools

prevalent in the low resource settings environment within which we work. The

Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing

how OHIE supports care and means that we can show just how OHIE impacts

health/clinical use cases. From our experiences in running the first demo

back in 2010 at Medinfo (learning from Mohawks team and their experiences) I

think the value that we had was that the tools that were shown could be

related to in the field systems and the “story” could be told that

highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would

propose the following:

We need to have a sandbox which provides accessible data endpoints for

each of our OHIE workflows (that we have I believe – btw I want to better

understand why you think the IOL was the cause of the delay in your demo -

can we have a look at this? in our implementations we aren’t seeing it

responding that slowly and it is not a fair representation of the tool or

OHIE if it is doing that on our sandbox environment – please reach out to

us if this is the case we all need to succeed here). But more so we need to

guide people in following an illustrative use case for them to understand

how it all comes together. Right now you can maybe knock on OHIE to register

and resolve a patient but if we really want to show it we should say to ppl

if you consume XX endpoints you can see your system contributing to a

particular use case (maternal care for example). Having the wiring there is

one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.

My view is the app should rather show how OpenHIE is consumed by an

existing application(s) (not a new build, but one that is for low resource

settings if possible) in a particular workflow. We can focus on technical

documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this

way) as the implementer community comes to life as it will bring us down to

“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards

Carl Fourie

Senior Program Manager

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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne

surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like

to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a

great demo of how the Oscar system integrated with OpenHIE. Prior to that, I

presented a separate demo POC app which was built from scratch (I.e. vendor

neutral).

During the meeting, we decided to discuss a common path ahead, and a

strategy of what we would like to see. To move this forward, i’d like to

hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?

a. Help clinicians / implementers understand how the systems works

b. help implementers / devs understand how the interactions between

components work

c. Load / performance / application testing

How do we want to position this?

a. The demo app should be a neutral system that demonstrates how you can

built your own POC app

b. The demo app could be existing POC apps that are already used by

OpenHIE

–

Best Regards,

Suranga

–

You received this message because you are subscribed to the Google

Groups “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to ohie-sandbox+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

“OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to ohie-sandbox+unsubscribe@googlegroups.com.

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

–

Best Regards,

Suranga

–

Best Regards,

Suranga

–

You received this message because you are subscribed to the Google Groups

“OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to ohie-sandbox+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 “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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

dritz · March 23, 2016, 1:03pm

Hi Suranga et al.

Suranga, I think group A’s needs will be served by things like re-usable, pre-built API components (in java, .NET, etc.) and code examples that illustrate how to use these. No one should expect to develop code from scratch; there are mature open source frameworks (http://cdatools.org/, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html, etc.) and we need to point developers to these and perhaps even start to cultivate “job aids” re: how to use them. Also, the existing IHE documentation regarding actor “behaviours” is fundamentally important and, to be honest, we need to do a much better job of ensuring potential system developers leverage these assets. IHE puts a lot of effort into these document sets and we should not expect to spend time/money to duplicate them (rather, we should “inherit” them). Lastly, my sense is that this “dev” group will need a live lab environment to play around in and we should make it easy for them to connect to MEDIC, HEAL and COIL.

Group B needs scenarios and we have a rudimentary start on getting some of these documented (https://hingx.org/Share/Attachment/2552?fileName=Live%20Demonstration%20-%20Digital%20Health%20for%20Better%20Care%20The%20Maternal%20and%20Child%20Continuum%20of%20Care%20Scenario.pdf&folderID=null). I don’t really think that this group should be “owned” by any particular POS application. Rather, the scenarios should describe particular care delivery narratives in terms of their transactions and enable these to be walked through using any POS systems that can connect to the HIE and play the necessary role. Where group A focuses on all the transactions that an actor can do (an SHR or a CR or whatever)… group B focuses on the series of transactions and actors that are needed to tell a health story. We have a few POS systems that we’ve already demo’d using this scenario-based idea (e.g. OpenMRS, OSCAR, GIIS, DHIS2, RapidPro, etc.) but the potential list of participants includes every system that speaks the necessary IHE transactions (and this is a loooooong list; http://product-registry.ihe.net/PR/home.seam).

Group C plays for keeps; these are the guys that need to operate live systems. To be blunt, this group is not served by OpenHIE as much as it is served by the product-publishing members of OpenHIE. User manuals and operating guides are needed for each of the HIE systems, and these need to be of commercial-grade quality. At some future time we might want to consider the completeness of the “product documentation” as one of our OpenHIE certification criteria alongside functional conformance. For group C, it will be important to be able to conformance-test and load-test their specific product configuration (the “project-a-thon” idea). There is an important risk-mitigation service our labs (MEDIC, HEAL, COIL) can play, here. My sense is that this work will be implementation-specific and should be funded out of the specific project’s budget. (E.g. the testing MEDIC did for the BID TZ implementation).

Sorry to be late to the party. I hope these comments are helpful.

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: ohie-sandbox@googlegroups.com [mailto:ohie-sandbox@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Tuesday, March 22, 2016 1:45 PM
To: ohie-sandbox@googlegroups.com
Subject: Re: OpenHIE demo strategy: What’s your opinion?

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

Regards
Carl Fourie

Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group © who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget © and
things rapidly fall apart or don’t get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group ©

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn’t go
into the OpenHIE 1.0 release that we’re testing, or for some other reason…
But again, don’t take my word for this, I will re-check and confirm when
folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan’t on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the “story” could be told that
highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe – btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren’t seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment – please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i’d like to
hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing
How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google
Groups “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google Groups
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+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 “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ryan_Yates1 · March 24, 2016, 7:26pm

In regards to group C, what would be valuable to showcase? Automation tools, documentation, continuous integration tools? Or maybe how the environment is set up to host the sandbox? I want to know what others want to see as I am biased on what I think is important :).

···

On Wed, Mar 23, 2016 at 9:03 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga et al.

Suranga, I think group A’s needs will be served by things like re-usable, pre-built API components (in java, .NET, etc.) and code examples that illustrate how to use these. No one should expect to develop code from scratch; there are mature open source frameworks (http://cdatools.org/, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html, etc.) and we need to point developers to these and perhaps even start to cultivate “job aids” re: how to use them. Also, the existing IHE documentation regarding actor “behaviours” is fundamentally important and, to be honest, we need to do a much better job of ensuring potential system developers leverage these assets. IHE puts a lot of effort into these document sets and we should not expect to spend time/money to duplicate them (rather, we should “inherit” them). Lastly, my sense is that this “dev” group will need a live lab environment to play around in and we should make it easy for them to connect to MEDIC, HEAL and COIL.

Group B needs scenarios and we have a rudimentary start on getting some of these documented (https://hingx.org/Share/Attachment/2552?fileName=Live%20Demonstration%20-%20Digital%20Health%20for%20Better%20Care%20The%20Maternal%20and%20Child%20Continuum%20of%20Care%20Scenario.pdf&folderID=null). I don’t really think that this group should be “owned” by any particular POS application. Rather, the scenarios should describe particular care delivery narratives in terms of their transactions and enable these to be walked through using any POS systems that can connect to the HIE and play the necessary role. Where group A focuses on all the transactions that an actor can do (an SHR or a CR or whatever)… group B focuses on the series of transactions and actors that are needed to tell a health story. We have a few POS systems that we’ve already demo’d using this scenario-based idea (e.g. OpenMRS, OSCAR, GIIS, DHIS2, RapidPro, etc.) but the potential list of participants includes every system that speaks the necessary IHE transactions (and this is a loooooong list; http://product-registry.ihe.net/PR/home.seam).

Group C plays for keeps; these are the guys that need to operate live systems. To be blunt, this group is not served by OpenHIE as much as it is served by the product-publishing members of OpenHIE. User manuals and operating guides are needed for each of the HIE systems, and these need to be of commercial-grade quality. At some future time we might want to consider the completeness of the “product documentation” as one of our OpenHIE certification criteria alongside functional conformance. For group C, it will be important to be able to conformance-test and load-test their specific product configuration (the “project-a-thon” idea). There is an important risk-mitigation service our labs (MEDIC, HEAL, COIL) can play, here. My sense is that this work will be implementation-specific and should be funded out of the specific project’s budget. (E.g. the testing MEDIC did for the BID TZ implementation).

Sorry to be late to the party. I hope these comments are helpful.

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: ohie-sandbox@googlegroups.com [mailto:ohie-sandbox@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Tuesday, March 22, 2016 1:45 PM
To: ohie-sandbox@googlegroups.com
Subject: Re: OpenHIE demo strategy: What’s your opinion?

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

Regards
Carl Fourie

Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don’t get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne
surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn’t go
into the OpenHIE 1.0 release that we’re testing, or for some other reason…
But again, don’t take my word for this, I will re-check and confirm when
folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan’t on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the “story” could be told that
highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe – btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren’t seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment – please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne
surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i’d like to
hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing

How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google
Groups “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,
Suranga

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google Groups
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+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 “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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

ryan · April 4, 2016, 10:31am

Hi all,

These are are some very important conversations and I agree with what Carl F has mentioned above. This has been a topic of great discussion within Jembi over the past months.

I feel that we don’t really need a ‘demo app’, what we really need is a reference, production quality PoC system just like we have for the other components of the OHIE architecture. This reference application could be setup in a demo mode along with the rest of the reference applications to provide a useful demo environment. With a fully implemented reference application setup in a demo environment we could address each of the groups mentioned above:

Group A (developers) - The reference PoC application would provide a starting point for HIE developers and show best practices and libraries that could be used to implement a PoC application. They could also learn how this hook into the OpenHIE workflows and even view the transaction that are executed in the demo environment via the OpenHIM.
Group B (implementers) - The reference PoC application in the demo environment could concretely demonstration the clinical use cases that we expect to support. This would allow ministry officials a live view of how OpenHIE could improve patient care.
Group C (Operators) - We would have to manage the demo environment ourselves so operators would benefit from the documentations and lessons that we learn in doing so. The demo environment could also be used as a teaching tool to train HIE operators.
In addition the reference PoC application and demo environment would allow us to:
Test each workflow that we develop
Test new versions of our reference applications
Introduce people to what can be accomplished by OHIE
Enable us to streamline our workflows and the standards that we use to make them more implementable (because we will have to implement a PoC ourselves)
Provide an out of the box HIE and PoC application that does something clinically relevant for those that don’t wish so start off doing development.

I know that I would love to work on a reference PoC application and the setup of a demo environment for OpenHIE. I think this would be extremely useful. What do other think of this? I believe that much of what has been discussed in this thread could be accomplished by focussing on this direction.

Cheers,

Ryan

···

On Wed, Mar 23, 2016 at 9:03 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga et al.

Suranga, I think group A’s needs will be served by things like re-usable, pre-built API components (in java, .NET, etc.) and code examples that illustrate how to use these. No one should expect to develop code from scratch; there are mature open source frameworks (http://cdatools.org/, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html, etc.) and we need to point developers to these and perhaps even start to cultivate “job aids” re: how to use them. Also, the existing IHE documentation regarding actor “behaviours” is fundamentally important and, to be honest, we need to do a much better job of ensuring potential system developers leverage these assets. IHE puts a lot of effort into these document sets and we should not expect to spend time/money to duplicate them (rather, we should “inherit” them). Lastly, my sense is that this “dev” group will need a live lab environment to play around in and we should make it easy for them to connect to MEDIC, HEAL and COIL.

Group B needs scenarios and we have a rudimentary start on getting some of these documented (https://hingx.org/Share/Attachment/2552?fileName=Live%20Demonstration%20-%20Digital%20Health%20for%20Better%20Care%20The%20Maternal%20and%20Child%20Continuum%20of%20Care%20Scenario.pdf&folderID=null). I don’t really think that this group should be “owned” by any particular POS application. Rather, the scenarios should describe particular care delivery narratives in terms of their transactions and enable these to be walked through using any POS systems that can connect to the HIE and play the necessary role. Where group A focuses on all the transactions that an actor can do (an SHR or a CR or whatever)… group B focuses on the series of transactions and actors that are needed to tell a health story. We have a few POS systems that we’ve already demo’d using this scenario-based idea (e.g. OpenMRS, OSCAR, GIIS, DHIS2, RapidPro, etc.) but the potential list of participants includes every system that speaks the necessary IHE transactions (and this is a loooooong list; http://product-registry.ihe.net/PR/home.seam).

Group C plays for keeps; these are the guys that need to operate live systems. To be blunt, this group is not served by OpenHIE as much as it is served by the product-publishing members of OpenHIE. User manuals and operating guides are needed for each of the HIE systems, and these need to be of commercial-grade quality. At some future time we might want to consider the completeness of the “product documentation” as one of our OpenHIE certification criteria alongside functional conformance. For group C, it will be important to be able to conformance-test and load-test their specific product configuration (the “project-a-thon” idea). There is an important risk-mitigation service our labs (MEDIC, HEAL, COIL) can play, here. My sense is that this work will be implementation-specific and should be funded out of the specific project’s budget. (E.g. the testing MEDIC did for the BID TZ implementation).

Sorry to be late to the party. I hope these comments are helpful.

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: ohie-sandbox@googlegroups.com [mailto:ohie-sandbox@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Tuesday, March 22, 2016 1:45 PM
To: ohie-sandbox@googlegroups.com
Subject: Re: OpenHIE demo strategy: What’s your opinion?

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

Regards
Carl Fourie

Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don’t get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne
surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn’t go
into the OpenHIE 1.0 release that we’re testing, or for some other reason…
But again, don’t take my word for this, I will re-check and confirm when
folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan’t on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the “story” could be told that
highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe – btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren’t seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment – please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne
surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i’d like to
hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing

How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google
Groups “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,
Suranga

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google Groups
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+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 “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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

Suranga_Kasthurirat2 · April 4, 2016, 11:21am

Hey Ryan! welcome back

These are excellent comments - but quick question to you - did you plan to attend todays sandbox call, where we’ll be discussing all this at length?

Best regards,

Suranga

···

On Mon, Apr 4, 2016 at 6:31 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

These are are some very important conversations and I agree with what Carl F has mentioned above. This has been a topic of great discussion within Jembi over the past months.

I feel that we don’t really need a ‘demo app’, what we really need is a reference, production quality PoC system just like we have for the other components of the OHIE architecture. This reference application could be setup in a demo mode along with the rest of the reference applications to provide a useful demo environment. With a fully implemented reference application setup in a demo environment we could address each of the groups mentioned above:

Group A (developers) - The reference PoC application would provide a starting point for HIE developers and show best practices and libraries that could be used to implement a PoC application. They could also learn how this hook into the OpenHIE workflows and even view the transaction that are executed in the demo environment via the OpenHIM.

Group B (implementers) - The reference PoC application in the demo environment could concretely demonstration the clinical use cases that we expect to support. This would allow ministry officials a live view of how OpenHIE could improve patient care.

Group C (Operators) - We would have to manage the demo environment ourselves so operators would benefit from the documentations and lessons that we learn in doing so. The demo environment could also be used as a teaching tool to train HIE operators.
In addition the reference PoC application and demo environment would allow us to:

Test each workflow that we develop

Test new versions of our reference applications

Introduce people to what can be accomplished by OHIE

Enable us to streamline our workflows and the standards that we use to make them more implementable (because we will have to implement a PoC ourselves)

Provide an out of the box HIE and PoC application that does something clinically relevant for those that don’t wish so start off doing development.

I know that I would love to work on a reference PoC application and the setup of a demo environment for OpenHIE. I think this would be extremely useful. What do other think of this? I believe that much of what has been discussed in this thread could be accomplished by focussing on this direction.

Cheers,

Ryan

On Thu, Mar 24, 2016 at 9:26 PM Ryan Yates ryan@openmrs.org wrote:

In regards to group C, what would be valuable to showcase? Automation tools, documentation, continuous integration tools? Or maybe how the environment is set up to host the sandbox? I want to know what others want to see as I am biased on what I think is important :).

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+unsubscribe@googlegroups.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 Sandbox” group.

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

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

–

On Wed, Mar 23, 2016 at 9:03 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga et al.

Suranga, I think group A’s needs will be served by things like re-usable, pre-built API components (in java, .NET, etc.) and code examples that illustrate how to use these. No one should expect to develop code from scratch; there are mature open source frameworks (http://cdatools.org/, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html, etc.) and we need to point developers to these and perhaps even start to cultivate “job aids” re: how to use them. Also, the existing IHE documentation regarding actor “behaviours” is fundamentally important and, to be honest, we need to do a much better job of ensuring potential system developers leverage these assets. IHE puts a lot of effort into these document sets and we should not expect to spend time/money to duplicate them (rather, we should “inherit” them). Lastly, my sense is that this “dev” group will need a live lab environment to play around in and we should make it easy for them to connect to MEDIC, HEAL and COIL.

Group B needs scenarios and we have a rudimentary start on getting some of these documented (https://hingx.org/Share/Attachment/2552?fileName=Live%20Demonstration%20-%20Digital%20Health%20for%20Better%20Care%20The%20Maternal%20and%20Child%20Continuum%20of%20Care%20Scenario.pdf&folderID=null). I don’t really think that this group should be “owned” by any particular POS application. Rather, the scenarios should describe particular care delivery narratives in terms of their transactions and enable these to be walked through using any POS systems that can connect to the HIE and play the necessary role. Where group A focuses on all the transactions that an actor can do (an SHR or a CR or whatever)… group B focuses on the series of transactions and actors that are needed to tell a health story. We have a few POS systems that we’ve already demo’d using this scenario-based idea (e.g. OpenMRS, OSCAR, GIIS, DHIS2, RapidPro, etc.) but the potential list of participants includes every system that speaks the necessary IHE transactions (and this is a loooooong list; http://product-registry.ihe.net/PR/home.seam).

Group C plays for keeps; these are the guys that need to operate live systems. To be blunt, this group is not served by OpenHIE as much as it is served by the product-publishing members of OpenHIE. User manuals and operating guides are needed for each of the HIE systems, and these need to be of commercial-grade quality. At some future time we might want to consider the completeness of the “product documentation” as one of our OpenHIE certification criteria alongside functional conformance. For group C, it will be important to be able to conformance-test and load-test their specific product configuration (the “project-a-thon” idea). There is an important risk-mitigation service our labs (MEDIC, HEAL, COIL) can play, here. My sense is that this work will be implementation-specific and should be funded out of the specific project’s budget. (E.g. the testing MEDIC did for the BID TZ implementation).

Sorry to be late to the party. I hope these comments are helpful.

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: ohie-sandbox@googlegroups.com [mailto:ohie-sandbox@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Tuesday, March 22, 2016 1:45 PM
To: ohie-sandbox@googlegroups.com
Subject: Re: OpenHIE demo strategy: What’s your opinion?

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

Regards
Carl Fourie

Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don’t get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne
surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn’t go
into the OpenHIE 1.0 release that we’re testing, or for some other reason…
But again, don’t take my word for this, I will re-check and confirm when
folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan’t on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the “story” could be told that
highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe – btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren’t seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment – please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne
surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i’d like to
hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing

How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google
Groups “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,
Suranga

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google Groups
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+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 “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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

Best Regards,
Suranga

dritz · April 4, 2016, 12:14pm

Hi all.
I hope we can discuss these ideas today. One of our challenges will be to support demonstrations of interoperability. No one POS application gets us there. As they say, it takes two to tango.
See you on the call.
Derek.

+1(905)515-0045

···

On Mon, Apr 4, 2016 at 6:31 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

These are are some very important conversations and I agree with what Carl F has mentioned above. This has been a topic of great discussion within Jembi over the past months.

I feel that we don’t really need a ‘demo app’, what we really need is a reference, production quality PoC system just like we have for the other components of the OHIE architecture. This reference application could be setup in a demo mode along with the rest of the reference applications to provide a useful demo environment. With a fully implemented reference application setup in a demo environment we could address each of the groups mentioned above:

Group A (developers) - The reference PoC application would provide a starting point for HIE developers and show best practices and libraries that could be used to implement a PoC application. They could also learn how this hook into the OpenHIE workflows and even view the transaction that are executed in the demo environment via the OpenHIM.

Group B (implementers) - The reference PoC application in the demo environment could concretely demonstration the clinical use cases that we expect to support. This would allow ministry officials a live view of how OpenHIE could improve patient care.

Group C (Operators) - We would have to manage the demo environment ourselves so operators would benefit from the documentations and lessons that we learn in doing so. The demo environment could also be used as a teaching tool to train HIE operators.
In addition the reference PoC application and demo environment would allow us to:

Test each workflow that we develop

Test new versions of our reference applications

Introduce people to what can be accomplished by OHIE

Enable us to streamline our workflows and the standards that we use to make them more implementable (because we will have to implement a PoC ourselves)

Provide an out of the box HIE and PoC application that does something clinically relevant for those that don’t wish so start off doing development.

I know that I would love to work on a reference PoC application and the setup of a demo environment for OpenHIE. I think this would be extremely useful. What do other think of this? I believe that much of what has been discussed in this thread could be accomplished by focussing on this direction.

Cheers,

Ryan

On Thu, Mar 24, 2016 at 9:26 PM Ryan Yates ryan@openmrs.org wrote:

In regards to group C, what would be valuable to showcase? Automation tools, documentation, continuous integration tools? Or maybe how the environment is set up to host the sandbox? I want to know what others want to see as I am biased on what I think is important :).

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+unsubscribe@googlegroups.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 Sandbox” group.

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

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

–
Best Regards,
Suranga

On Wed, Mar 23, 2016 at 9:03 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga et al.

Suranga, I think group A’s needs will be served by things like re-usable, pre-built API components (in java, .NET, etc.) and code examples that illustrate how to use these. No one should expect to develop code from scratch; there are mature open source frameworks (http://cdatools.org/, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html, etc.) and we need to point developers to these and perhaps even start to cultivate “job aids” re: how to use them. Also, the existing IHE documentation regarding actor “behaviours” is fundamentally important and, to be honest, we need to do a much better job of ensuring potential system developers leverage these assets. IHE puts a lot of effort into these document sets and we should not expect to spend time/money to duplicate them (rather, we should “inherit” them). Lastly, my sense is that this “dev” group will need a live lab environment to play around in and we should make it easy for them to connect to MEDIC, HEAL and COIL.

Group B needs scenarios and we have a rudimentary start on getting some of these documented (https://hingx.org/Share/Attachment/2552?fileName=Live%20Demonstration%20-%20Digital%20Health%20for%20Better%20Care%20The%20Maternal%20and%20Child%20Continuum%20of%20Care%20Scenario.pdf&folderID=null). I don’t really think that this group should be “owned” by any particular POS application. Rather, the scenarios should describe particular care delivery narratives in terms of their transactions and enable these to be walked through using any POS systems that can connect to the HIE and play the necessary role. Where group A focuses on all the transactions that an actor can do (an SHR or a CR or whatever)… group B focuses on the series of transactions and actors that are needed to tell a health story. We have a few POS systems that we’ve already demo’d using this scenario-based idea (e.g. OpenMRS, OSCAR, GIIS, DHIS2, RapidPro, etc.) but the potential list of participants includes every system that speaks the necessary IHE transactions (and this is a loooooong list; http://product-registry.ihe.net/PR/home.seam).

Group C plays for keeps; these are the guys that need to operate live systems. To be blunt, this group is not served by OpenHIE as much as it is served by the product-publishing members of OpenHIE. User manuals and operating guides are needed for each of the HIE systems, and these need to be of commercial-grade quality. At some future time we might want to consider the completeness of the “product documentation” as one of our OpenHIE certification criteria alongside functional conformance. For group C, it will be important to be able to conformance-test and load-test their specific product configuration (the “project-a-thon” idea). There is an important risk-mitigation service our labs (MEDIC, HEAL, COIL) can play, here. My sense is that this work will be implementation-specific and should be funded out of the specific project’s budget. (E.g. the testing MEDIC did for the BID TZ implementation).

Sorry to be late to the party. I hope these comments are helpful.

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: ohie-sandbox@googlegroups.com [mailto:ohie-sandbox@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Tuesday, March 22, 2016 1:45 PM
To: ohie-sandbox@googlegroups.com
Subject: Re: OpenHIE demo strategy: What’s your opinion?

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

Regards
Carl Fourie

Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don’t get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne
surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn’t go
into the OpenHIE 1.0 release that we’re testing, or for some other reason…
But again, don’t take my word for this, I will re-check and confirm when
folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan’t on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the “story” could be told that
highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe – btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren’t seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment – please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne
surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i’d like to
hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing

How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google
Groups “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,
Suranga

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google Groups
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+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 “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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

ryan · April 4, 2016, 12:21pm

Hi all,

Thanks Suranga

I will join the call today to discuss further (Yay, daylight savings, the calls are back in my work hours!).

Cheers,

Ryan

···

On Mon, Apr 4, 2016 at 6:31 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

These are are some very important conversations and I agree with what Carl F has mentioned above. This has been a topic of great discussion within Jembi over the past months.

I feel that we don’t really need a ‘demo app’, what we really need is a reference, production quality PoC system just like we have for the other components of the OHIE architecture. This reference application could be setup in a demo mode along with the rest of the reference applications to provide a useful demo environment. With a fully implemented reference application setup in a demo environment we could address each of the groups mentioned above:

Group A (developers) - The reference PoC application would provide a starting point for HIE developers and show best practices and libraries that could be used to implement a PoC application. They could also learn how this hook into the OpenHIE workflows and even view the transaction that are executed in the demo environment via the OpenHIM.

Group B (implementers) - The reference PoC application in the demo environment could concretely demonstration the clinical use cases that we expect to support. This would allow ministry officials a live view of how OpenHIE could improve patient care.

Group C (Operators) - We would have to manage the demo environment ourselves so operators would benefit from the documentations and lessons that we learn in doing so. The demo environment could also be used as a teaching tool to train HIE operators.
In addition the reference PoC application and demo environment would allow us to:

Test each workflow that we develop

Test new versions of our reference applications

Introduce people to what can be accomplished by OHIE

Enable us to streamline our workflows and the standards that we use to make them more implementable (because we will have to implement a PoC ourselves)

Provide an out of the box HIE and PoC application that does something clinically relevant for those that don’t wish so start off doing development.

I know that I would love to work on a reference PoC application and the setup of a demo environment for OpenHIE. I think this would be extremely useful. What do other think of this? I believe that much of what has been discussed in this thread could be accomplished by focussing on this direction.

Cheers,

Ryan

On Thu, Mar 24, 2016 at 9:26 PM Ryan Yates ryan@openmrs.org wrote:

In regards to group C, what would be valuable to showcase? Automation tools, documentation, continuous integration tools? Or maybe how the environment is set up to host the sandbox? I want to know what others want to see as I am biased on what I think is important :).

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+unsubscribe@googlegroups.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 Sandbox” group.

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

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

–
Best Regards,
Suranga

On Wed, Mar 23, 2016 at 9:03 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga et al.

Suranga, I think group A’s needs will be served by things like re-usable, pre-built API components (in java, .NET, etc.) and code examples that illustrate how to use these. No one should expect to develop code from scratch; there are mature open source frameworks (http://cdatools.org/, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html, etc.) and we need to point developers to these and perhaps even start to cultivate “job aids” re: how to use them. Also, the existing IHE documentation regarding actor “behaviours” is fundamentally important and, to be honest, we need to do a much better job of ensuring potential system developers leverage these assets. IHE puts a lot of effort into these document sets and we should not expect to spend time/money to duplicate them (rather, we should “inherit” them). Lastly, my sense is that this “dev” group will need a live lab environment to play around in and we should make it easy for them to connect to MEDIC, HEAL and COIL.

Group B needs scenarios and we have a rudimentary start on getting some of these documented (https://hingx.org/Share/Attachment/2552?fileName=Live%20Demonstration%20-%20Digital%20Health%20for%20Better%20Care%20The%20Maternal%20and%20Child%20Continuum%20of%20Care%20Scenario.pdf&folderID=null). I don’t really think that this group should be “owned” by any particular POS application. Rather, the scenarios should describe particular care delivery narratives in terms of their transactions and enable these to be walked through using any POS systems that can connect to the HIE and play the necessary role. Where group A focuses on all the transactions that an actor can do (an SHR or a CR or whatever)… group B focuses on the series of transactions and actors that are needed to tell a health story. We have a few POS systems that we’ve already demo’d using this scenario-based idea (e.g. OpenMRS, OSCAR, GIIS, DHIS2, RapidPro, etc.) but the potential list of participants includes every system that speaks the necessary IHE transactions (and this is a loooooong list; http://product-registry.ihe.net/PR/home.seam).

Group C plays for keeps; these are the guys that need to operate live systems. To be blunt, this group is not served by OpenHIE as much as it is served by the product-publishing members of OpenHIE. User manuals and operating guides are needed for each of the HIE systems, and these need to be of commercial-grade quality. At some future time we might want to consider the completeness of the “product documentation” as one of our OpenHIE certification criteria alongside functional conformance. For group C, it will be important to be able to conformance-test and load-test their specific product configuration (the “project-a-thon” idea). There is an important risk-mitigation service our labs (MEDIC, HEAL, COIL) can play, here. My sense is that this work will be implementation-specific and should be funded out of the specific project’s budget. (E.g. the testing MEDIC did for the BID TZ implementation).

Sorry to be late to the party. I hope these comments are helpful.

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: ohie-sandbox@googlegroups.com [mailto:ohie-sandbox@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Tuesday, March 22, 2016 1:45 PM
To: ohie-sandbox@googlegroups.com
Subject: Re: OpenHIE demo strategy: What’s your opinion?

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

Regards
Carl Fourie

Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don’t get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne
surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn’t go
into the OpenHIE 1.0 release that we’re testing, or for some other reason…
But again, don’t take my word for this, I will re-check and confirm when
folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan’t on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the “story” could be told that
highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe – btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren’t seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment – please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne
surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i’d like to
hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing

How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google
Groups “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,
Suranga

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google Groups
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+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 “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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

ryan · April 4, 2016, 12:24pm

@Derek, just as a direct comment to your email: I agree, no one PoC will get us there, but two instances of a reference PoC will show user and interested parties a whole lot. As more OpenHIE compatible PoC implementations become available we could try host demo instances of these in the our environment to show true interoperability between disparate systems.

Cheers,

Ryan

···

On Mon, Apr 4, 2016 at 6:31 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

These are are some very important conversations and I agree with what Carl F has mentioned above. This has been a topic of great discussion within Jembi over the past months.

I feel that we don’t really need a ‘demo app’, what we really need is a reference, production quality PoC system just like we have for the other components of the OHIE architecture. This reference application could be setup in a demo mode along with the rest of the reference applications to provide a useful demo environment. With a fully implemented reference application setup in a demo environment we could address each of the groups mentioned above:

Group A (developers) - The reference PoC application would provide a starting point for HIE developers and show best practices and libraries that could be used to implement a PoC application. They could also learn how this hook into the OpenHIE workflows and even view the transaction that are executed in the demo environment via the OpenHIM.

Group B (implementers) - The reference PoC application in the demo environment could concretely demonstration the clinical use cases that we expect to support. This would allow ministry officials a live view of how OpenHIE could improve patient care.

Group C (Operators) - We would have to manage the demo environment ourselves so operators would benefit from the documentations and lessons that we learn in doing so. The demo environment could also be used as a teaching tool to train HIE operators.
In addition the reference PoC application and demo environment would allow us to:

Test each workflow that we develop

Test new versions of our reference applications

Introduce people to what can be accomplished by OHIE

Enable us to streamline our workflows and the standards that we use to make them more implementable (because we will have to implement a PoC ourselves)

Provide an out of the box HIE and PoC application that does something clinically relevant for those that don’t wish so start off doing development.

I know that I would love to work on a reference PoC application and the setup of a demo environment for OpenHIE. I think this would be extremely useful. What do other think of this? I believe that much of what has been discussed in this thread could be accomplished by focussing on this direction.

Cheers,

Ryan

On Thu, Mar 24, 2016 at 9:26 PM Ryan Yates ryan@openmrs.org wrote:

In regards to group C, what would be valuable to showcase? Automation tools, documentation, continuous integration tools? Or maybe how the environment is set up to host the sandbox? I want to know what others want to see as I am biased on what I think is important :).

–

You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+unsubscribe@googlegroups.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 Sandbox” group.

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

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

–
Best Regards,
Suranga

On Wed, Mar 23, 2016 at 9:03 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga et al.

Suranga, I think group A’s needs will be served by things like re-usable, pre-built API components (in java, .NET, etc.) and code examples that illustrate how to use these. No one should expect to develop code from scratch; there are mature open source frameworks (http://cdatools.org/, http://www.mohawkcollege.ca/ideaworks/MEDIC/Everest.html, etc.) and we need to point developers to these and perhaps even start to cultivate “job aids” re: how to use them. Also, the existing IHE documentation regarding actor “behaviours” is fundamentally important and, to be honest, we need to do a much better job of ensuring potential system developers leverage these assets. IHE puts a lot of effort into these document sets and we should not expect to spend time/money to duplicate them (rather, we should “inherit” them). Lastly, my sense is that this “dev” group will need a live lab environment to play around in and we should make it easy for them to connect to MEDIC, HEAL and COIL.

Group B needs scenarios and we have a rudimentary start on getting some of these documented (https://hingx.org/Share/Attachment/2552?fileName=Live%20Demonstration%20-%20Digital%20Health%20for%20Better%20Care%20The%20Maternal%20and%20Child%20Continuum%20of%20Care%20Scenario.pdf&folderID=null). I don’t really think that this group should be “owned” by any particular POS application. Rather, the scenarios should describe particular care delivery narratives in terms of their transactions and enable these to be walked through using any POS systems that can connect to the HIE and play the necessary role. Where group A focuses on all the transactions that an actor can do (an SHR or a CR or whatever)… group B focuses on the series of transactions and actors that are needed to tell a health story. We have a few POS systems that we’ve already demo’d using this scenario-based idea (e.g. OpenMRS, OSCAR, GIIS, DHIS2, RapidPro, etc.) but the potential list of participants includes every system that speaks the necessary IHE transactions (and this is a loooooong list; http://product-registry.ihe.net/PR/home.seam).

Group C plays for keeps; these are the guys that need to operate live systems. To be blunt, this group is not served by OpenHIE as much as it is served by the product-publishing members of OpenHIE. User manuals and operating guides are needed for each of the HIE systems, and these need to be of commercial-grade quality. At some future time we might want to consider the completeness of the “product documentation” as one of our OpenHIE certification criteria alongside functional conformance. For group C, it will be important to be able to conformance-test and load-test their specific product configuration (the “project-a-thon” idea). There is an important risk-mitigation service our labs (MEDIC, HEAL, COIL) can play, here. My sense is that this work will be implementation-specific and should be funded out of the specific project’s budget. (E.g. the testing MEDIC did for the BID TZ implementation).

Sorry to be late to the party. I hope these comments are helpful.

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: ohie-sandbox@googlegroups.com [mailto:ohie-sandbox@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Tuesday, March 22, 2016 1:45 PM
To: ohie-sandbox@googlegroups.com
Subject: Re: OpenHIE demo strategy: What’s your opinion?

Hi all,

Following up on this discussion-

(1) I can own group A; that can be my baby, and it’ll live on the OpenHIE demo environment. Work on this is finishing, and will be shared soon.

(2) Who owns group B, and where do they live? I’m assuming that someone from the OSCAR / OpenMRS communities will be responsible for their upkeep and management - but do they also belong in the OpenHIE demo environment? technically they could, but it would make the demo a bit crowded, to say the least

(3) Regarding group C, AKA Ryan Y’s group. If I understood correctly, we’re looking for a way to better understand how things happen under the hood inside the sandbox - but how is this different from the visualizer feature that already exists? are we talking specifically about a tool that offers performance stats? can you provide us with say a few sample scenarios on how we could/would use group C?

Best regards,

Suranga

Thanks and best regards,

Suranga Kasthurirathne

Regional Community manager (Asia-Pacific)

On Thu, Mar 17, 2016 at 3:41 AM, Carl Fourie carl@jembi.org wrote:

Great summary all and I agree with Bob and Scott on the introduction of group c and prioritization of b over a for now (I think the more “b” asks for things and understand the more “a” will be asking for the information they really need to get the job done).

Regards
Carl Fourie

Senior Program Manager

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.

On Thu, Mar 17, 2016 at 12:28 AM, Scott Teesdale steesdale@instedd.org wrote:

I would echo bob’s group C as being really important. And I would prioritize b, over a. Let us know if we can do anything to help here. Nice job Suranga.

Scott

On Mar 17, 2016, 5:31 AM +1100, Bob Jolliffe bobjolliffe@gmail.com, wrote:

Very good Suaranga.

Maybe its also worth considering there is a group (c) who are always
overlooked.

The ones who will manage the system, bring it to life in material form
and keep it going. CIOs, technical officers, sysadmins, network
admins etc

Groups (a) and (b) easily seduce one another, but they forget (c) and
things rapidly fall apart or don’t get started in the first place. I
suppose in a way the sandbox itself is the facilitator of this
seduction. Likes the systems-on-a-stick and demo systems of the past
which some folk will be familiar with from earlier WHO efforts. I
think probably the sandbox needs to also showcase itself (rather than
just the apps which are on it) in some way. To expose the hidden
labour of the likes of Ryan Yates and all.

To a group (c)

On 16 March 2016 at 19:15, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi everyone,

I’ve been contemplating demo strategy based on what Carl proposed, and I
want to suggest the following -

Loosely, we can break our demo audience into two groups - (a) developers/low
level implementers who want to understand how the system works, and look at
its underbelly (transactions, messages etc) and (b) high level
implementers/ministry/officials etc. who want to understand the clinical
relevance/value/impact

For group (a): Something thats designed more as a guide - as a teaching /
training tool - something that can be used to visualize transactions / show
folks where things failed and how messages travel etc.

For group (b): We need demo’s using existing tools/applications, such as the
ones involving OSCAR and OpenMRS - tools that demonstrate clinical
relevance, and working use cases, and can directly plug and play with
OpenHIE.

What do people think?

On Sat, Mar 12, 2016 at 4:27 PM, Suranga Kasthurirathne
surangakas@gmail.com wrote:

Hi there,

Thanks Carl,

Firstly, I think I should apologize over my early statement on the
performance of the IOL. They were raised before, and the Ryan C + Hannes
combination fixed that issue very promptly. I cant guarantee this, but I
believe that the delay still exists because either the changes didn’t go
into the OpenHIE 1.0 release that we’re testing, or for some other reason…
But again, don’t take my word for this, I will re-check and confirm when
folks return to office on Monday.

I’ll take note of your comment that ‘the app should rather show how
OpenHIE is consumed by an existing application(s) (not a new build, but one
that is for low resource settings if possible’.

I’m waiting to hear more comments, and we’ll discuss them in more detail
once we hear more opinions

On Thu, Mar 10, 2016 at 2:12 AM, Carl Fourie carl@jembi.org wrote:

Hi All

Thanks Suranga for “kicking the nest” here to get this going. We (Jembi)
have been thinking about this quite a bit and for sometime. I think
understanding fundamentally what we are trying to demonstrate is important.
I pretext this with the fact that I wan’t on the calls and have seen the
recordings. Suranga your POC demo seemed to focus on showing what OpenHIE
could provide to the POC - it was very focused at showing that you could get
information from OHIE but you had to know what it was you were looking at.

Personally I think we need to contextualize what OpenHIE provides within
a more clinical use case and show how it is / can be leveraged by tools
prevalent in the low resource settings environment within which we work. The
Mohawk demo/BALI demo/Maternal/RHEA/Medinfo2010 all focused around showing
how OHIE supports care and means that we can show just how OHIE impacts
health/clinical use cases. From our experiences in running the first demo
back in 2010 at Medinfo (learning from Mohawks team and their experiences) I
think the value that we had was that the tools that were shown could be
related to in the field systems and the “story” could be told that
highlighted OHIE’s (then RHEA/RHIE) deployment.

So again I come back to what are we wanting to demonstrate? I would
propose the following:
We need to have a sandbox which provides accessible data endpoints for
each of our OHIE workflows (that we have I believe – btw I want to better
understand why you think the IOL was the cause of the delay in your demo -
can we have a look at this? in our implementations we aren’t seeing it
responding that slowly and it is not a fair representation of the tool or
OHIE if it is doing that on our sandbox environment – please reach out to
us if this is the case we all need to succeed here). But more so we need to
guide people in following an illustrative use case for them to understand
how it all comes together. Right now you can maybe knock on OHIE to register
and resolve a patient but if we really want to show it we should say to ppl
if you consume XX endpoints you can see your system contributing to a
particular use case (maternal care for example). Having the wiring there is
one thing, we need to “juice” the system to make it meaningful.

Now all that on the page it brings us to “Demo App”.
My view is the app should rather show how OpenHIE is consumed by an
existing application(s) (not a new build, but one that is for low resource
settings if possible) in a particular workflow. We can focus on technical
documentation on “how to build your own app / link my app to OHIE”.

This is going to be a very valuable direction (if we are able to go this
way) as the implementer community comes to life as it will bring us down to
“real world” demonstrations.

Just my ZAR 0.02 and I hope it isn’t TLDR

Cheers

Regards
Carl Fourie
Senior Program Manager
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.

On Wed, Mar 9, 2016 at 7:39 PM, Suranga Kasthurirathne
surangak@openmrs.org wrote:

Hi all,

There has been some discussion on how OpenHIE as a community would like
to move forward with building / supporting demo systems.

During the sandbox call held on the 7th of March, Mohawk presented a
great demo of how the Oscar system integrated with OpenHIE. Prior to that, I
presented a separate demo POC app which was built from scratch (I.e. vendor
neutral).

During the meeting, we decided to discuss a common path ahead, and a
strategy of what we would like to see. To move this forward, i’d like to
hear your general input on the following:

Two very broad questions…

What is the purpose of the demo?
a. Help clinicians / implementers understand how the systems works
b. help implementers / devs understand how the interactions between
components work
c. Load / performance / application testing

How do we want to position this?
a. The demo app should be a neutral system that demonstrates how you can
built your own POC app
b. The demo app could be existing POC apps that are already used by
OpenHIE

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google
Groups “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-sandbox+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
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,
Suranga

–
Best Regards,
Suranga

–
You received this message because you are subscribed to the Google Groups
“OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-sandbox+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 “OpenHIE Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-sandbox+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 “OpenHIE Sandbox” group.

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

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