New IHE profile allows patients more flexibility in expressing their privacy preferences.
This is a re-publication of an article that Tarik Idris from InterComponentWare and I co-authored. Originally posted on the ICW blog at 20.04.2017
The average size of electronic medical records grows each year. Some of the drivers of this growth are the increased utilization of EMR systems, scanning of paper records, and improved access to health information exchanges. As a consequence, patients need more sophisticated tools to adequately express their privacy preferences. When your medical record contains only a few x-rays and is only ever shared between your family doctor and your radiologist, a simple “yes” or “no” to data sharing may be sufficient to express your privacy preferences. But if your record contains family and social history, photos of skin conditions, STD panels, genetic information, and psychiatric evaluations and different parts of that record need to be accessed by a small army of physicians, surgeons, therapists and dental hygienists, you might need a more detailed method of defining your privacy preferences than “yes” or “no”.
Privacy preferences are commonly documented in a patient privacy consent document. The IHE profile BPPC (“Basic Patient Privacy Consents”) defined a common format for these consent documents. It is widely used, especially in projects sharing medical documents between different healthcare enterprises. BPPC was designed to cover cases where the patient has a simple choice between a handful of possible privacy policies. For example, the patient might choose between allowing all data sharing, only allowing sharing of summaries or only allowing sharing in case of emergency. The BPPC profile doesn’t determine what the choices are, it only requires that each choice that a patient is given has a unique identifier (“Privacy Policy Identifier”) and that there is some kind of access control system that knows what to do for each of those identifiers. The consent document only references the privacy policies (they are not expressed in a machine readable format as part of the consent document) and are just assumed to be understood by the recipient. BPPC was not designed for expressing fine-grained access rules, e.g. that a specific lab panel might only be viewed by a specific healthcare provider.
In light of this growing need for more sophisticated consent documents, the IHE IT Infrastructure Domain decided to define a new profile, IHE APPC (Advanced Patient Privacy Consents), that compliments BPPC by addressing additional use cases. Development of this profile started in late 2015 and was supported by an international group of stakeholders. The profile was published as a new “Supplement for Trial Implementation” in August 2016.
APPC’s focus is to enable automatic enforcement of consent documents. If a patient’s consent document states that facility X may not access his longitudinal record in an HIE, then the HIE should automatically deny access requests for this patient’s records coming from facility X. To enable this automatic enforcement, APPC includes a detailed, machine-readable, structured representation of the privacy policy. Whereas BPPC only included a reference to the privacy policy, APPC uses OASIS XACML (eXtensible Access Control Markup Language) to fully spell out the access control rules implied by the privacy policy. XACML is an XML-based domain specific language to unambiguously define access rules. This allows systems to implement an enforcement mechanism for these privacy policies by using one of several commercial or open source rules engines that can interpret XACML access rules.
We hope to empower both healthcare providers AND patients with the IHE APPC profile. Without a flexible language for defining access control rules for each project, vendors will force the same one-size-fits-all access control approach onto all healthcare providers, regardless of their specific needs. Using the IHE APPC profile, healthcare providers will be able to define an access control approach that fits their processes and their patient collective. E.g. pediatric oncology patients need their data available for regular follow-ups for a long time, whereas a surgery ER patient’s data could potentially be more ephemeral.
Patients will benefit by having a less monolithic approach to privacy preferences. While it is unrealistic that there will be completely different rules for each patient, there is a finite list of common customizations that can easily be implemented in an enforcement system based on IHE APPC. A common type of patient-specific customization is to blacklist specific providers (colleagues, relatives, former lovers, …) to deny them access to your patient record. Another common customization is hiding specific documents (e.g. drug testing results, psychiatric evaluations).
“The advantage for patients is the greater consideration of their individual needs.”
Of course in the grand scheme of things, technology, standards and products are just minor elements in arriving at a patient-friendly and efficient privacy scheme. Privacy laws and regulations, healthcare provider’s competitive landscape and association politics, liability laws, etc. usually have a greater impact on what the actual privacy choices for patients are. But when it is time to establish an agreed upon set of privacy policies in real world IT systems, it is important to have specifications like IHE APPC ready to enable an easy and cost-efficient implementation.
This is a re-publication of an article that Tarik Idris from InterComponentWare and I co-authored. Originally posted on the ICW blog at 20.04.2017
The average size of electronic medical records grows each year. Some of the drivers of this growth are the increased utilization of EMR systems, scanning of paper records, and improved access to health information exchanges. As a consequence, patients need more sophisticated tools to adequately express their privacy preferences. When your medical record contains only a few x-rays and is only ever shared between your family doctor and your radiologist, a simple “yes” or “no” to data sharing may be sufficient to express your privacy preferences. But if your record contains family and social history, photos of skin conditions, STD panels, genetic information, and psychiatric evaluations and different parts of that record need to be accessed by a small army of physicians, surgeons, therapists and dental hygienists, you might need a more detailed method of defining your privacy preferences than “yes” or “no”.
Privacy preferences are commonly documented in a patient privacy consent document. The IHE profile BPPC (“Basic Patient Privacy Consents”) defined a common format for these consent documents. It is widely used, especially in projects sharing medical documents between different healthcare enterprises. BPPC was designed to cover cases where the patient has a simple choice between a handful of possible privacy policies. For example, the patient might choose between allowing all data sharing, only allowing sharing of summaries or only allowing sharing in case of emergency. The BPPC profile doesn’t determine what the choices are, it only requires that each choice that a patient is given has a unique identifier (“Privacy Policy Identifier”) and that there is some kind of access control system that knows what to do for each of those identifiers. The consent document only references the privacy policies (they are not expressed in a machine readable format as part of the consent document) and are just assumed to be understood by the recipient. BPPC was not designed for expressing fine-grained access rules, e.g. that a specific lab panel might only be viewed by a specific healthcare provider.
In light of this growing need for more sophisticated consent documents, the IHE IT Infrastructure Domain decided to define a new profile, IHE APPC (Advanced Patient Privacy Consents), that compliments BPPC by addressing additional use cases. Development of this profile started in late 2015 and was supported by an international group of stakeholders. The profile was published as a new “Supplement for Trial Implementation” in August 2016.
APPC’s focus is to enable automatic enforcement of consent documents. If a patient’s consent document states that facility X may not access his longitudinal record in an HIE, then the HIE should automatically deny access requests for this patient’s records coming from facility X. To enable this automatic enforcement, APPC includes a detailed, machine-readable, structured representation of the privacy policy. Whereas BPPC only included a reference to the privacy policy, APPC uses OASIS XACML (eXtensible Access Control Markup Language) to fully spell out the access control rules implied by the privacy policy. XACML is an XML-based domain specific language to unambiguously define access rules. This allows systems to implement an enforcement mechanism for these privacy policies by using one of several commercial or open source rules engines that can interpret XACML access rules.
We hope to empower both healthcare providers AND patients with the IHE APPC profile. Without a flexible language for defining access control rules for each project, vendors will force the same one-size-fits-all access control approach onto all healthcare providers, regardless of their specific needs. Using the IHE APPC profile, healthcare providers will be able to define an access control approach that fits their processes and their patient collective. E.g. pediatric oncology patients need their data available for regular follow-ups for a long time, whereas a surgery ER patient’s data could potentially be more ephemeral.
Patients will benefit by having a less monolithic approach to privacy preferences. While it is unrealistic that there will be completely different rules for each patient, there is a finite list of common customizations that can easily be implemented in an enforcement system based on IHE APPC. A common type of patient-specific customization is to blacklist specific providers (colleagues, relatives, former lovers, …) to deny them access to your patient record. Another common customization is hiding specific documents (e.g. drug testing results, psychiatric evaluations).
“The advantage for patients is the greater consideration of their individual needs.” Of course in the grand scheme of things, technology, standards and products are just minor elements in arriving at a patient-friendly and efficient privacy scheme. Privacy laws and regulations, healthcare provider’s competitive landscape and association politics, liability laws, etc. usually have a greater impact on what the actual privacy choices for patients are. But when it is time to establish an agreed upon set of privacy policies in real world IT systems, it is important to have specifications like IHE APPC ready to enable an easy and cost-efficient implementation.
No comments:
Post a Comment