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

February 23rd 2010 Security Conference Call

From HL7Wiki
Revision as of 22:04, 27 February 2010 by Finaversaggi (talk | contribs) (→‎Agenda)
Jump to navigation Jump to search

Security Work Group Weekly Conference Call

Meeting Information

Attendees

Agenda

  1. (05 min) Roll Call, Approve Minutes Feb 16th, 2010 & Call for Additional Agenda Items
  2. (20 min) Harmonized Privacy and Security Peer Review

ACTIVE PROJECTS

  • (15 min) Security and Privacy Ontology project

Announcements

Minutes

1. Action Items

  • Team: Please provide feedback to the DRAFT Harmonized Security & Privacy DAM via the Peer Review process by COB March 4, 2010.

2. Resolutions- None

3. Updates/Discussion

Security and Privacy Ontology project

  • The Foundations & Technology Steering Division reviewed the Security & Privacy Ontology scope statement earlier today.
    • Mike and Steve presented the update scope statement and addressed the SD’s concerns.
    • The Steering Division approved the project.

Harmonized Privacy and Security DAM Peer Review

  • On Feb, 17, Ioana sent a message to the Security & CBCC Lists containing the DRAFT Harmonized Security & Privacy DAM within a link that included the following three documents. Today's meeting focused on the overview presentation:
  1. Overview presentation describing the changes to the Security DAM and elaborating the approach to harmonization
  2. The DRAFT Harmonized Security & Privacy DAM
  3. The Peer Review form designed to collect reviewer issues, comments and questions related to the document/artifact
  • Peer Review is intended to provide a light-weight review process in which reviewer comments are collected. The comments will be addressed in the disposition column. The Peer Review process is used to guide discussion in subsequent meetings which leads to common understanding and further refinement of the document
  • Since the last review of the Security DAM, major changes include harmonizing the classes, resolving overlaps/inconsistencies between the two information models and incorporating the definitions for all classes and attributes appearing in the Composite Privacy and Security DAMs into a single document
  • The harmonized Security & Privacy DAM attempts to delineate the two business viewpoints – security policy enforcement and privacy policy declaration – required to support authorization and access control in electronic health record systems
    • The Table of Contents organizes these viewpoints into separate sections which contain the class and attribute definitions specific to each viewpoint. In addition to Security and Privacy viewpoints, there is a third – Consent Directives – that identifies the classes/attributes required to represent the contents of a Consent Directive
    • The purpose of organizing the document this way is to clearly define the classes/attributes that are owned by each viewpoint
  • This document has attempted to resolve all the comments contained in the Security DAM ballot. If reviewers find there are comments that have not been addressed, please include them in the Peer Review
  • Richard questioned whether the original Privacy and Security DAMs have been deprecated as the result of the harmonization
    • The Privacy DAM is already DSTU, and therefore, this model does not nullify the Privacy DAM. The Harmonized DAM only attempts to clarify the Privacy and Security DAMs by bringing them together into a single artifact
  • This version of the new model is aligned with ISO 22600. An outstanding task is to align the model with ISO 15816 - Security Information Objects for Access Control, which will provide stronger definitions for attributes, something that we struggled with in the Security DAM ballot
  • What’s changed in the information models
    • Security Viewpoint: Role relationships changed and Organization is replaced by ProviderOrganization as a possible Grantee
    • Privacy Viewpoint: Identified JurisdictionalOrganization, Clearinghouse and Consenter classes as Privacy specific
    • The Consent Directive Viewpoint is an attempt to bridge the Privacy and Security Viewpoints. The model illustrates the relationship between declared consent directives and privacy policies from the Privacy viewpoint to the Security viewpoint
      • The Abstract Policy class cannot be instantiated; it identifies common properties of all policies. BasicPolicy and CompositionPolicy are the classes that can be instantiated
      • Consent Directives are realized as a ConstraintPolicy. Constraint policies include AuthorizationPolicies, ObligationPolicies, DelegationPolicies and RefrainPolicies
      • A Privacy Policy is realized as a CompositionPolicy
    • CompositionPolicy contains other policies, and CompositionPolicy itself is a Policy and has the properties of a Policy
    • ConsentDirective is not a specialization of ConstraintPolicy, but it is realized or implemented as a ConstraintPolicy so it can relate the Privacy and Security viewpoints
    • All the business use cases were brought into the model to provide better traceability from the classes and attributes to the use cases
    • For example, Figure 2 in the Security Use Case Analysis section is a modification to the existing diagram. This use case realization depicts the capabilities implemented by the Access Control System (ACS) and how those capabilities relate to the business requirements/use cases
    • Also new to the model are sequence diagrams to illustrate how the use cases would be implemented by conceptual systems
    • The Consent Directive Lifecycle diagram is a state machine diagram for a Consent Directive and is new to both Privacy and Security. It was added as background information in response to a comment in the Security DAM ballot. This is a good way to identify business triggers and is used to identify certain interactions that may need to be supported. The arrows represent state changes and the boxes represent allowed changes for the business objects
    • The last slide in the presentation compares the default policy against the consent directive issued by the patient and validates that the consent directive is consistent with the default policy

Feedback

  • Mike commented that in the discussions around Purpose-of-Use, a third viewpoint has been raised – that of the clinician’s perspective
    • There may be additional work to distinguish between the three viewpoints (Security, Privacy and Clinician) in an RM-ODP drawing to show where some of the artifacts or policies exist because there is transition between these viewpoints
    • A State Diagram might be a good way to conceptually represent this – to show how the information changes state from different viewpoints and through the lifecycle
  • Ioana agreed there is an implied third viewpoint : the provider perspective – when information is requested and certain roles and purpose of use are asserted. This viewpoint has not been elaborated on to date. We will include a diagram that shows how information has to be annotated so it can be correctly used and filtered by a clinical information system with the benefit of an Access control System into the harmonized DAM
    • A similar diagram was originally included in the Privacy DAM but was removed before balloting. We will take this as an action item to incorporate into the harmonized DAM.
  • This topic will remain on the WG agenda in the coming weeks
    • Next week’s meeting will take a deep dive on the Negotiate Policies use case: take it from the business definition to the required interactions and classes to ensure we have coverage
  • Many thanks to Ioana for all the hard work and for this presentation
  • Please submit your Peer Review comments to the list or Ioana/Serafina directly by March 4. Comments received will be incorporated and a new revision will take into account peer review comments, alignment with ISO 15816 and the additional clinician viewpoint so there will be significant changes in the next revision.
  • Serafina motioned to adjourn the Security meeting early; seconded by John with the caveat if additional people join at the top of the hour, we would revisit the next 15 minutes to fill them in

Meeting was adjourned at 1:45 PM EST No significant motions or decisions were made

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