This call went out publicly on Monday (see below) and I was already pre-signed up. I have been involved with this topic for many years. I am disappointed that the introduction to this topic treats it as a ‘persistent privacy issue’. Although it does seem to be a persistent privacy issue, the persistent aspect has more to do with unwillingness than a lack of ability to provide consumer controls. I will totally agree that the security community, including myself, don’t do enough to explain how to do this.
I have blogged on the topic in the past many times. At first the “Data Segmentation” phrase threw me off. This is a term that security community uses to describe something different. Data Segmentation is the process of carving out extremely sensitive information and keeping it physically isolated from common data. I thus wrote: Data Classification - a key vector enabling rich Security and Privacy controls. This did quite a bit of good to help the community understand “Data Classification”, and has resulted in a new understanding of ‘confidentialityCode’. Proposal for confidentialityCode vocabulary
This is only one of the problems that is included in the topic of “Data Segmentation”, embedded inside is the issue of how a patient can express their privacy policy or constraints; and how that can be enforced. To me this is a very different problem, and would never be seen by a security professional as related to “Data Segmentation”. This is not to say that Security doesn’t have a solution. It is just known as Privacy Policy. In fact the solution to this need has very little to do with the Data. I have tried to express multiple times that Privacy Policy otherwise known as Constraints are not ‘metadata’. Could an architecture consider them metadata, sure it could but it would result in a fragile and non-scalable solution. One Metadata Model - Many Deployment Architectures, Data Objects and the Policies that Control them, ConfidentialityCode can't carry Obligations
Capturing the Privacy Policy (aka Consent, Obligations, Constraints), how to encode it, communicate it, and manage it in a way that holds up to legal challenges. We have some Stepping stones for Privacy Consent, while still developing advanced consents. IHE - Privacy and Security Profiles - Basic Patient Privacy Consents, Consent Management using HITSP TP30, The meaning of Opt-Out, Opt-In, Opt-Out.... Don't publish THAT!, Consent standards are not just for consent, Consumer Preferences and the Consumer, and RHIO: 100,000 Give Consent.
We even have some actual work done by some Health Information Exchanges - Draft Affinity Domain Policies
I look forward to helping the community understand. I commit to doing a better job of explaining how this is done in a standards based way that is robust, can be implemented in multiple deployment architectures, and is scalable.
I have blogged on the topic in the past many times. At first the “Data Segmentation” phrase threw me off. This is a term that security community uses to describe something different. Data Segmentation is the process of carving out extremely sensitive information and keeping it physically isolated from common data. I thus wrote: Data Classification - a key vector enabling rich Security and Privacy controls. This did quite a bit of good to help the community understand “Data Classification”, and has resulted in a new understanding of ‘confidentialityCode’. Proposal for confidentialityCode vocabulary
This is only one of the problems that is included in the topic of “Data Segmentation”, embedded inside is the issue of how a patient can express their privacy policy or constraints; and how that can be enforced. To me this is a very different problem, and would never be seen by a security professional as related to “Data Segmentation”. This is not to say that Security doesn’t have a solution. It is just known as Privacy Policy. In fact the solution to this need has very little to do with the Data. I have tried to express multiple times that Privacy Policy otherwise known as Constraints are not ‘metadata’. Could an architecture consider them metadata, sure it could but it would result in a fragile and non-scalable solution. One Metadata Model - Many Deployment Architectures, Data Objects and the Policies that Control them, ConfidentialityCode can't carry Obligations
Capturing the Privacy Policy (aka Consent, Obligations, Constraints), how to encode it, communicate it, and manage it in a way that holds up to legal challenges. We have some Stepping stones for Privacy Consent, while still developing advanced consents. IHE - Privacy and Security Profiles - Basic Patient Privacy Consents, Consent Management using HITSP TP30, The meaning of Opt-Out, Opt-In, Opt-Out.... Don't publish THAT!, Consent standards are not just for consent, Consumer Preferences and the Consumer, and RHIO: 100,000 Give Consent.
We even have some actual work done by some Health Information Exchanges - Draft Affinity Domain Policies
I look forward to helping the community understand. I commit to doing a better job of explaining how this is done in a standards based way that is robust, can be implemented in multiple deployment architectures, and is scalable.
From: S&I Framework Admin [mailto:admin@siframework.org]
Sent: Monday, September 19, 2011 12:52 PM
To: undisclosed-recipients
Subject: Call for Participation - Data Segmentation
Sent: Monday, September 19, 2011 12:52 PM
To: undisclosed-recipients
Subject: Call for Participation - Data Segmentation
Call for Participation
Office of the National Coordinator for Health Information Technology (ONC)
Data Segmentation Initiative
The Office of the National Coordinator for Health Information Technology (ONC) Offices of the Chief Privacy Officer and Standards and Interoperability are launching an initiative to address standards for the ability to exchange parts of a medical record (often called data segmentation).
As announced by ONC in a recent post to the Health IT Buzz Blog:
“This project aims to make progress on the persistent privacy issues raised in the PCAST report. The goal of this project is to enable the implementation and management of health information disclosure policies originating from a patient’s request, statutory and regulatory authority or organizational disclosure requirements.
The project aims to examine and evaluate the standards needed for sharing individually identifiable health information (including standards recommended by the Health IT Standards Committee through the use of metadata tagging of privacy attributes in standard clinical and policy records and record segments). The initiative will develop use cases that define the current need for data protection services, such as a patient’s directive not to disclose substance abuse records in accordance with 42 CFR Part 2, and will then extend current standards-based software models to demonstrate interoperability. Testing will be based on a reference model aligned with a set of use cases and functional requirements developed by the S&I community.”
Dr. Farzad Mostashari, National Coordinator for Health Information Technology
On behalf of ONC, I am pleased to announce and invite your valued participation in the launch of the Data Segmentation Initiative. This initiative takes place under the auspices of the ONC Standards & Interoperability Framework in conjunction with the Office of the Chief Privacy Officer.
Meeting logistics and reference materials are posted on the ONC Data Segmentation wiki page: http://wiki.siframework.org/Data+Segmentation
If you would like to volunteer to participate in the Data Segmentation Initiative, please review the documentation on the S&I Framework wiki: http://wiki.siframework.org/Getting+Started+as+a+Volunteer. Once you have read through the material regarding participation, levels of commitment, guidelines for participation and voting rights, please sign up to participate in the Data Segmentation Initiative by completing the registration form at: http://wiki.siframework.org/Data+Segmentation+Sign+Up
The official launch of the Data Segmentation Initiative will be held on October 5th from 1:00 – 2:30 pm EST with opening remarks from myself and Dr. Doug Fridsma (Director of the Office of Standards and Interoperability), a brief overview by Johnathan Coleman (Data Segmentation Initiative Coordinator), and a presentation by Melissa M. Goldstein, JD on the Whitepaper released by ONC in September 2010 entitled, “Data Segmentation in Electronic Health Information Exchange: Policy Considerations and Analysis,” available at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__privacy_and_security/1147. Details on the Data Segmentation launch including web meeting access and call in information are posted on the wiki: http://wiki.siframework.org/Data+Segmentation . In addition, we will host Data Segmentation breakout sessions at the S&I Framework Face-to-Face Meeting, October 18-19, 2011 at the Hyatt Regency-Crystal City in Arlington, Virginia.
Your perspectives, expertise and experiences are critical to the success of this initiative and we look forward to your participation on the Data Segmentation Initiative.
Joy Pritts, JD
Chief Privacy Officer
Office of the National Coordinator for Health IT
Chief Privacy Officer
Office of the National Coordinator for Health IT
John, thanks for raising this important topic. There are two areas that merit consideration: Data Annotation (to avoid the term segmentation, which may be misleading) and Consent Management.
ReplyDeleteBy data annotation, I refer to the process of marking up a set of records to indicate which records correspond to particular topics (such as mental health) and information categories (such as medications). These annotations can be provided independently of any particular privacy policy.
A consent management system merges a set of privacy policies, including laws mandated by governmental agencies, rules adopted by health care providers and preferences specified by patients. These policies should reference the same set of annotations used above.
Then, when a particular data exchange is contemplated, the current policy (as provided by the consent management system) is compared against the available annotations. Only those records allowed by the policy are shared.
In this manner, the same annotations can be used regardless of the privacy policies in play at a particular time. And, the patient can express her/his consent preferences once and need not be asked to sign off on every data exchange (this is especially important for coordinating care, which may involve dozens of exchanges).
Peter, nicely said. The additional thing I am adding is the risk around these annotations. I am not trying to bring the risk to zero, just trying to bring it as close as possible while still providing enough 'annotations' for the policies to operate off of.
ReplyDelete