November 24th 2009 Security Conference Call

Security Work Group Weekly Conference Call

Attendees

• Bernd Blobel Security Co-chair, absent
• Kate Bolster
• Steven Connolly
• Mike Davis Security Co-chair
• Tom Davidson
• Suzanne Gonzales-Webb CBCC Co-chair
• Allen Hobbs
• Don Jorgenson
• Glen Marshall Security Co-Chair
• John Moehrke
• Milan Petkovic
• Pat Pyette
• Scott Robertson
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida
• Meno

Agenda

1. (05 min) Roll Call, Approve Minutes & Call for Agenda Items
2. (10 min) Harmonization Meeting outcome
3. (45 min) Security DAM Ballot Status - Walkthrough final content and Ballot Website

Minutes

1. Actions:

• Ioana/Team: Develop proposal to address the vocabulary issues around confidentiality.
  • Those interested are requested to continue discussion on the ListServ and via email
  • Report-outs to this group will be given periodically on the status.
  • An effort will be made to reach out to a broader group of participants to join in the discussion.
• Steve Connolly: To lead discussion on US-Realm value sets for Security DAM information model in an upcoming meeting

4. Updates/Discussion:

Harmonization Meeting

• Official result (from Harmonization Minutes)

1. Proposal initially approved by committee 8-5-2. Second motion raised by AMS (Patrick Loyd seconded) to reconsider 11-4-0.
2. New proposal: Change definition of Act.confidentialityCode and Role.confidentialityCode: Codes that identify how sensitive a piece of information is and/or that indicate how the information may be made available or disclosed.
3. OPEN ISSUE: The definition of this concept needs work in particular to help distinguish and identify the relationship between the types of concepts that it conveys and how best to encode and communicate by this one attribute.

• Strong resistance to the adding a new attribute due to:

1. Concern by HL7 Canada that the change would break many existing models
2. Harmonization issues with other standards (DICOM, IHE) which use existing confidentialityCode vocabulary

• A new sub-project of the Information Modeling effort will be undertaken by the Security and CBCC workgroups to help define the vocabularies necessary for Security and Privacy. This will involve harmonization across various HL7 concepts.

1. Identify existing vocabularies for other RIM attributes and figure a way to encode them within a single attribute.
2. Discussion should continue among those who are interested on the ListServ. Periodically there will be report-outs to this group based on the status of this effort.
3. Investigating the terminology/vocabularies will help to clarify what are the next steps. The process will cause us to take a look at a number of value sets where we may find attributes that already address our requirements. For example, Act.reasonCode already supports Purpose-of-Use, so we don't have to repeat purpose of use within Confidentiality.
   • Need to ensure this attribute can be sent in the envelope.
   • Need to be cautious the attributes we're looking for are not overloaded terms in use for different purpose than our intended use.

Security DAM and January 2010 Ballot Desktop Walkthrough

• Security DAM can be found on the left side of the Ballot Desktop page, under Domain Analysis Model on the Ballot Desktop or download the Security Domain Analysis Model from GForge.
  • A point of clarification about the location (and last update date) for the most current version. The document date from the link on the Security Wiki site indicates November 24th, while the date from the ballot desktop version is November 23rd.

1. The documents are identical except for the date format. The Wiki version date is displaying the date the document was opened (current date). The date format on the ballot site version reflects the actual last update date.
2. The document has been checked into Subversion, and change control in effect.

• Review the Security Policy Overview to see if there are missing classes (to support the use cases).
  • Many of the classes in the Security DAM are shared with classes in the Composite Privacy DAM. The descriptions of these shared classes is not repeated in the Security DAM; they reference the Composite Privacy DAM.
• There was a suggestion to add a narrative section explaining how the classes are used to fulfill each use case since there is little obvious difference in the use case diagrams.
  • This will be done in a future version. This is currently being balloted as Informative. Going forward, the plan is to ballot this DSTU where it will be harmonized with the Composite Privacy DAM.
  • The diagrams will be updated to highlight where classes are specifically called and a reference will be added in each use case to tie the concepts back to the classes in the diagram.
• As the Composite Privacy and Security DAMs move toward Normative (DSTU), how will conformance be measured?

1. A Domain Analysis is used for profiling other standards or for creating downstream platform-independent models.
   • Conformance to an analysis model is measured in traceability.
2. Don is balloting the SOA PASS-Alpha project as DSTU with the intent to go Normative. And PASS will include the Privacy and Security DAMs.
3. If intent is to ballot PASS-Alpha as Normative, should the content of the underlying models (Composite Privacy and Security DAMs) be included or should they be referenced?
   • The diagrams from the DAMs will be included in the Information Modeling section of the PASS project ballots. A statement will indicate that the diagrams are included for the reader's convenience, and a reference will point them to those documents. (The DAM's are still "Informative"; the stuff considered Normative will be the PASS Conformance Statements).
   • This implies that an Informative reference is being adopted as Normative.
   • Functional Model profiles have been balloted as Normative in the past.

• Steve Connolly is developing US-centric value sets for the classes contained in the Security DAM and will lead a discussion on value sets and the status of that development during next meeting
  • Steve's question: Are the value sets Normative and bound to the Informative model? Or will the value sets will become Normative once the information model becomes Normative?

1. There is some conflict because in many cases the classes are not RIM classes and are not fully developed
2. Depending on the target profile:
   • If the value set is applied to profiling other standards (XACML, SAML, etc.) you can ballot the terminology only and the value set would be based on HL7 normative vocabulary specifications.
   • If you're balloting an information model and a terminology, Ioana believes the information model has to be related to the RIM.
3. The RBAC Permissions catalog was balloted as an HL7 vocabulary standard without binding to the RIM.
4. HL7 recognizes external vocabularies in the definition of many standards (SNOMED, LOINC, etc.)
5. The outstanding question is: is the structure of an XML parameter type used in the PASS Access Control service allowed to be based on an Information Model that ISO-22600 published or on a model that is derived from some other RIM based model?
6. Need the flexibility to create profiles based on the Security information model, but to use value sets that are outside HL7. E.g., Structure roles in the US, might want to specify ASTM-1986.
7. Worse-case scenario there will have to be an effort to relate the Domain Analysis Model(s) to the RIM, which is a step that is worthwhile regardless of the ArB/TSC decision

Meeting was adjourned at 2:00 PM EST.

No significant motions or decisions were made.