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

November 17th 2009 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Work Group Weekly Conference Call

Meeting Information

Attendees

Agenda

This week's Security Call extended two hours. Minutes within represent both Conference Calls and agendas have been combined

  1. (05 min) Roll Call, Approve Minutes & Call for Agenda Items
  2. (15 min) Announcements
  3. (70 min) Security DAM draft peer review
  4. (30 min) PASS-Alpha project update

Minutes

1. Actions

  • Team: The Security DAM draft has been submitted for peer review in preparation for the January 2010 Informative ballot.
  • Security & CBCC Co-Chairs: Please attend the HL7 Harmonization meeting by conference call to vote on the proposal to separate sensitivity and confidentiality concepts in confidentialityCode
  • Mike: Follow up with Don Lloyd for TSC’s reason for moving the Security DAM to Informative from DSTU
  • Don: Get clarification from Arb & TSC to determine whether the service payloads need to conform to the HL7 RIM
  • Ioana: Check the Governance and Operations manual to see if Informative standards are issued an ANSI identifier (and remain an ANSI standard for all time)

2. Resolution

  • Security DAM will be balloted Informative rather than DSTU (per email from Don Lloyd and the TSC)

3. Announcements

  • Glen Marshall, who will be stepping down as co-chair in January 2010, has nominated John Moehrke for co-chair of the HL7 SECURITY WORK GROUP.
  • Mike Davis presented the HL7 Security work to Federal Health Information Modeling (FHIM), a new ONC workgroup. FMIH is very interested in the Information Modeling work and the SOA WG efforts as well. They would like to establish collaboration with the HL7 WGs, so Mike signed up for that effort.
    • Scope of FHIM work is Security information models and standards
  1. Information Modeling
  2. Security Framework
  3. Standards Harmonization
  • FHIM was happy to learn of the HL7 Security and CBCC WG accomplishments because they thought there was still a large gap around Security and Privacy
  1. They have no desire to duplicate any of the work being done by HITSP but instead want to leverage those efforts
  2. They are interested in identifying gaps between standards and profiles and proactively engage its members directly with the SDOs to fix those gaps. This is beyond HITSP’s scope, but is not in conflict with its charter

4. Updates/Discussion

Harmonization Proposal

(Separation of sensitivity and confidentiality concepts from RIM confidentialityCode to support Privacy and Security requirements)

Purpose of Harmonization is to discuss all the issues related to proposals.

  1. Pat Pyette brought up the issue of backward compatibility (raised by the Canadians due to the concern this change would break many of their models)
    • The code set used in Canada currently has only three entries:
      • Confidential
      • Sensitive
      • Business As Usual
    • Question is whether there is a real business case to separate these now because it will create some compatibility hardships
  2. John Moehrke also raised the concern that HL7 isn’t the only standard that uses confidentialityCode. There is a potential harmonization problem because DICOM and IHE use this code. The proposal needs to be more global than applying only to HL7
  3. Another question is how to deal with multiple codes since confidentialityCode in the Act class definition has a multiplicity of zero or more. What does it mean for an object to have more than one code?
    • Is it an AND relationship, an OR relationship, or some other relationship?
    • This is a larger issue than merely separating Sensitivity from Confidentiality. It requires a broader discussion than can take place in Harmonization/Vocabulary alone and where there is only one vote per committee.

Security DAM Ballot Update

Ioana provided a walkthrough of the domain analysis model. It’s important to remember that these are conceptual systems, so don’t get hung up on some of the terms used in the document. This is not a substitute for the PASS-Security project where specific services with platform independent specifications.

  • If feedback is received by Friday, 11/20, the DAM will be submitted to the ballot site by Sunday, November 22. Deadline for content submission for the Security DAM is November 29, so if there are any glaring issues following initial submission, we have the next week to amend if necessary.
  • The Use Cases are neither Normative nor Informative; they are background information used to explain how the scope of work was developed.
  • In many areas of the document, the analysis lead to strong guidance because there is a high degree of confidence that specific health care requirements for Access Control were identified.
  • Where our position is less strong, the document explicitly calls out that certain references are examples only. For example, the Vocabulary Analysis section states that the codes provided are for illustrative purposes only
  1. Focus of the DAM is on Access Control and Authorization
  2. Introduction contains an overall discussion of the information required to understand the use cases
  3. Security policy structure and information model diagrams
    • Most of the classes, along with the vocabulary, are shared between the Security and Composite Privacy domain analysis models
    • Classes that are not specifically designated as shared are specific to Security
  4. Use case analysis section provides elaboration for the identified use cases:
    • Enforce Privacy Policy and Consent Directives using Access Control
    • Automated Policy Resolution
    • Negotiate Privacy Policy
  5. Appendix A contains the use cases that scope the analysis model.
  6. Sequence diagrams are used to elaborate the use cases and identify the conceptual users of systems and the systems required to support the use cases.
    • For example, in the Negotiate Policies section, steps declared in the use case describe the system interactions:
      • Shows the conceptual system responsible for Access Control which supports certain capabilities
      • The system that submits Privacy preferences has to invoke a specific capability that allows Privacy preferences to be evaluated
      • Based on that evaluation, a legally binding policy that the consenter will accept (or not) is returned. If the policy is accepted, it becomes legally recorded and enforceable

HL7 Ballot level discussion

(The impact of Informative versus DSTU).

One of Mike’s goals is to create some international profiles in SAML

  • The approach is to use the information models in the DAMs to define the content that would go into a generalized SAML assertion. If the Information Models were Normative, they would have influence.
  • While technically there is no difference (between DSTU and Informative), the labels have a connotation.
  1. Normative implies you are able to test conformance to the standard.
  2. DSTU implies that you intend to go Normative. Most specifications declared Informative do not intend to become Normative.
  3. DSTU is an iterative approach that captures as many comments from early adopters as possible and incorporates them into the DAM which can be republished.
    • As you proceed from the conceptual model to a platform independent model, things that are not practical for designing a service may be surfaced which may lead to a scope revision and republication.
    • DSTU standards elapse if they are not renewed or they do not move to Normative. If the industry trials do not find the specification useful, the DSTU can disappear. This is the upside and potentially the downside.
  4. Informative standards do not expire or elapse
  5. There is the question whether Informative standards receive an external identifier do they can be referred to by other organizations, for example, by OASIS. (Ioana to check the Governance and Operations Manual to see if Informative standards as issued an ANSI identifier)
  6. There are different requirements for ballot reconciliation at the various levels, including the number of votes required to pass, and how negative comments are disposed.
  7. The purpose of a Domain Analysis Model is to drive Normative standards. The DAM is not the information model; it is an information model analysis.
  8. It is the intent to move the Composite Privacy and Security DAMs a Normative standard (from DSTU and Informative respectively).

PASS-Alpha Project Update

  • The Security and Composite Privacy Domain Analysis models are referenced by the PASS project.
  1. Composite Privacy DAM has been balloted at DSTU
  2. Security DAM has now been relegated to Informative by the TSC (originally offered as DSTU)
  • Based on today’s conversation, PASS-Access Control will be balloted DSTU
  • PASS-Architectural Framework will be balloted Informative
  1. Because the DAMS contain information models have not yet reached Normative status
  • Will the ballot be a Service Functional Model (SFM)?
  1. Don: It will have some of the attributes of an SFM, specifically since it is trying to align with the SAEAF terminology and approach. Not sure whether there is an answer to the question until it goes through the ballot cycle
  2. SOA’s approach is different than SAEAF’s:
    • In SOA, the service functional model operates at a conceptual level
    • In SAEAF, there is an expectation that things will be pushed down to into a platform independent model and sometimes into a platform specific model
    • This project might provide the perfect opportunity to use the Security and Privacy information models to do that
    • Within HL7 we can go vertically down from the conceptual level, but if the information model that’s captured in the DAM isn't sufficiently concrete, we can push down to a platform independent level and make it as concrete as necessary. It doesn't have to be RIM-based, but can still be a fully developed UML model and still meet the platform independent requirements
  • What will it take to extend the Security DAM to a platform independent model?
  1. Ioana: First need an answer from the TSC to determine whether the service payloads need to conform to the HL7 RIM.
    • If you're not bound to create an interoperable version, you can reuse the information model and the DAM as is.
    • If you want them to be interoperable, the payloads must conform to the RIM. So you have to map the conceptual model to the RIM, not unlike what was done for the May draft Ballot for Comment. Interoperability determines whether you need to go through the step to map the concepts to the RIM.
      • Suggestion to Don to clarify this issue with the ArB and TSC to see if a service specification that includes functional models and payloads reflecting a conceptual model (not the HL7 RIM) can be balloted as a Normative SAEAF standard.
  2. Don: Preliminary feedback from TSC and ArB indicates there isn’t a requirement to map the concepts to the RIM to make them interoperable
  3. John: PASS-Audit, like PASS-Access Control, is using external standards that are not HL7 Rim-based.
    • PASS Audit is based on RFC 3881 (or the more normative DICOM Supplement 95).
    • It would kill the entire PASS effort if HL7 requires it to conform to the HL7 RIM.
  4. Mike: If we’re building a conformance specification for PASS-Audit that references an ISO standard (very comfortable with that notion), why can’t we accomplish the same thing for an information model for Security and Privacy Policy?
    • Don will pose this argument to the ArB and TSC when he seeks clarification

Meeting was adjourned at 3:15 EST.

Resolved that Security DAM will be balloted as Informative

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