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

September 2009 WGM Agenda CBCC Monday Q3

From HL7Wiki
Jump to navigation Jump to search

Community-Based Collaborative Care Working Group hosting Security WG

Attendees

  1. Bernd Blobel co-chair Security
  2. Andy Bond
  3. Bill Braithwaite MD
  4. Steven Connolly
  5. Mike Davis chair (co-chair Security)
  6. Suzanne Gonzales-Webb co-chair CBCC
  7. Patty Greim
  8. Allen Hobbs
  9. Don Jorgenson
  10. Ray Krasinski
  11. Jim Kretz
  12. Nancy LeRoy
  13. Rob McClure
  14. Hideyuki Miyohara
  15. John Moehrke
  16. Tracy Page
  17. Patrick Pyette
  18. Harry Rhodes
  19. Ioana Singureanu
  20. David Staggs
  21. Walter Suarez
  22. Richard Thoreson co-chair CBCC
  23. Serafina Versaggi Scribe
  24. Max Walker co-chair CBCC
  25. HoJung Yoon

Updates

Agenda and Minutes

  1. Report Outs
  2. Security Doman Analysis Model (DAM)
  3. CDA Implementation Guide
  4. Role-Based Access Control (RBAC)

Report Outs

  • Walter Suarez, Kaiser Permanente, co-chair Security, Privacy and Infrastructure Technical Committee at HITSP and the HITSP Consumer Preferences Tiger Team on the HIT Policy Committee Meeting 9-18-09 – the first of a series of public hearings on privacy and security issues. Jodie Daniels presented an overview on the various privacy and security requirements and regulations emerging from ARRA and other areas.
    • Ioana: please include link to document Daniel_HIT Policy committee 9-2009_final.ppt
  • The 9-18 meeting was comprised of four quarters with invited speakers
  1. Patient choice control and segmentation of health information: this quarter focused on the access and use of data. Policy and implementation people discussed the area of patient choice and consumer control over health information, and more specifically segmentation of information and the degree to which consumers can select certain parts and allow certain people to access only certain parts of the health record (granularity).
  2. Use disclosure and secondary uses of data: this dealt with Public Health access to and the importance of secondary use of data for research. Balance between privacy, preferences by consumers and the ability to use these data.
  3. Models for data storage and exchange – aggregation and de-identification of data: The issue of aggregating data under data warehouses and protecting access to it through de-identification mechanisms was covered.
  4. Transparency, audit and accountability: Bob Gelman covered the area of Accountability: entities ability to let consumers know who has seen what for what purpose. Gelman presented a defined view that says accountability is broad and includes everything, not just certain disclosures and all uses of data. Kaiser Permanente presented testimony on the challenges presented by new regulations which expand the accounting of disclosures.

One of the most notable aspects of the discussion was that very little evidence exists about the implementation costs of any approach to privacy and accountability. There is little documented evidence on the costs for either very granular or general high-level Privacy preferences for disseminating health care documentation. These costs are not just monetary, but include resources, re-programming and educating consumers about the potentially confusing choices.

The meeting didn’t result in next steps and there wasn’t a sense that “something” would be produced by “some” date. The current requirements for federal agencies to produce regulations about accounting disclosures was not driving the discussion. This purpose for this meeting was to hear the broad perspective of consumer consent related issues. The outcome of this session will likely result in recommendations that will inform the ONC on these issues. This group meets every month; but it is not the only topic this group deals with.

What is pertinent to HL7: There are two committees which advise the ONC: the Health IT Standards Committee and the Health IT Policy Committee. The HIT Standards committee has identified a gap in managing Consent Directives and they’ve made a recommendation to HHS that the SDO’s should be developing Consent Management standards.

Security Domain Analysis Model (DAM)

  • Ioana Singureanu - presenting
    • Ioana: please add a link to the Security DAM Project Scope statement

Background:

The Security DAM began as a VA project and is being presented to this joint Work Group in and effort to create interest and to bring in more volunteers and stakeholders. The Security DAM is a companion to the Composite Privacy DAM. The Privacy DAM is focused on Consent Directives and Privacy Policy management, while the Security DAM is focused on the enforcement of Privacy policies by Security systems.

Work to date:

  • Earlier drafts have been presented to the Security and CBCC Work Groups
  • Information analysis about the personal health information relevant to the enforcement of health security policies including organizational and provider privacy policies and consumer consent directives
  • UML Model has been checked into HL7 subversion, it consists of a draft containing best practices from ISO with input from security experts within VA. We also involved Medical Records experts from VA in the development
  • Started developing use cases which are available on the Security Work Group Wiki site. These use cases are looking at the exchange of enforcement of health care security policies. The most recent addition, added by Steve Connolly, is a use case around the negotiation of policies and consent directives.
  • Draft project scope statement

Scope statement overview:

  • Started with RBAC information – because Security Work Group has already addressed these
  • Looked at permissions and permission catalog and how permissions relate to user roles and the operations in which those roles are allowed to engage
  • Other concepts captured:
    • Purpose of Use
    • Different specializations of these security policies have also been identified, e.g.,
      • Delegation
      • Authorization
      • Obligation
    • All concepts based on ISO 22600
  • Also added something relevant to Consent – the idea of a Constraint Policy. A Constraint Policy limits an existing policy that supports a Constraint Directive

Discussion:

  • Ioana: This conceptual model is not yet tied to the HL7 RIM. We’re still trying to understand what’s relevant from an architectural standpoint. To date, this document represents our interpretation of how to leverage all the existing architectural concepts. If there are issues with the model, this project provides the opportunity to clear up and refine any omissions and problems.
  • Bernd: in terms of the model. The idea behind ISO 22600: all of the policies always contain constraints, that’s the characteristic of policies and therefore we’d have to introduce a separate class for constraints
  • Ioana: we might have to revisit the constraint policy as the result
  • We looked at different attributes of information that would be subject to Privacy policy and Consent Directives. Some attributes may need additional work. Some attributes may require a change to the RIM. For example, one element that surfaced is the difference between Confidentiality and Sensitivity, as well as the idea that sensitivity is not only associated with a particular artifact but with a user as well.
  • Mike: this area has also been identified in the US as a gap – the lack of an information model. A new group in HHS responsible for recommending standards is looking for SDOs to provide some guidance.
  • Ioana: this effort is not meant to substitute for other good work that’s been done, but to tie together a set of interoperability specifications - this is what HITSP’s looking for.
  • Bernd: the big advantage of this work is that it’s extended the perspective of Policy to the environment that Policy has to apply to. The only concern I have is that any policy is a constraint expression and patient consent is just another policy. We have to bridge between policies. This therefore introduces another class into the UML diagram. So there may be an outstanding issue to resolve the true meaning of a consent policy.*
  • Q: is there a vocabulary item that defines data sensitivity categories and groupings?
    • Ioana: currently HL7 combines the concepts of Sensitivity and Confidentiality in its terminology. Ideally, we would like to separate these two concepts. The project’s analysis has identified a need to revisit these concepts and the vocabulary. This project will help to formalize the reason for this separation and to put these concepts (Confidentiality & Sensitivity) in context.
    • Mike: ISO identifies sensitivity as part of Access Control that needs to be considered, but these classes don’t define the vocabulary
  • Ioana: Purpose of Use has been incorporated as part of Policy and we have also identified there are concepts that have to do with the information user: login, credentials
  • The Privacy DAM looks at the business from a slightly different point of view; a lot will be common between the two models however.
  • ISO standards are providing the definition part, but not the inter-relationship between definitions. If we had a terminology, there would be inter-relationship between definitions.
  • Richard: what are the next steps?
  • Mike: The plan is to meet a schedule established by HL7 for an initial ballot in Jan 2010. We’ll take the draft work done over the summer, and leverage that to get this project scope statement approved. Then submit it to HL7. The first deadline is 10/4 – to take the approved project Scope Statement to the PMO. This has to then be approved by the TSC within two weeks of this Work Group meeting. Security is the primary sponsor for this effort, and if approved today, it will be taken to the Security Steering Division which meets tonight (9/21).
  • Richard: how will the gaps identified in terms of vocabulary be filled and when will this be done?
  • Mike: The Security Work Group will talk to M&M as this gap is a comment against the Privacy DAM.
  • Ioana: if we say Sensitivity and Confidentiality should not be mixed, we first have to convince M&M these concepts should be separated. The terminology in HL7 combines them, so there has to be an effort to tease out which concept domain belongs to sensitivity and which belong to confidentiality.
  • John: the reason for the Security DAM is to uncover modeling problems. Once uncovered, we create new projects to resolve them.
  • Steve: ideally Domain Analysis is done separately from implementation (in this case the RIM). Need to do the analysis without looking at the RIM.
  • Richard: To what extent do we worry about harmonization and to what extent do we worry about putting things into a ballot? What are our steps to fill a gap? Is this a new process, similar to what SAEAF is doing?
  • Ioana: in the SAEAF process, you create the conceptual model before developing a platform independent model, which comes before developing platform-specific technology.
  • Mike: This feeds into Don’s task. Don is looking for these information models to fill in the PASS Alpha work. Don will aggregate these different artifacts for re-use. An electronic ballot request was put out last week. If it’s appropriate, I would like to make a motion that we review the DAM and get a consolidated vote on this.
  • Ioana: I’d also like to make sure we have identified all the people who are interested in contributing to the project.
    • Walter Suarez (KP) will be added as a domain expert to the project scope (as well as others who have been added to the updated Project Scope statement, see link above)
  • Motion:
    • Mike: I make a motion that this group has seen and approves the joint Security/CBCC project to create a Security Domain Analysis Model. Security will be the lead. The intent is to ballot in Jan 2010.
    • Bernd seconded the motion.
    • Vote: Abstain: 0; Oppose: 0; Approval: 25 (all)

CDA Implementation Guide

  • Ioana Singureanu - presenting
    • Ioana: please add a link to the CDA Implementation Guide Project Scope statement

Background:

This is a project to create an implementation guide to allow clients to express their Consent Directives using CDA R2 that we discussed on last week’s conference call. The purpose of this Implementation Guide is to produce a structured document specification to exchange signed client Privacy Preferences (the term Client has replaced Consumer).

This specification will make use of the concepts identified in the CPCD DAM and the CDA R2 specification. This project is intended to support the management of Consent Directives and polices. CDA R2 supports the multiple representation of a Consent Directive in a user-friendly form – as a narrative, signed document (wet signature) as well as computable statements/entries using standards-based terminology.

  • This proposal leverages the work done for the Security and Privacy DAMs.
  • Outcome of this project will be an implementation guide, not a new standard or Domain Analysis Model.
  • Several co-sponsors have been identified including the Security, Structured Documents and Child Care Work Groups. The primary sponsor is CBCC.
  • Ioana is the project facilitator but the job is up for grabs if anyone wants it.
  • Walter volunteers to be the publishing facilitator.
  • Interested parties include: Mike Davis, Tom Davidson (SSA), Rob McClure, Pat Pyette, John Moehrke, Bernd Blobel, Suzanne Gonzales-Webb, Allen Hobbs

Discussion:

  • Q: It’s my understanding that Implementation Guides are created to support Standards. Are we building an Implementation Guide to support the Consent version 1 (within Medical Records/Information Management)? Version 2 is only open for comment. Are we putting the cart before the horse by putting out an Implementation Guide before the Standard?
    • Ioana: This is not an Implementation Guide of a Medical Records standard, it is an Implementation Guide of a Structured Document. We are constraining a structured document such that it can be used to exchange consent directives.
    • The CDA R2 standard already exists. It is a standard that specifies what a structured document may look like. Effectively this is a profile. A profile of CDA is an Implementation Guide.
  • Don: could you comment on the relationship between the information model on the previous project (Security DAM) and where that interacts with run-time Access Control?
  • Ioana: there is a point where if you have a fully described interoperable expression of consents, you can translate that into a fully enforceable policy statement assertion that can be implemented by systems. There are different concerns that have to meet in the middle. But ultimately, you have a computable representation of a consent directive that can be mapped or transformed into an access control policy.
  • Don: the individual classes described in these models have to be shared
  • John: That’s why the Security DAM is going to be carefully synchronized with the Privacy DAM. These are still just DAMs, not implementations. We still need an implementation.
  • Ioana: We need to have an HL7 V3 standard that takes these concepts and relates them to the RIM. We are working to map these concepts to the RIM
  • John & Don: Not so sure these need to be in the RIM.
  • Ioana: The PASS-Alpha project may reuse the implementation guide specification as their own service specification along with other kinds of payloads that Don will elaborate.
  • Motion:
    • Ioana: I would like to make a motion to approve this scope statement.
    • Mike seconded the motion.
    • Vote: Abstain: 0; Oppose: 0; Approval: 25 (all)

Role-Based Access Control (RBAC)

  • Steve Connolly - presenting
    • Ioana: please add a link to the document HL7WGM9-21-09 Steve Connolly slide deck for RBAC and constraints

Background:

This is an older project that was originally balloted in January 2008, and has been updated for September 2009.

Roll-Based Access Control (RBAC) consists of an information model and is subsumed by the Security Domain Analysis Model.

  • RBAC creates permissions from objects and operations.

The task was to increase the number of objects and operations to more generally represent access control needs.

Process:

  1. Health care scenarios were identified from which objects and operations were gathered
  2. They were collected into permissions
  3. From the first RBAC permission catalog, determined whether RBAC could be implemented from this. Yes – we would do a refined information model. No – go back and augment the scenarios by introducing the EHR functional model.

This effort allowed us to recognize a number of gaps that were filled with new objects and operations. We also included a Constraint Catalog for the Sept 2009 ballot.

The approach we took was to adopt an organizational framework to distinguish workflow from record objects, conduct a Gap analysis, add and refine objects and finally, to conduct peer review and get approval.

We came up with an object vocabulary which separated the workflow from the record objects and connected the workflow objects and object vocabulary to the EHR functional model. There was an attempt to connect the objects to an external code system (SNOMED-CT and LOINC) but this proved not to be satisfactory – only three of the 56 objects could be mapped to SNOMED-CT and only 10 to LOINC.

All but two of the original objects were retained, so there’s not been much change to the original object list.

Accomplishments:

  • Organized the object vocabulary and map it to the EHR functional model
  • Performed analysis for mapping to LOINC and SNOMED-CT. We’re not giving up on this but what is required is an information model that is produced with the Security DAM to constrain the object that can then be mapped to SNOMED-CT or LOINC or a number of different code systems

Discussion:

  • Bernd: SNOMED-CT does not deal with administrative issues – it is a medical terminology. SNOMED-CT does not identify persons, and Security cannot be managed without the concept of person. We will never use only one ontology. A top-level ontology such as OBO, that provides some of the missing details but is not perfect, could be an alternative. Having a top-level ontology that covers both domains could help, but this would still require the introduction of additional terms.
  • Steve: there is the problem of taking a class called objects, in this case the definition of objects, records within an EHR that require protection and trying to map those to SNOMED-CT which are clinical processes, treatments, etc., but not records of treatments, processes.
  • Bernd: that’s one of the problems. But the problem is that many concepts that are relevant for Security issues are not in SNOMED-CT at all. OBO is my recommendation even though there are things missing in OBO. We are working on this at the moment.
  • Steve: by using the RIM paradigm, you have a class; the class has attributes, the attributes would be bound to code systems and one of those code systems could be SNOMED-CT.
  • Bernd: We are slowly moving towards an ontology-controlled environment and we are borrowing from outside specifications and definitions which haven’t had the RIM in mind. If we are combining those issues with our issues we will be in trouble. Some Security objects and certificates are hardly adaptable to the RIM philosophy. It’s impossible to stay 100% with the RIM.

Meeting adjourned at 3:00 PM EST

In Q4 we will spend five minutes more on the RBAC constraint catalog. Q4 will then cover the Composite Privacy Domain Analysis Model and PASS-Alpha projects.

Ballot reconciliation will be conducted in the Security Work Group on Thursday during all quarters.

Back to CBCC Main Page

[Top]

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