IHE Security and Privacy for HIE
This page is deprecated. This paper has been included in and replaced by the Health Information Exchange: Enabling Document Sharing Using IHE Profiles white paper.
Deprecated
Media:Example.oggThis is a work approved as a IHE ITI Planning Committee white paper. This work was originally proposed as the IHE Response to Markle Principles white paper. The scope has changed over a few IHE ITI Planning Committee meetings. The current scope is to show the IHE Solutions to Security and Privacy challenges of building a Health Information Exchange (HIE). See below for meeting minutes and scheduled meetings.
Current Draft
The proposed public draft (July 22, 2008). (see below for working drafts)
This security model is built around XDS (XDS.a and XDS.b) leverages the security profiles ATNA, Consistent Time, BPPC, PWP, EUA, and XUA.
A video was created at 2007 HIMSS demonstration that shows the IHE Security in action. http://www.ihe.net/Scenarios/security.cfm
Privacy and Security at HIMSS 2008 Demonstration technical details.
July 22, 2008
ITI technical committee reviewed and approved for external publication.
The Diff since the 7-7-08 version
July 15, 2008 -- Webinar
I presented on the IHE Webinar on the IHE Security and Privacy model.
July 7, 2008 -- White Paper Draft
Next call to discuss is July 22, 2008 at the IHE ITI Technical Committee face-to-face meeting in chicago Minutes_Nov_2007_-_Sep_2008#Agenda_Jul_21-25
June 18, 2008 -- Notes from meeting
Known Issues that I need help coming to a solution:
- Need to show better how confidentialityCodes work.
- This is still confused with consent
- This is done through document labels that can be specific to Patient, Document, Event/episode, Time, intended use, etc.
- Complex confidentialityCodes are also beyond the current state of the art.
- Show that the assignment of a confidentialityCode is simply identifying the type of data in the document. This does not fix the privacy/security policies.
- Actual access control is based on many factors including the confidentialityCode.
- Confidentiality Code is independent from classCode. classCode describes the document content to clinical use. confidentialityCode describes the document content for security and privacy purposes. A simple system might have direct maps, this would not be true all the time.
- Access Controls
- Need to do a better job of explaining how access controls are minimally enforced, but also how through the use of XUA they can enable more centralized control.
- Add clarifications around all the places that Access Control can be addressed and to what degree IHE supports/enables this and where we currently see gaps
- Access Control at the Repository – Doesn’t know patient associated with the document, thus can only apply RBAC type permissions based on an XUA assertion.
- Possibly after current 3.2 section, possibly a sub-section.
- Need a good reference to Appendix L or what ever it is called today and in the future.
- Template for XDS Affinity Domain Deployment Planning – White Paper
- http://static.ihe.net/Technical_Framework/upload/IHE_ITI_White_Paper_XDS_Affinity_Domain_Template_TI_2007_08_15.pdf
- Likely need to promote current section 3.4... new section 4.
- Need to have a more complete example that wraps authentication, RBAC, confidentialityCode, Consents, and current conditions (break-glass). This example would pick some overall policy, some consent policies, some confideniality Codes, and some users with roles. Explaining how this might be enforced at the edge system, and how XUA can enable centralized support. Then explain how the centralized support is not complete as it doesn't have enough information to be complete. (Mick will help with this).
- comments are expected via email
Next publication on July 7th.
Next review at the ITI Technical Face-to-face with expected approval for publication.
Some text I have written for emails that might help:
I do want to mention that the confidentialityCode 'inside' the CDA does NOT need to correlate to the confidentialityCode found in the XDS Metadata. It can coorelate. I might have a deterministic rule. The main reason for this to be considered independent is that the confidentialityCode inside the CDA document is relative to the process/workflow that generated the document. If the purpose for the document is to publish into a document sharing environment, then the codes are likely to be the same. But, when the document is re-purposed into a document sharing system, it will then be labeled with broader codes understood by the broader community. This re-purpose should NOT modify the original CDA document as that would be a modification.
The other miss-understanding that I have heard of lately around confidentialityCode is what it means. In the same way that doctype defines what the document is in terms of the clinical/administrative content, the confidentialtiyCode defines what the document is in terms of privacy/security content. For example although it might seem obvious that all ECG type documents are all likely to be the same from a privacy/security point of view, this should NOT be presumed. A more specific example is that a medical summary document could easily contain observations that would fall into 42-CFR-Part-2 (sensitive topics), where as for the vast majority of medical summary documents don't. Another example would be where a patient has requested that a specific report be handled more sensitive. Other example is an emergency data set that the patient wants made available to the widest possible audience. Only the publishing system knows this. The important point is that the confidentialityCodes should be looked at as more static assessment of the document content privacy/security characteristics.
Some have confused confidentialtiyCode with consents. These are totally different concepts. Access Controls are where all of the values including confidentialityCode, consents, user-role, permissions, and situation. Consents likely have rules around documents with specific confidentialityCodes, but the binding of the rules to the codes is done in the Access Control step. The confidentialityCode is not the appropriate place to put dynamic rules. To be a little more clear, there has been confusion around how the Document Source chooses the confidentialityCode. The confidentialityCode that is placed on a document at publication should be based on the document content, not based on current consents (there are exceptions, but they are very edge cases).
June 10, 2008 -- White Paper Draft
Next call to discuss is June 18, 2008.
April 7, 2008 - Presentation to CalPSAB
March 28, 2008
There is concern that this is a rather technical white paper to be published by the planning committee. Should this actually be owned by the technical committee?
Notes
- Introduction
- Tell about the flow of the paper
- Goal
- Audience tips
- Technical - Higher level view of security, national initiatives
- Technical people can use this to present the solution to management
- Introduction to technical concepts of security
- Policy vs Technology -- we are trying to fill a gap
- answer "But how does this fix security?"
- Tell about the flow of the paper
- Policy
- Remove much of this.. there is simply too much discussion on policy
- Break-Glass
- Really need either more information on this topic, or need to point to external
- section 2.3
- Move this to section 3.3
- add physical controls
- add authenticity
- add incident response -- business continuity and remediation
- add some category for firewalls and antivirus like solutions (not clear what this category is)
- Section 3.1
- remove reference to PHR, make it an example
- need more should encouragement
- Need more discussion on preventative vs reactive security and how they are related on a continuum
- around line 250 - list out how ATNA actually satisfies this
- Section 3.2
- need a drawing
- Futures
- need more detail
- Might be good to re-use the Table 1, and include futures
- need to include more identified gaps since original release (HITSP)
- Break out by
- Implementations of this security model (Karen and Manuel will provide)
- Gaps and roadmap
- need more detail
comments from email May 29
explain that we are only giving further details on the 'direct' relationships. The indirect relationships shown in the table are not explained.
comments from t-con May 28
- Change the first diagram: Replace HITSP with Medical Professional Society
- Change the first diagram: echosystem to environment
- Change the second diagram: promulgate policies
- add indirect relationships to table
- text around apparent superficial policy conflicts (race and records retention)
- text in futures section around data mining --> de-identification
- other minor
comments from face-to-face meeting in Chicago May 18th
I have integrated comments received after the ITI Technical Committee meeting on May 18th. The above draft is ready for review on May 29th to be released for Public Comment.
comments from Maryann
I have integrated some very good comments from Maryann and added the content discussed at the face-to-face.
face-to-face at the IHE Tech meeting May 15
Edits were done to the draft and uploaded to the FTP. See current draft above.
- Bring back the introduction to the OECD principles, explaining that they inform policies, risk assessment, and technical controls
- Need diagram early to show relationship between policies and controls
- Need matrix that shows technical controls to the IHE profiles
- Try to add text around PHR. Given the XPHR profile...
- More formally recognize our gaps in a section prior to the conclusion.
Update -- April 13, 2007
I received the Policy section from Glen, and some comments from Karima.
The current draft (April 13, 2007).
Minutes - April 11, 2007
Attendance: John, Rob, Chris, Tyrone, Glen, Larry, and Vassil
Rob was concerned that we don't spend enough time explaining that IHE doesn't set Policies, we enable policies and their enforcement. IHE is a global organization and thus needs to respond to 50+ government policies and regulations. We need to make it clear that there is a difference between setting policy and enabling policy
Tyrone is very concerned that given the IHE scope we will not be able to adequately address the OECD principles. This was echoed by John and others. The conclusion was that we should remove the principles from the paper and change the scope to a more general security and privacy technical controls.
Larry offered that when we write the policy section, that we don't simply indicate that IHE doesn't address policies, but rather help our reader with some pointers to known organizations that are working on policies. We should also help our reader understand why policies are out of scope. He gave the example of scalability.
Glen offered to help author the section on Policy.
With the exception of the new edits to the Policy section, the other discussed changes have been integrated into the current draft (April 11, 2007).
January 29 t-con of the IHE ITI Planning Committee
It was strongly suggested that IHE must address a more global audience. This may best be done by addressing the OECD Principles on Data Protection.
I do have a concern that we need to hit the Markle Principles strong as they are influencing decision makers. A quick and decisive discussion is necessary. If this paper is too big, or takes too long it will have very little impact.
- Is there a need outside the USA for this type of response to Healthcare Consumer Principles?
IBM has offered up as predicate white paper http://www.almaden.ibm.com/cs/projects/iis/hdb/Publications/papers/vldb02_hippocratic.pdf
Tyrone Grandison (IBM) will co-edit with John Moehrke (GE Healthcare)
Lori will see if members of the ISO TC 215 committee want to add their personal knowledge and opinion to this IHE effort. This would be distinct from any ISO work.
The group felt that including OECD with a Markle focus for USA may satisfy both the USA and Global community.
Layout options:
- One Document with 2 parts -- OECD and Markle
- One Document that addresses the OECD principles with sub discussions on mapping to Markle
- Two documents
Detail: Yes we want to be specific on the technology solution that IHE offers, but we must do a better job of bridging the principles to the technology solution than is found in the original draft submitted.
January 31 discussion with Chris and Tyrone
Outline
- Introduction -- There are well understood and agreed to global principles to data protection that do apply to healthcare.
- OECD Data Protection Principles
- sprinkle in the Markle cross-walk
- Matching of OECD principles to IHE profiles
- Conclusion -- IHE Profiles can address Data Protection Principles including those from Markle
Chris and Tyrone will work on the outline, Introduction, and layout of OECD principles
John to fill in the IHE profile details
Meeting each Wednesday at 11:00 Central time
Targeting HIMSS with the understanding that this is very much a stretch goal.
Comments
Contact the editor JohnMoehrke@gmail.com with any comments, suggestions, or criticism.