September 2009 WGM Agenda CBCC Monday Q4

Community-Based Collaborative Care Working Group hosting Security WG

• Back to September 2009 WGM

Attendees

1. Bernd Blobel
2. Andy Bond
3. Steven Connolly
4. Mike Davis Chair
5. Suzanne Gonzales-Webb
6. Frieda Hall
7. Allen Hobbs
8. Don Jorgenson
9. Ray Krasinski
10. Jim Kretz
11. Nancy LeRoy
12. Glen Marshall
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
23. Serafina Versaggi Scribe
24. Max Walker

Agenda and Minutes

• (10 min) RBAC Constraint Catalog
• (85 min) PASS-Alpha Project

RBAC Constraint Catalog

• Steve Connolly and Suzanne Gonzalez-Webb presenting

After January 2008 ballot we had defined:

• • Operations
  • Objects
  • Permissions

For the September 2009 ballot, additional operations and objects as well as concept of Context Constraints were added.

Context constraints are restrictions that are enforced on Access Permissions. The Constraint Catalog was added to handle the additional conditions imposed on accessing health care data, such as Purpose of Use, limitations as to who can view a client’s record, length of time before permission is revoked, etc.

With the introduction of Privacy and Consents, the Constraint Catalog is a way in which we planned to handle Access Permissions within RBAC.

These concepts are being transferred into the Security DAM. Some concepts are still pretty rough. This is also not to say that access to everything (about health care data) can be controlled by permissions alone. You need more than permissions to limit access and RBAC.

Discussion:

• Bernd: this is a very practical approach that can be implemented soon because it is based on HL7 assumptions. If we have classes and attributes and we can define a constraint as an attribute, we can then use it in any environment. If there is a more “socialized” environment, meaning you have systems which are more autonomous, which can behave independently and intelligently, then we need more complex descriptions of things and not just one attribute. But you can always define a complex expression like a policy, by a set of attributes, and with a large number of attributes, you can express any complexity. So this is a convergent development, where 22600 started top-down with the policy description as a very complex approach, this is the bottom-up, but we are on the same wavelength. The only problem is being able to formalize these issues – to make it abstract and then formalized so it can become computable.

This ties to the work being done on the PASS-Alpha project.

PASS-Alpha Project

Don Jorgenson presenting

Ioana: please attach Don's slides once sent

Background:

• PASS–Alpha (Privacy Access and Security Services)
  • Alpha from the SAEAF-Alpha program – HL7’s Service Aware Enterprise Architecture Framework
    • Architecture framework built upon RM-ODP and model driven architecture
• Includes:
  • Access Control
  • Access Services
  • Security

• Major Components:
  • DAM – conceptual level
  • Service functional model – behavior definitions

Current Status:

• Access Control started last year at Vancouver, and we’re about 0.5 rev of the capabilities.
  • Identified use cases
  • Gathered requirements
  • Established capabilities

• PASS-Alpha includes a service view. The project will take the Domain Analysis Models and map them to the existing traditional HL7 message/document base and service paradigm.
• Historically platform-independent models and platform-specific models were not in the purview of HL7. Platform-independent: a fully developed model with specified data types and behavior but is not bound to a platform. The traditional MDA resulted in a platform-specific binding.
• Collaboration Analysis: In addition to defining services and service interfaces, PASS-Alpha combines services, re-use.
• Service collaborations are the interactions required to fulfill a specific business use case or interoperability use case depending on the level in the model-driven architecture. In the case of the conceptual model, these would be collaborations required to fulfill a business use case.
• In the message paradigm, HL7 doesn’t care about applications being inter-connected. But for real semantic interoperability, you have to know how an application is sending, receiving or possession information. Additional collaboration information enables interconnection via messaging, which guarantees semantic interoperability because application behavior is also described.
• PASS-Alpha project focuses on services but doesn't ignore existing HL7 work. This will provide a framework that accommodates both. Ideal situation would be to take application level messages from one end to another while security and privacy are managed.
• Focus of the PASS project is on the service interfaces, where an Access Control engine can grab Consent information, together with the information model that information to be passed between Consent Managers.

Discussion:

• Q: Will there be coordination between this project and what others are doing related to Privacy Preferences? PASS-Alpha, CDA Implementation Guide, etc.?
  • What’s totally new in PASS, compared to what’s being done in NHIN–CONNECT is that PASS elaborates behaviors based on identified use cases for Consent Directives management, for Privacy Policy management, for Access Control Policy Information Point type systems. There will be more business-focused behavior. In NHIN-CONNECT, the single behavior is XDSP. You can register documents and fetch them when you need them. The exchange of Consent Directives and Access Control policies is a different set of behaviors.
  • The CDA can capture a wet signature and deliver it somewhere; it might be an XDS repository, so there are some message-based solutions. This is a different way of moving information, collecting and delivering into a repository where it’s available for the Access Control engine to find Privacy Policies that apply to the situation for processing.
  • The CDA Implementation Guide could be the next generation of expressing Consent in BPPC, but the behavior doesn’t change. The PASS-Aplha project goes beyond and adds behaviors.
  • SAEAF is trying to be services-aware, not necessarily services-oriented. From a platform independent model, we should be able to produce messages or documents or services that recognize the same concepts, that use the same language and with relative ease, can inter-operate. The interconnections will need to be addressed, but the semantic information will be almost identical, whether it’s message-based, document-based or services-based.

• Have milestones been identified for this ballot? When will peer-review occur for instance? What will be included in the ballot?
  • A number of tasks need to be accomplished over the next six weeks for peer review. How much we’re able to pull together will determine what’s in the ballot. The Security DAM is an important dependency for PASS.

Meeting adjoured at 5:00 PM EST. No significant decisions or motions made

Back to CBCC Main Page

[Top]