On the HIT-Policy Tiger team meeting yesterday there was a wonderful presentation of some of the leading work in OASIS and HL7. This is emerging work that I am very excited about and very actively engaged with. I am not convinced that this work is ready for prime-time today, but will be in a few years. Fortunately this maturity was eventually discussed and exposed.
There was a question asked about how the Access Control engine gets access to the specific rules that a patient has agreed to in their consent. As part of this question there was statements that access to this Consent Content would include a laundry list of things that the patient wants hidden, such as "I don't want knowledge of my HIV Positive status known outside direct care team". This is an important point that policy content would expose that the patient might have some of these medical conditions.
One would hope that policy language is not as explicit as my example above, but rather would have groups of policy fragments that would be turned on/off universally across the whole population of patients in a policy-domain (region). Meaning that the patient is offered a common checklist that they use to express their interests. It is hoped that the patient finds enough expressibility in this set of checklists. It does not mean that this set of checklists ultimately make the results not-sensitive, but by everyone in a policy-domain making the same set of decisions there will be enough use of the policy fragments to make it less obvious that a patient is sensitive to HIV.
But even if checklists of policy fragments are used, there will be cases where a patient will want slightly different policies, and we all hope that there is a future where full expressible policy could happen (I figure 100 years should be enough). In this full expressible policy the patients special (non-checklist) rules could be directly encoded.
So, ultimately we do expect that the consent content could become sensitive. It might be because of a checklist selection of a policy fragment or could be because of expressed rules.
The solution was not discussed on the meeting, although the important topic was discussed a few hours earlier in the meeting. Consent Documents, especially those that contain sensitive topics, should leverage the very same segmentation capability that is used to isolate clinical content that has sensitive topics. In this way, only those that have the rights to have access will get access. Indeed if the Consent Document only contains rules that an access control service would understand then there should be a confidentialityCode that isolates these documents to only access control services.
I would further indicate that we often think of segmentation only in the context of the different levels of 'sensitive' clinical topics. This is too limited of a viewpoint of segmentation. Segmentation must also be very clear when a content (document) contains things like policy-rules/attributes that might be considered sensitive in some way (another topic is those content that contain financial identifiers). The other direction is also important for segmentation, we have often brought up the 'emergency data set' as needing to have a segmentation (confidentialityCode) that makes this data very widely accessible.
Reference blog article: 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.
Related Articles
Wednesday, June 30, 2010
Sunday, June 6, 2010
A Look into the UK breach statistics
This data looks very much like the USA data published by HHS outlined in A Look into the HHS Posts Data Breach Notifications. The biggest issues in both cases are hardware theft.
According to statistics from the Information Commissioner's Office (ICO), the UK National Health Service has reported 305 data security breaches since November 2007. During the same period, the private sector reported 288 breaches, local government reported 132 breaches, and central government reported 81 breaches. The most frequent cause of NHS breaches was hardware theft, which accounted for 116 incidents, followed by hardware loss, which accounted for 87 incidents. There were also 43 instances in which NHS information was disclosed improperly, 17 instances in which data were lost in transit, and 13 instances of improper technology disposal. In all, more than 1,000 data breaches have been reported to the ICO. In April the ICO was granted the authority to impose fines of up to GBP 500,000 (US $730,000) for serious data breaches.
- http://www.kable.co.uk/nhs-data-losses-information-commissioners-office-01jun10
- http://www.zdnet.co.uk/news/compliance/2010/06/01/nhs-top-culprit-as-uk-data-breaches-exceed-1000-40089098/
- http://www.ico.gov.uk/upload/documents/pressreleases/2010/1000_data_breaches280510.pdf
- http://www.ico.gov.uk/upload/documents/library/corporate/research_and_reports/breach_notification_spreadsheet_may2010.pdf
University of Louisville kidney patient data was available to public
This is a case of a Doctor believing that the tool he used protected the data. This seems to me a case where making something too easy results in failure. The fortunate thing is that it is unlikely anyone else noticed.
The information was available so long because the U of L doctor who set up the Web site thought the information was protected by a password and other precautions, Hebert said."It was just a mistake," Hebert said. "It was his understanding it was password protected." More
Subscribe to:
Posts (Atom)