This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

December 15th 2009 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Work Group Weekly Conference Call

Meeting Information

Attendees

Agenda

  1. (05 min) Roll Call, Approve 12/1 Minutes & Call for Agenda Items
  2. (55 min) Report-Outs:

Minutes

1. Actions

Team: Please review the Security DAM Value sets documents and provide input/feedback in preparation for special joint Security/CBCC meeting on January 5

2. Resolutions

  • None

3. Announcements

  • 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)

4. Updates/Discussion

Security DAM Value Sets

Steve presented the two draft documents: Excel spreadsheet & Word document

Context:

  • 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:
  1. Perfect fit: The value sets meet the need for describing the coded attribute
  2. 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
  3. 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:

Attachment 2: The purpose of this table is to provide a "map" to better understand some of the terms that are used to describe aspects of Privacy Policy. This table is being shared by the HL7 Security & CBCC, SOA Workgroups and HITSP.

  • Concepts are defined in the left hand column, for example:
    • Subject of information content
    • Person(s) owning a privacy policy
    • 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.
    • Consent Directive is equivalent to Privacy Preferences, which is equivalent to what a patient would say, is my personal privacy policy (that is being submitted)
  • 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.
  • To get from a person's privacy preferences (Consent Directive) to an agreed upon organizational privacy policy (a Consent Directive that can be enforced), it is more confusing to create a new term for the outcome of the negotiation process. The patient/person has to agree to the outcome of the negotiation to make this a contract.
  • 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.
  • The secondary organization could see the final result of the primary negotiation, and the secondary organization could see the policy of the first organization as a preference. However, what's on the wire from the first organization is a negotiated privacy policy.
  • 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!

Retrieved from "https://wiki.hl7.org/w/index.php?title=December_15th_2009_Security_Conference_Call&oldid=30556"