DATA Access and Integrity within the HIE

[Carl Fourie]

Thanks for raising these questions Craig,

I'm curious from the team members, what are the current patterns of managing data integrity and access  within the OpenHIE implementation or other HIE implementations? If not implemented what patters are we designing around.

I'm curious as to how others are managing the scenario that Craig outlined below?

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 Mon, May 16, 2016 at 6:08 AM, Craig A <ca...@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'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.

 

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:

- 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.

--
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/a62ed55a-0e2e-4f0f-bfda-58bcaeec208f%40googlegroups.com.

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

[Alvin Marcelo]

Hi Carl,

In the Philippines (Philippine Health Information Exchange -- not running in production yet), things got shaky when the whole voter database was breached. Suddenly, the eHealth technical working group decided there was too much risk to have a separate client registry and decided to put the interop layer and CR inside PhilHealth (national health insurance payer). The rationale was that PhilHealth had the equipment and human infrastructure to secure it plus it was their mandate to store personal information (not the MOH).

Having said that, even months before the breach, there was already a lot of back and forth between the MOH and PhilHealth on how data will be shared. I thought that was a huge gap in the OpenHIE framework -- that the partners were groping in the dark "now that we can share all our data via OpenHIE -- what do we share?"

Was there a wiki page for this that I missed? a framework for data sharing?

But then again, is data sharing/access/ownership actually part of an OpenHIE discussion or more a separate political one?

alvin

Alvin B. Marcelo

Pls update your address book with my new email address - adma...@up.edu.ph

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWg%2BMmZQbcsa-%3DfthZEzUWEUsb%2BAijMgxXEGfvz94SHKTQ%40mail.gmail.com.

[Pierre Dane]

hi all, 

I think this is a great question and requires some serious discussion. I am not aware of any guidelines around this and I have seen that control of data is a very sensitive subject, even when not taking the legal side of things into account. 

everyone generally assumes that their data is better than everyone else's so it's quite a messy space. 

one model that I have seen is that ALL data is accepted by the HIE and then there is some logic in the CR that decides after the fact which record is the most correct, and a full audit log is kept. But this doesn't really conform to the current openHIE workflows. 

I think these kinds of decisions will also need to be taken by each ministry that own the HIE, specifically to each POC implementation. it gets more complicated when importing batches of data from other systems (lab,pharmacy) that are sometimes used to bootstrap registries. 

Pierre

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWg%2BMmZQbcsa-%3DfthZEzUWEUsb%2BAijMgxXEGfvz94SHKTQ%40mail.gmail.com.

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

--

Pierre Dane

Jembi Health Systems

Software Development Manager

tel: +27 (0)21 701 0939

cel: +27 (0)83 680 8274

email: pie...@jembi.org

web: www.jembi.org

[Carl Fourie]

Adding Derek's email to this

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.

---------- Forwarded message ----------
From: Derek Ritz <derek...@ecgroupinc.com>
Date: Fri, May 20, 2016 at 3:58 PM
Subject: Re: [ohie-implementers] DATA Access and Integrity within the HIE
To: Pierre Dane <pie...@jembi.org>
Cc: Carl Fourie <ca...@jembi.org>, "OpenHIE Implementers Network (OHIN)" <ohie-imp...@googlegroups.com>, Shaun Grannis <sgra...@regenstrief.org>

Hi all.

The care delivery network where I live (Ontario, Canada) is mandated that all members of the care delivery network must actively co-own the CR database record. This is easy for the government to mandate because, here, we have a single-payor system and the client ID is connected to the health insurance plan. This provides a very strong monetary incentive for the care providers.

The mechanism for co-ownership is that, at each presentation for care, the subject is asked to confirm that the demographic data is "current". To do this, subject is asked: "are you still at 123 Anyplace Street?" and "is your phone number still 555-1212?" and so on. If the demographic data have changed, the new data is captured at the point of care system and this is updated to the CR.

I have attached a PPT deck from ~4 years ago that was prepared to inform the CR project in Rwanda. I'm sad to say that this isn't how we implemented OpenEMPI (Shaun, you can maybe confirm this?)... but in my view the "golden record with golden key" method is crucial to enjoying success in a broadly-scaled CR implementation. There is also a high-level discussion of this idea here: https://vimeo.com/152392600 (and videos 1 and 2 in this series can be found here: https://vimeo.com/151342311 and here: https://vimeo.com/156650602, if folks are interested). Please note, these videos are still going thru their final edits... so they are not yet available from the AeHIN website.

I hope this info is helpful to our discussion. (Carl... could you please forward this email to the google group... i'm getting a "no access" reply when i try to. thanks.)

Warmest regards,

Derek.

--

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

[Derek Ritz]

sorry... membership is sorted now... re-posting this to the google group... (please see below)

---------- Forwarded message ----------
From: Derek Ritz <derek...@ecgroupinc.com>
Date: Fri, May 20, 2016 at 9:58 AM
Subject: Re: [ohie-implementers] DATA Access and Integrity within the HIE
To: Pierre Dane <pie...@jembi.org>
Cc: Carl Fourie <ca...@jembi.org>, "OpenHIE Implementers Network (OHIN)" <ohie-imp...@googlegroups.com>, Shaun Grannis <sgra...@regenstrief.org>

Hi all.

The care delivery network where I live (Ontario, Canada) is mandated that all members of the care delivery network must actively co-own the CR database record. This is easy for the government to mandate because, here, we have a single-payor system and the client ID is connected to the health insurance plan. This provides a very strong monetary incentive for the care providers.

The mechanism for co-ownership is that, at each presentation for care, the subject is asked to confirm that the demographic data is "current". To do this, subject is asked: "are you still at 123 Anyplace Street?" and "is your phone number still 555-1212?" and so on. If the demographic data have changed, the new data is captured at the point of care system and this is updated to the CR.

I have attached a PPT deck from ~4 years ago that was prepared to inform the CR project in Rwanda. I'm sad to say that this isn't how we implemented OpenEMPI (Shaun, you can maybe confirm this?)... but in my view the "golden record with golden key" method is crucial to enjoying success in a broadly-scaled CR implementation. There is also a high-level discussion of this idea here: https://vimeo.com/152392600 (and videos 1 and 2 in this series can be found here: https://vimeo.com/151342311 and here: https://vimeo.com/156650602, if folks are interested). Please note, these videos are still going thru their final edits... so they are not yet available from the AeHIN website.

I hope this info is helpful to our discussion. (Carl... could you please forward this email to the google group... i'm getting a "no access" reply when i try to. thanks.)

Warmest regards,

Derek.

On Fri, May 20, 2016 at 4:49 AM, Pierre Dane <pie...@jembi.org> wrote:

--

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

[Shaun Grannis]

Important topic - thanks for the great discussion!

From my perspective, both 1) technical and 2) policy/procedural strategies are needed to ensure that the data privacy and security requirements are met for each HIE implementation.

As we begin the "privacy and security journey", I wanted to folks know that in order to support those goals, the OpenHIE community needs your help to:

1) Clearly communicate the technical privacy and security features that the OpenHIE framework supports today,

2) Create and communicate a road-map for new technical features that are needed by the community, and

3) Support implementers in assessing their context to determine HIE privacy and security needs.   

 

We would love your feedback from implementers regarding your existing privacy and security challenges and how OpenHIE can better support your needs.

 

We welcome any input you have to offer.  

 

Best,

 

Shaun

----
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)      
(317) 274-9305 (Fax) 

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BKPT%2BhgTHwVvaxbo0c%3D8TWGfPcLoPFsTD%2BoRy9PGDyX9g%40mail.gmail.com.

[Shaun Grannis]

Hi Alvin,

While we have the basic substrate for items #1 and #2, we always welcome feedback from the community. As we document the current state and roadmap, we hope to get your feedback.

Regarding #3, we are exploring a few informative related references and appreciate any additional references / perspectives the community has.

Best,

Shaun

On Wed, May 25, 2016 at 7:10 PM, Alvin Marcelo <adma...@up.edu.ph> wrote:

Thanks for this Shaun. I presume #1 and 2 will emanate from the core team.

For #3, are there frameworks implementers can use to help explicitate their privacy contexts? We can introduce this to the privacy expert group here for deliberation...

Alvin

[Carl Fourie]

Thanks All for starting this thread and Shaun for the "3 areas" I've taken the liberty to create 2 stubs on the OHIN wiki page (can be found in the Quick Links box on the Right of the page) [https://wiki.ohie.org/display/SUB/OpenHIE+Implementers]

- OpenHIE Privacy and Security (link): a page to help coordinate the OHIE Privacy and Security features and current discussions (it needs to still be built out) - Shaun can we get some guidance from the Architecture team on this too please -- I know it is a topic for the call on friday

- Implementers Features Request (link): a place for implementers to list out the feature requests of OpenHIE for the communities to engage around.

Cheers

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.