December 15th 2009 Security Conference Call
Security Work Group Weekly Conference Call
- Bernd Blobel Security Co-chair, absent
- Tom Bonina
- Steven Connolly
- Mike Davis Security Co-chair
- Suzanne Gonzales-Webb CBCC Co-chair
- Don Jorgenson
- John Moehrke
- Milan Petkovic
- Pat Pyette
- Richard Thoreson CBCC Co-chair
- Serafina Versaggi scribe
- Tony Weida
- Craig Winter
- (05 min) Roll Call, Approve 12/1 Minutes & Call for Agenda Items
- (55 min) Report-Outs:
- Mike: Security Vocabulary Harmonization (25 min)
- Team: Security DAM Value Sets (30 min - continued from Dec 1 meeting)
Team: Please review the Security DAM Value sets documents and provide input/feedback in preparation for special joint Security/CBCC meeting on January 5
- Security DAM Value Sets spreadsheet, latest update 01/04/2010
- Security DAM Value Sets companion document, latest update 01/04/2010 (30 min - continued from Dec 1 meeting)
- Holiday Schedule: 12/22 & 12/29 Meetings are canceled
- We will reconvene January 5 at 1:00 PM EST for a two-hour Security Value Sets discussion (Joint with CBCC WG)
Security DAM Value Sets
Steve presented the two draft documents: Excel spreadsheet & Word document
- These draft documents represent an instance of the information model applied to the US domain.
- The code sets contained in the spreadsheet are US-domain code systems. We are not undertaking a Tier-2 analysis to determine which are the most useful. This is an inventory of existing systems.
Process for Review:
- Columns A (Class) & B (Coded Attribute) in the Excel spreadsheet are from the Security DAM Class diagram and represent the highest level of abstraction. As you move to the right, the columns further describe the code systems and value sets that can be used to bind to the coded attributes
- The coded attributes are those listed in the Security DAM Information Model, which is the basis for understanding the intent of the coded attribute
- The Word document expands on the spreadsheet in more detail.
- It contains all the concepts in the value sets
- The value sets fall into three categories:
- Perfect fit: The value sets meet the need for describing the coded attribute
- In between: The fit may not be perfect - at present, this may be due to not understanding the concepts contained within the coded attribute, or because the coded attribute is unique. Most of the value sets listed fall into this category
- Gap: There are no known concept domains that can be bound to the coded attribute
- While reviewing the value sets, please identify any significant gaps or forced fits
- The guiding philosophy in the Security DAM analysis has been to specify non-health care specific standards or existing external (non-HL7) health care specific standards that are already established for these concept domains
- If there is more than one source, HL7 should not constrain to any one particular code set. If there are existing sources, we will not invent a new one. Developing a new HL7 code set is the measure of last resort.
- If existing code sets cannot be identified after further analysis, these coded attributes will be identified as gaps
- A theme call will be scheduled for January 5 to go over this document in more detail.
- We will use the time currently allocated to the normal HL7 Security and CBCC working group calls, and dedicate the two hours to work through the process as a group.
- We can present that work at the face-to-face meeting in Phoenix
Security Vocabulary Harmonization
Mike presented a Privacy Harmonization Table:
- Concepts are defined in the left hand column, for example:
- Subject of information content
- Entity authorized to act on behalf of patient
- Across the top are entities which may have different terms or "perspectives" for these various concepts:
- HL7, HITSP, ONC, NHIN, Persons/People, Organization, Canada
- Attachment 3: contains a diagram that depicts some of the systems involved in the creation, management and enforcement of privacy policies.
- We have had a lot of discussion about the issue that patients submit what they would like (privacy preferences) and what is ultimately agreed upon by an organization and becomes enforced policy (the outcome of negotiation)
- If you start with Consumer Privacy Preferences, from the HL7 perspective we use the term Consent Directive.
- In the SOA group's reference model for Access Control is a management layer where policies are validated and accepted (based on the outcome of the patient/organization negotiation).
- Once the terms are accepted they go to the Security Management layer and can be enforced by a Security engine.
- You can deal with the transformation or state change going from my privacy preferences to a real and enforceable policy in a few ways
- One way is to define new vocabulary for the change in state
- Another, is to acknowledge that a state change may occur and there may be some negotiation between the organization and the person/patient
- This recommendation states rather than defining new words for the state change, we leave the term purposely ambiguous.
- The business of harmonizing with policy is a function, but we're still dealing with consumer preferences.
- TP30 does not address the concept of Consent Directive and the state change very well. It's very conflicted.
- The proposal is: don't create new vocabulary. There is process involved (negotiation), but we're talking about what can be enforced. This negotiation is with a single organization, which implies the person/patient has to make this negotiation with multiple organizations.
- There is an implication that if the policies pass from one organization to another, it is not the raw policy that is being passed, but the policy that the organization and patient have reconciled - a real policy.
- Will the recipient organization know that this is a negotiated privacy preference or not?
- The state transition must be clear
- There is no negotiation between the primary and secondary organizations.
- Once "preferences" have been reconciled (consumer preferences and organizational/jurisdictional policy), it just becomes policy soup. The engine doesn’t care where this came from.
The meeting was adjourned at 2:15 PM EST. The next time the Security Work Group will meet is Tuesday, January 5, 2010.
Happy New Year!