Wiki Content - What are we missing!?

Legacy ohie-implementers
,
1

Good day all

As our introductions start kicking up it is a good time to start asking some questions of the growing network. The first is:

"What are we missing?" - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions

There is a page on the wiki - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions with some initial ideas and we would encourage the network to discuss these here on the list and make suggestions.

Looking forward to the feedback (here and wiki)

···

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

2

Hi Carl,

I have a few items for group discussion:

  • I feel that there are two distinct groups of implementers. The first focuses on implementing the OpenHIE infrastructure (everything above OpenHIM). The second group focuses on implementing to integrate the point of service with OpenHIM. This second group includes finding benefit from OpenHIE from point of service systems like OpenMRS, CommCare, ODK, etc.

  • It would be good to identify key assumptions when implementing OpenHIE. For example, I think we assume that a Point of Service application should be connected to the internet to gain real-time benefit from OpenHIE. What should we assume about data access, modifying records and recommending workflows when things go wrong?

  • Should we integrate with the Sandbox team to build a reference implementation of a point of service workflows in relation to the OpenHIE v1.0 release?

Sincerely,

Craig

···

On Tuesday, May 10, 2016 at 11:22:20 PM UTC-7, carl wrote:

Good day all

As our introductions start kicking up it is a good time to start asking some questions of the growing network. The first is:

“What are we missing?” - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions

There is a page on the wiki - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions with some initial ideas and we would encourage the network to discuss these here on the list and make suggestions.

Looking forward to the feedback (here and wiki)

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

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.

3

Hi Craig

Great to have you weighing in here.

I think you have a good point here about the different types of implementers - are you looking at this from a technical level of those who need to “wire up” the tools primarily or a more holistic approach as from “what governance and agreements do we need in place to implement a central HIE”? I think there is definitely scope for us to understand what both groups would be looking to get from OpenHIE and what information they would find most useful.

I’ve added a heading on the wiki page for the assumptions you list here. I’m wondering what you are thinking around the concept of DATA ACCESS? is this how OpenHIE allows data access or what data is accessible by who, how to configure etc?

With the concept of workflows for when things go wrong is the thought here within the software or more SOPs for real world persons?

WRT to the sandbox question I think this is something that we should definitely consider and we would want to unpack what the thinking is around here. Some of the previous discussions in the Sandbox community have been around what types of reference / demo features would be useful for implementers to see and be of value. At this stage it has come down to options around:
(i) A reference OpenHIE that exposes all the workflow endpoints that interested PoC’s can knock against to see how one could contribute towards being part of, say, a Maternal Use Case and that shows how OHIE manages the data (showcasing the OHIE architecture in action)

(ii) A reference PoC that is able to consume and contribute to the OHIE workflows (showing how a PoC could leverage the OHIE functionality to advance its implementation or network of implementations)

How does this fit with what you were thinking?

A lot of questions here, Craig your email has a great mine of conversation starters, and it would be great to get input from others on these too.

···

On Wed, May 11, 2016 at 7:39 PM, Craig A cappl@grameenfoundation.org wrote:

Hi Carl,

I have a few items for group discussion:

  • I feel that there are two distinct groups of implementers. The first focuses on implementing the OpenHIE infrastructure (everything above OpenHIM). The second group focuses on implementing to integrate the point of service with OpenHIM. This second group includes finding benefit from OpenHIE from point of service systems like OpenMRS, CommCare, ODK, etc.
  • It would be good to identify key assumptions when implementing OpenHIE. For example, I think we assume that a Point of Service application should be connected to the internet to gain real-time benefit from OpenHIE. What should we assume about data access, modifying records and recommending workflows when things go wrong?

Sincerely,

Craig

On Tuesday, May 10, 2016 at 11:22:20 PM UTC-7, carl wrote:

Good day all

As our introductions start kicking up it is a good time to start asking some questions of the growing network. The first is:

“What are we missing?” - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions

There is a page on the wiki - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions with some initial ideas and we would encourage the network to discuss these here on the list and make suggestions.

Looking forward to the feedback (here and wiki)

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/7eac3f08-3ead-4303-b6aa-101263cbecc4%40googlegroups.com.

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

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

4

Hi folks,

I thought I would weigh in as well.

Greetings, I’m new to Jembi and HIE, but not new to healthcare, HIE or eHealth. If you are interested in knowing more about me I include my LinkedIn reference in my signature.

I like the ideas that are coming to fruition. Myself and Carl have started to add some content to the Wiki (Log In - OpenHIE Wiki), but in reading the comments here, we may need to rethink the content structure and flows to provide people with a better way of navigating the content and storyboard of HIE and interconnected data sources and health information systems (e.g. EHRs).

Maybe a smaller working group could compile the elements that are expressed in this forum, and then propose a structure and flow through the Wiki?

Cheers, Brian

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

LinkedIn: http://www.linkedin.com/in/mrbrianarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

···

On Tuesday, May 10, 2016 at 11:22:20 PM UTC-7, carl wrote:

Good day all

As our introductions start kicking up it is a good time to start asking some questions of the growing network. The first is:

“What are we missing?” - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions

There is a page on the wiki - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions with some initial ideas and we would encourage the network to discuss these here on the list and make suggestions.

Looking forward to the feedback (here and wiki)

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

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.

5

Hi Carl,

I’ll answer the questions inline

Hi Craig

Great to have you weighing in here.

I think you have a good point here about the different types of implementers - are you looking at this from a technical level of those who need to “wire up” the tools primarily or a more holistic approach as from “what governance and agreements do we need in place to implement a central HIE”? I think there is definitely scope for us to understand what both groups would be looking to get from OpenHIE and what information they would find most useful.

Craig: Many point of service systems aren’t setup to interact with a live HIE and there will need to be significant technical development to integrate new HIE workflows in these Point of Service Systems. For example, it would be great if OpenMRS could query OpenHIE when a new patient is being registered to see if there is an existing registration in the HIE. This would require some type of hook in their registration app that does the query. But what happens when there’s no internet connection? What workflows do implementers need to perform on their systems to accommodate the HIE? Do we need to cache data for offline use?

Additionally, the OpenHIE 1.0 workflows require a point of service system to speak a number of IHE standards like PDQ and XDS. It would be really good to map human workflows like “register patient” “Provider Encounter” etc. to these standards to it’s easy for an implementer to evaluate the technical merit of an existing system they’re planning to adopt. This could also inform gaps in the OpenHIM mediators, or represent a clear use case for implementing MOTECH between the POS system and OpenHIM.

I’ve added a heading on the wiki page for the assumptions you list here. I’m wondering what you are thinking around the concept of DATA ACCESS? is this how OpenHIE allows data access or what data is accessible by who, how to configure etc?

Craig: I attended an Interop Layer community call last month where we discussed informed consent. It got me thinking about central government ownership of the HIE and mandated use. It makes sense for all health providers in a given geographic area to be required to interact with the HIE. Let’s say INGO 1 works in the country and is now mandated to push data to the HIE. Are there generalized workflows we can share that would reduce the burden of adoption for this INGO? For example, what happens in OpenHIE implementations when there’s a conflict between the data in the HIE and the data in a Point of Service provider’s system? Who owns that data and how can the POS provider ensure data quality in this scenario? Is it a best practice to create duplicate records? I feel that there is a lot of operational knowledge in OpenHIE deployments that could benefit the community.

With the concept of workflows for when things go wrong is the thought here within the software or more SOPs for real world persons?

WRT to the sandbox question I think this is something that we should definitely consider and we would want to unpack what the thinking is around here. Some of the previous discussions in the Sandbox community have been around what types of reference / demo features would be useful for implementers to see and be of value. At this stage it has come down to options around:
(i) A reference OpenHIE that exposes all the workflow endpoints that interested PoC’s can knock against to see how one could contribute towards being part of, say, a Maternal Use Case and that shows how OHIE manages the data (showcasing the OHIE architecture in action)

(ii) A reference PoC that is able to consume and contribute to the OHIE workflows (showing how a PoC could leverage the OHIE functionality to advance its implementation or network of implementations)

How does this fit with what you were thinking?

Craig: I feel that both of these are appropriate. I think it would be a big win for the implementer communities if we could demonstrate a clinical point of service system like OpenMRS interacting with OHIE as well as a handset application an software system like CommCare or OpenSRP. Each of these have different workflows and benefits from interacting with OpenHIE. We’ll also be able to address offline interaction, syncing and data caching (if appropriate).

···

On Thursday, May 12, 2016 at 12:32:06 AM UTC-7, carl wrote:

A lot of questions here, Craig your email has a great mine of conversation starters, and it would be great to get input from others on these too.

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

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, May 11, 2016 at 7:39 PM, Craig A ca...@grameenfoundation.org wrote:

Hi Carl,

I have a few items for group discussion:

  • I feel that there are two distinct groups of implementers. The first focuses on implementing the OpenHIE infrastructure (everything above OpenHIM). The second group focuses on implementing to integrate the point of service with OpenHIM. This second group includes finding benefit from OpenHIE from point of service systems like OpenMRS, CommCare, ODK, etc.
  • It would be good to identify key assumptions when implementing OpenHIE. For example, I think we assume that a Point of Service application should be connected to the internet to gain real-time benefit from OpenHIE. What should we assume about data access, modifying records and recommending workflows when things go wrong?

Sincerely,

Craig

On Tuesday, May 10, 2016 at 11:22:20 PM UTC-7, carl wrote:

Good day all

As our introductions start kicking up it is a good time to start asking some questions of the growing network. The first is:

“What are we missing?” - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions

There is a page on the wiki - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions with some initial ideas and we would encourage the network to discuss these here on the list and make suggestions.

Looking forward to the feedback (here and wiki)

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/7eac3f08-3ead-4303-b6aa-101263cbecc4%40googlegroups.com.

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

6

Hi Craig

Thanks for the responses, I think the best to do here is to split them out into different threads and see how things evolve from there - I’ll be sending out new threads shortly.

···

On Mon, May 16, 2016 at 6:08 AM, Craig A cappl@grameenfoundation.org wrote:

Hi Carl,

I’ll answer the questions inline

On Thursday, May 12, 2016 at 12:32:06 AM UTC-7, carl wrote:

Hi Craig

Great to have you weighing in here.

I think you have a good point here about the different types of implementers - are you looking at this from a technical level of those who need to “wire up” the tools primarily or a more holistic approach as from “what governance and agreements do we need in place to implement a central HIE”? I think there is definitely scope for us to understand what both groups would be looking to get from OpenHIE and what information they would find most useful.

Craig: Many point of service systems aren’t setup to interact with a live HIE and there will need to be significant technical development to integrate new HIE workflows in these Point of Service Systems. For example, it would be great if OpenMRS could query OpenHIE when a new patient is being registered to see if there is an existing registration in the HIE. This would require some type of hook in their registration app that does the query. But what happens when there’s no internet connection? What workflows do implementers need to perform on their systems to accommodate the HIE? Do we need to cache data for offline use?

Additionally, the OpenHIE 1.0 workflows require a point of service system to speak a number of IHE standards like PDQ and XDS. It would be really good to map human workflows like “register patient” “Provider Encounter” etc. to these standards to it’s easy for an implementer to evaluate the technical merit of an existing system they’re planning to adopt. This could also inform gaps in the OpenHIM mediators, or represent a clear use case for implementing MOTECH between the POS system and OpenHIM.

I’ve added a heading on the wiki page for the assumptions you list here. I’m wondering what you are thinking around the concept of DATA ACCESS? is this how OpenHIE allows data access or what data is accessible by who, how to configure etc?

Craig: I attended an Interop Layer community call last month where we discussed informed consent. It got me thinking about central government ownership of the HIE and mandated use. It makes sense for all health providers in a given geographic area to be required to interact with the HIE. Let’s say INGO 1 works in the country and is now mandated to push data to the HIE. Are there generalized workflows we can share that would reduce the burden of adoption for this INGO? For example, what happens in OpenHIE implementations when there’s a conflict between the data in the HIE and the data in a Point of Service provider’s system? Who owns that data and how can the POS provider ensure data quality in this scenario? Is it a best practice to create duplicate records? I feel that there is a lot of operational knowledge in OpenHIE deployments that could benefit the community.

With the concept of workflows for when things go wrong is the thought here within the software or more SOPs for real world persons?

WRT to the sandbox question I think this is something that we should definitely consider and we would want to unpack what the thinking is around here. Some of the previous discussions in the Sandbox community have been around what types of reference / demo features would be useful for implementers to see and be of value. At this stage it has come down to options around:
(i) A reference OpenHIE that exposes all the workflow endpoints that interested PoC’s can knock against to see how one could contribute towards being part of, say, a Maternal Use Case and that shows how OHIE manages the data (showcasing the OHIE architecture in action)

(ii) A reference PoC that is able to consume and contribute to the OHIE workflows (showing how a PoC could leverage the OHIE functionality to advance its implementation or network of implementations)

How does this fit with what you were thinking?

Craig: I feel that both of these are appropriate. I think it would be a big win for the implementer communities if we could demonstrate a clinical point of service system like OpenMRS interacting with OHIE as well as a handset application an software system like CommCare or OpenSRP. Each of these have different workflows and benefits from interacting with OpenHIE. We’ll also be able to address offline interaction, syncing and data caching (if appropriate).

A lot of questions here, Craig your email has a great mine of conversation starters, and it would be great to get input from others on these too.

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

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, May 11, 2016 at 7:39 PM, Craig A ca...@grameenfoundation.org wrote:

Hi Carl,

I have a few items for group discussion:

  • I feel that there are two distinct groups of implementers. The first focuses on implementing the OpenHIE infrastructure (everything above OpenHIM). The second group focuses on implementing to integrate the point of service with OpenHIM. This second group includes finding benefit from OpenHIE from point of service systems like OpenMRS, CommCare, ODK, etc.
  • It would be good to identify key assumptions when implementing OpenHIE. For example, I think we assume that a Point of Service application should be connected to the internet to gain real-time benefit from OpenHIE. What should we assume about data access, modifying records and recommending workflows when things go wrong?

Sincerely,

Craig

On Tuesday, May 10, 2016 at 11:22:20 PM UTC-7, carl wrote:

Good day all

As our introductions start kicking up it is a good time to start asking some questions of the growing network. The first is:

“What are we missing?” - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions

There is a page on the wiki - https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions with some initial ideas and we would encourage the network to discuss these here on the list and make suggestions.

Looking forward to the feedback (here and wiki)

Senior Program Manager | Digital Health Division

Regards
Carl Fourie
Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/7eac3f08-3ead-4303-b6aa-101263cbecc4%40googlegroups.com.

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/a62ed55a-0e2e-4f0f-bfda-58bcaeec208f%40googlegroups.com.

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

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.