December 1st 2009 Security Conference Call

Security Work Group Weekly Conference Call

Attendees

• Bernd Blobel Security Co-chair, absent
• Tom Bonina
• Andre Carrington
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Allen Hobbs
• Rob Horn
• Rob McClure
• John Moehrke
• Milan Petkovic
• Pat Pyette
• Scott Robertson
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida
• Craig Winter

Agenda

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

• Ioana/Team: Confidentiality/Sensitivity vocabulary analysis (20 min) ListServ messages
• Steve Connolly: US-Realm value sets for Security DAM Information model (35 min)

Minutes

1. Actions:

• Team: Please review Security DAM Value Sets (01/04/2010) for discussion next week
• Mike: Will develop a draft document that provides a set of standards-based definitions for concepts that are within the confidentialityCode value set. These will be definitions that we will use moving forward. (this action item does not yet have a due date assigned)
  • If others have suggested sources or definitions already written, please email to Mike for incorporation into the draft
  • Steve Connolly, Tony Weida and Rob McClure will provide input as well
  • The draft will be used in upcoming meetings to refine the harmonization proposal

4. Updates/Discussion:

Confidentiality/Sensitivity Vocabulary

Outcome of the proposal in the Harmonization meeting was not completely clear.

• The original submitted proposal was not accepted
  • We agreed not to change the existing confidentialityCode structure so there would be no impact existing implementations
  • Other standards (e.g., DICOM) also refer to confidentialityCode
• There is a recognized need to describe additional attributes that describe privacy and security
  • Current confidentiality codes do not cover the entire scope of what is needed to express security and privacy
• To address the need for vocabulary for security and privacy with respect to confidentialityCode, a holistic approach will be taken. Rather than looking at just one aspect of confidentialityCode, the approach will look at the whole picture
  • Make concepts consistent where possible
  • There are multiple, orthogonal value sets which are being merged into confidentialityCode (and we are constrained by this decision)
  • Therefore an internal structure is required to make things semantically understandable and to provide for interoperability
• Use ISO as the basis to identify all the attributes necessary to sufficiently express Security and Privacy and that are needed to apply to a document
  • A review of ISO 10181-3 reveals some attributes which can be found in confidentialityCode, but other attributes are found in different RIM artifacts, e.g., Purpose of Use, Role
  • For example, the concept, Purpose of Use is represented by Act.Reason. There is a privacy related concept domain in the Act.Reason coding system. There are also other overlaps with the confidentialityCode value set
  • In reviewing the HL7 RIM, be aware of overloaded vocabulary that does not quite express our needs
• Our analysis may result in new security and privacy use cases that support the need to split out the concepts of sensitivity and confidentiality from confidentialityCode
• Doesn't matter whether the concepts are split out or merged together, more important is whether the information meets the needs of security and privacy.
• Throw away the vocabulary and think about the functionality
  • Label something with something. Read the label and the security system applies a policy against a set of attributes and makes the decision.
• Document the approach and gain agreement from Harmonization as to whether we are solving the right problem and have the right approach.
• Mike will develop a draft document that provides a set of standards-based definitions for concepts that are within the confidentialityCode value set. These will be definitions that we will use moving forward. (this action item does not yet have a due date assigned)
  • If others have suggested sources or definitions already written, please send them to Mike to incorporate into the draft
  • The draft will be used in upcoming meetings to refine the harmonization proposal
• Confidentiality is a process that acts on the labels of sensitivity
• Another term that was proposed: Access code
  • This is different from sensitivity or confidentiality because it's used by the Access Control system which only needs a code to make a decision based on a number of other attributes (patient id, user, etc)
• Proposed that the draft begins with the following definition:
  • Confidentiality code is an access control code based upon the cultural and policy needs for confidentiality and control of sensitive information.
  • This definition will be followed by definitions/descriptions for confidentiality, sensitivity and other attributes, and will put the entire approach into the ISO context
• The information models that describes the relationship among concepts is more powerful than describing the terms themselves

Security DAM Value Sets DRAFT

Steve Connolly provided a brief overview of the draft value sets and will send out to the CBCC and Security ListServ so members can review this week and we'll discuss at greater length next week

• Classes taken from the Security and Privacy DAMs
  • Exercise was to bind appropriate value sets to these classes
• Work from left column to the right
  • Column B is the coded attribute associated with the class (e.g., grantee has no coded attribute so it is blank)
  • Classes generally all come from the Security and Privacy class diagrams. Exception is Composition policy where the attributes were derived from Berndt and Mike's paper
  • Column C: The next step is to identify the concept domain associated with the coded attributes
• Concept domains were identified from sources that are contained in the second worksheet (Sources)
• Some ambiguity in the general meaning of the concept domain
  • E.g. Role, Organizations
  • There are often multiple value sets associated with a coded attribute
• Looking for guidance in terms of getting a more specific definition of what the attribute is intended to represent
• HITSP C80 was used as the basis for creating this spreadsheet
• It makes sense to define additional value sets for security and privacy since the existing ones may be larger than are necessary for our purpose.
  • You can create a value set that is a subset that is more relevant a particular domain (security/privacy)
• Result of this process so far:
  • Have identified some ambiguities in the definitions of some attributes
  • Some value sets that have not yet been identified, so looking for suggestions
• Identify value sets that are applicable to specific attributes in the Security domain analysis model and clarify the purpose for identifying these value sets
  • Who is responsible for developing the subset list of value sets for Security and Privacy?
  • Value sets are useful for illustrating the domain analysis models
  • In HL7 process, it's only later on that specific value sets are chosen for use in documents and messages
• What is the context in which we are discovering value sets?
  • Come up with a value set that is useful for US security policies
  • To make this international, look at ISO and IHE, where there is overlap, err on the side of internationalization
• Discussion to be continued next meeting

Meeting was adjourned at 2:11 PM EST.

No significant motions or decisions were made.