I think using synthetic data initially would be a useful way to test your stack for security and privacy concerns prior to using real data. I’m happy to discuss it more with those interested. In part this requires harmonizing the fake datasets already in use in the reference products. Synthea has a lot of promise and we at IntraHealth are proposing to work with it to generate millions of fake but realistic SHR for LMIC.
···
On Jul 27, 2018, at 10:49, Ryan Crichton <ryan.crichton@jembi.org> wrote:
Absolutely, so security should be considered from day one in an SHR implementation. Using the OpenHIE with an interoperability layer helps manage some of the security concerns however, there is no real way to fully mitigate risk as the HIE needs this information to function. One method that may help is to keep demographic details separately in the CR/MPI and link to a record in the SHR for clinical details. This means there would have to be two breaches to link medical data with identifiable data which would help. However, there would still be risk that the medical data still contains some information that could identify a patient.
The bottom line is that HIE infrastructure needs to be properly secured and perhaps as OpenHIE we should list some best practices on how to make that a reality.
Cheers,
Ryan
On Fri, Jul 27, 2018 at 9:38 AM Alvin Marcelo <admarcelo@up.edu.ph> wrote:
Dear Ryan,
The SHR therefore creates a tremendous risk for centralized storage of identifiable data? This poses a big challenge for LMICs...
Or is there a better risk-mitigated method?
Alvin
On Fri, 27 Jul 2018, 3:18 PM Ryan Crichton <ryan.crichton@jembi.org> wrote:
Hi Alvin,
I'l try answer were I can. The structure for the SHR will depend on the use cases being implemented but it is recommended to try use content profiles where possible that standardise the data that is captured and often structures it as a document such as a CDA document. Although, more recent HIEs are preferring to go the FHIR route and profiling FHIR for the implementation needs may be a more moderns way to go. It is also possible to consume documents in FHIR.
The data in the SHR is identifiable as it is designed to be the central store for a patient's medical records (or at least a summary of them) because of that it needs to be identifiable so that data can be queried for a particular patient. It also relies on their being an MPI/Client registry in place to be able to find that patient and resolve their identity.
ADX would be the preferred method to submit to the HMIS. The schema would be implementation specific in most cases and would need to be agreed on by the implementing partners.
Hope this helps.
Cheers,
Ryan
On Thu, Jul 26, 2018 at 3:20 AM Alvin Marcelo <admarcelo@up.edu.ph> wrote:
Dear architects,
I have a few questions and apologies if the answers are available somewhere and I have not done my homework (too busy hehe):
Is there a recommended structure of the SHR?
Are the data in the SHR identifiable or de-identified? why and why not?
How will the SHR submit data to the HMIS? is this via ADX? who defines the ADX schema?
TIA
On Fri, Jul 20, 2018 at 9:19 PM, Cox, Michelle Louise <miclcox@regenstrief.org> wrote:
The OpenHIE Architecture call scheduled for Friday, July 27 has been canceled since many people will be preparing for travel to the OpenHIE Community Meeting in Tanzania.
The next regularly-scheduled call will take place on Monday, August 13th.
Thanks!
Michelle Cox | Program Coordinator, Global Health Informatics
1101 West Tenth Street
Indianapolis, IN 46202
Tel 317-274-9324 | Fax 317-274-9305
Skype ID: miclcox | Facebook.com/regenstriefinstitute | www.regenstrief.org
My normal work hours are Monday – Friday, 7:15 a.m. – 4:00 p.m. Eastern Time
Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.
If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.
--
You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Alvin B. Marcelo, MD, FPCS, CGEIT, TOGAF, COBIT5 F/I, ArchiMate
https://orcid.org/0000-0001-6250-9169
--
Disclaimer:
This e-mail, together with any attachments, is intended for the named recipients only and is confidential. It may also be privileged or otherwise protected by law. If you have received it in error, please notify the sender immediately by reply e-mail and delete it and any attachments from your system. You may not copy or disclose its contents to anyone.
--
You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Ryan Crichton
Lead Developer
Jembi Health Systems NPC | SOUTH AFRICA
Mobile: +27
--
Ryan Crichton
Lead Developer
Jembi Health Systems NPC | SOUTH AFRICA
Mobile: +27
--
You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
