October 6th 2009 CBCC Conference Call

Attendees

• Pat Christensen
• Steven Connolly
• Tom Davidson
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Rob Horn
• John Moehrke
• Pat Pyette
• Richard Thoreson CBCC Co-chair
• Ioana Singureanu
• Serafina Versaggi Scribe
• Tony Weida

Agenda

1. (05 min) Roll Call, Approve Minutes & Accept Agenda
2. (20 min) PASS

• Review Privacy/Consent requirements extracted from the Use Cases used in the Composite Privacy Consent DAM,
• Solicit additional requirements (especially, but not limited to behavioral requirements)
• Identify new use cases necessary to extract the capabilities for Consent Management Services

Discussion

ACTION ITEM for the Group: Please review the PASS Consent Requirements draft (link below). This will be on the agenda for discussion in next week's call.

A summary transcript of today's meeting follows:

• Pat Pyette: PASS Summary – Requirements review
  • I’ve gone through the Privacy DAM use cases and tried to extract requirements from those use cases. See PASS Consent Requirements Draft version 0.01 http://hssp-security.wikispaces.com/PASS+Consent
  • On a regular basis moving forward, I’d like to go through these requirements with the group to identify and validate the requirement, identify the service area that would be responsible for it, identify determine whether it’s health care specific, whether we need it for functional specification and the use case this was extracted from.
  • Most of the language in this spreadsheet came straight from the Privacy DAM.
  • Since this is the first time anyone has seen this, it might be better for everyone to review and then we can discuss next week.
  • Process for group review: Gain agreement on the implications for the use case, are there requirements that haven’t been picked up and are there other requirements that we know exist and do we need to create a new use case for them?
  • Let’s out this on the agenda for next week and we can dig into this during the next meeting
  • What we’ve done in terms of process in PASS, in both Audit and Access Control, everyone has a vote on the clarity of the requirement (at 80% requirement is relatively clear, if 30%, wording has to be amended). This is a consensus driven approach
• John: I'm not sure the items within this spreadsheet are at the same level of abstraction. There are some granular requirements and other high-level requirements. Is this something that will be fixed in the wording and they’re all intended to be at the same level?
• Pat Pyette: If the group thinks the requirements are worded incorrectly or are not actionable, that they won’t drive something in further DAM/information model work, the group needs to fix/remove those items.
• Richard: any other agenda items? I’d like to discuss the necessity to adjudicate or harmonize potential conflicts among various policies.
• Pat Pyette: approach was to take the Consent DAM use cases – DAM includes business requirements, use cases and information model. The way the SAEAF process works: that business model drives the information model and the functional model. I fully expect that there are functional requirements and capabilities that we need that require further development of additional use cases.
• Richard: this one seems to be front and center in everyone’s mind: the reconciliation of policies could be across jurisdictions, across policies type. Do we have adequate use case for this?
• Pat Pyette: there is a cross-jurisdictional use case (CON30 - at the bottom of the spreadsheet) but not sure it is capturing what you’re talking about.
• John: not sure whether this a Privacy DAM issue or a workflow issue. It might be useful to put these concepts into the SAEAF matrix to understand where they live and where they’ll be dealt with. If we bring them up in the wrong place, we don’t have satisfaction. Yesterday’s release of Consumer Preferences by HITSP indicates that conflicting policies will arise that need to be handled manually – and that this is out of scope.
• Comment: this doesn’t mean that manually is out of scope, but that may be handled in the future.
• John: I’m not saying this is not going to be dealt with, only that it needs to be put in the proper place to be dealt with appropriately. It is not just an information model issue but a workflow issue.
• Pat Pyette: here's a summary of the tone of the artifacts produced for each viewpoint within the SAEAF 4 X 3 matrix:
  • The vertical perspective starts at the conceptual level and goes to a platform-independent level where there are some constraints from the conceptual model; then goes to the platform-specific, where in HL7-Speak, there are messages, documents or services.
  • The Horizontal perspective is the business viewpoint – a glossary is identified along with scenarios. Abstract the scenarios into a set of use cases that identify specific informational and functional requirements. These can then be used to feed the information model and the functional model – service capabilities analysis and profiling.
  • The SAEAF information analysis is like the modeling that has taken place for a classic DAM – producing things like a UML model for entities relationships. It also has state transition information –significant entities, how they transition and the impact as well as business rules which are cast-in-stone invariant rules. Those three things get identified in the information model.
  • The functional model starts off with the same scenarios, use cases and requirements and to drive out capabilities. For a particular behavior, a series of services or capabilities may be identified to satisfy this one behavior. So we try to identify how these things collaborate to satisfy their contract. Based on these, we create functional profiles. There are also semantic profiles which going back to the information model. These collaborations are how collections of information are used together – Conformance profiles, the collection of functional and semantic profiles. Conformance profiles can be used to test and validate. That’s the entire computational viewpoint.
  • Only other viewpoint within SAEAF framework is the Engineering viewpoint: still trying to figure out what this means. At the conceptual level, it talks to what’s needed to support the business from an infrastructure perspective. Mike may have a different view on this. We’re going back to the SAEAF folks, the ArB to get clarification on this.
• Richard: so where does this issue come up (adjudication of policies)? In the business viewpoint?
• Pat Pyette: Yes, the business viewpoint is concerned how the business interacts with its stakeholders and the specific business functions that it performs. This is not necessarily related to automation at all. Taking a look at that scenario would start at the business viewpoint, and then look at what’s needed from an informational and functional perspective to make that happen.
• Richard: so then, if the use cases are where you start (from the business perspective), then we will need a use case for what to do when there are conflicts about policy.
• Pat Pyette: If the use case is outstanding, someone needs to develop it. Can you do this Richard?
• Richard: I thought this was already resolved.
• Mike: There was a reference model that was presented at our joint meeting consisting of three layers:

1. Policy layer for privacy
2. Policy layer for jurisdiction/organization
3. Enforcement engine that consumes these things

• Mike: The issue was that a patient presents a request for their privacy preferences, but organizations are constrained by jurisdictional policy about what they can accept. Once the organization accepts it, it becomes policy that can be enforced.
• Mike: Policies need to be managed globally and enforced locally. This is an implementation detail however. In the paper-based way, since there is not much cross-organizational harmonization, it’s done at the hospital. But going forward, it would be desirable to handle this globally. There is the concern about the ownership of the data repositories. We need to draw a line between different functional sets – there’s a difference between managing and provisioning stores and doing these kinds of negotiations from the brute mechanical process of running a rule through an engine and getting a decision.

Richard: who is going to resolve conflicting policies? Who is going to own this?

• Mike: For SOA we’ve created a box and made it a broad non-specific one. A flow that you can take a look at that shows how policy goes from patient Consent to getting it into some repository. All we are calling this in the most general way is Privacy Management.
• Pat Pyette: a few months ago the CBCC voted to join the PASS Alpha effort. As a CBCC work group can we support PASS, based on the assumption that the work group contains domain expertise? So when we’re talking about business requirements, I would expect CBCC would be the source for this information.
• Richard: for next week, we will review this spreadsheet for completeness with respect to the Privacy and Security DAMs.
• Mike: the point where negotiation/adjudication meets is the boundary between the Security and Privacy DAMs. This is on the Privacy side and authoritative to Privacy and is a store that Privacy is responsible for creating and keeping. The Security Management side (not the Access Enforcement side) should interface with that store.
• Ioana is charge with working on harmonizing the Security and Privacy information models
• Mike: The CDA is a good starting place depending on what you mean by it. Is the CDA the form where a patient’s consent directive will take place from the PHR?
• Richard: all of the policies can be put into the CDA architecture (patient, organization, jurisdiction).
• Mike: We either have to map the objects to what the patient’s called out for to the Security Objects in the Permissions Catalog,
• Mike: the patient is presented with a form/display, make choices, electronically (optimally) sign this form. This document needs to be stored someplace and harvest the attributes of the patient’s input into machine-computable attributes that’s also stored in a directory somewhere and that when we need to transmit those thing from a PHR to a provider a CDA document is created. The receiving entity might also want to see the signed representation of the consent as well.
• John: are you suggesting there are two different CDA documents – one a representation what the patient signed and the other something that may have been transformed from that signed document into something that is computable?
• Pay Pyette: Do you expect this to be a single schema for those two purposes or a different schema?
• Mike: Could be either way. We’ve experimented with creating PDF Consent Directives and harvesting them for data that can be done relatively straightforward.
• Richard: want to define a framework or document that would be workable for all levels of policy – not just clients. CDA
• Pat Pyette: the issue in my mind – going from the privacy policy language that would be presented and agreed to by a patient or an organization have a different set constructs and different language that would be used and thus the transform into what may be computable from a security perspective. If the language is different the schema may have to be different. It would be good to think of these as two separate documents – two different CDA documents because there are two different uses for them.

This discussion will be continued in future conference calls.

Meeting adjourned at 3:15 PM EDT. No significant decisions or motions were made.

Back to CBCC Main Page