September 15th 2009 CBCC Conference Call

Community-Based Collaborative Care WG Weekly Conference Call

Attendees

• Steven Connolly (Apelon)
• Mike Davis(VA) Security Co-chair
• Suzanne Gonzales-Webb(SAIC) CBCC Co-chair, meeting chair
• Rob McClure(Apelon)
• Richard Thoreson (SAMSA) CBCC Co-chair
• Ioana Singureanu (Eversolve)
• Serafina Versaggi(Eversolve) Scribe
• Don Jorgenson (Inpriva)
• Pat Pyette(Perimind)
• Tony Weida(Apelon)
• Tom Davidson (SSA)
• Milan Petkovic(Philips)

Agenda and Minutes

1. (05 min) Roll Call, Approve Minutes, Accept Agenda & Call for Additional Agenda Items
2. (25 min) New Project - CDA Implementation Guide for Exchanging Consents The draft project scope statement was reviewed during the call with the following revisions:
   • Security WG was added as co-sponsor
   • The Department of Veterans Affairs (VA) was added as an implementer
   • The Social Security Administration (SSA) representative (Tom Davidson) will confirm whether SSA should be added as an implementer
   • Mike Davis and Tom Davidson were added as interested parties, an invite to other stakeholders to follow on the Security List
   • The project scope was clarified. The following is a summary of the discussion:
   • Ioana: This is a new project opportunity, one that came up on the list – brought up by Tom
   • Ioana will submit an early draft for this project to the list and would like to determine the level of interest of the folks on this call.
   • CDA Implementation Guide to exchange consent directives in a standard-based, platform-independent way
   • Short term project – no producing a new standard but instead creating an implementation guide of an existing standard - CDA
   • Identify project team members who would sponsor this project. Would Security like to be a co-sponsor of this project
   • Scope:
     • Produce a structured a structured document specification to exchange signed Consent directives
     • Will leverage work already done with Security on Privacy Consent model
     • Even though CDA R3 is coming along, it seems reasonable that this will have to be a CDA R2 implementation guide
     • CCD does not have a section for Consent Directives, but does have a section for advanced directives, but that is an entirely different set of information
     • Consent Directives would be a separate document – perhaps not ideal but that’s the situation
     • Approval in January 2010
     • Complete the DSTU ballot by Nov 30, 2009 to be ready for ballot by January
     • Need to consider a new vocabulary proposal because this would add a new document type to CDA
     • Also necessary to specify new common message element type based on the document entry that would constitute a consent directive: included is a CMET design, document design for implementation guide, and vocabulary proposal are therefore the three distinct deliverables
     • Also include an optional May ballot. So ballot reconciliation could occur in January– that would be the Phoenix workgroup meeting, based on the results of the reconciliation meeting, there would be perhaps another May ballot and that would be the end of this project
   • Richard will sponsor this as an action in the Security TC (?) to get approval for Security to be a co-sponsor
   • Ioana: Question for Tom. One requirement for normative DSTU project is to find two implementers for a standard. SAMSHSA already included. Would SSA be interested? - VA is interested as well
   • Question: isn’t there a way that already exists for exchanging consent information – text format?
   • IHE provides the BPPC profile that provides two definitions for defining Consent Directives, both CDA-based. One is for a scanned image. Also makes an attempt to define a structure, but only defines vocabularies for emergency and doesn’t come close to the detail required by the Domain Analysis Model
   • Ioana, directed to Tom: Should this project collaborate with IHE on the BPPC profile?
   • Tom: there are aspects that go beyond privacy
   • Mike: eventually if this was available, it would replace in many instances replace the BPPC
     • In terms of HIPAA only 2 ways of expressing consent
       1. Authorization
       2. Restriction request – a simple request in writing without a particular format.
     • Recognized that is something that is needed
   • The NHIN – under Consumer Preferences while repudiating TP30, went ahead and created an XACML policy for capturing this information
   • Mike: doesn’t capture this information. XACML is very rudimentary, it only defines permissions purely based on the services NHIN is currently exposing, and is not as robust as what this should end up being
   • Should this project should collaborate with HITSP to ensure HITSP is looking for the standard that is being proposed here.
     1. Yes - HITSP Consumer Preferences. But this project won’t meet the immediate timelines HITSP has
   • Mike: NHIN Connect – only patient authorization available is Opt-In (or Opt-Out). This doesn’t support consent; the XPA stuff is in there for going forward, but doesn’t support consent, it only supports authorizations of the requestor.
     • NHIN has a specification for a Subscribe type of thing to where the patient Consent Directives would be managed. But there is no implementation or detailed specification of how this would be done
   • Tom: trying to get in for next round of the NHIN is support for a TP30-TP13 exchange and retrieval of an external Consent Directive from an external source. Trying to align SSA use case for this so that their auth and release information would work under that umbrella. Trying to get this in for the Jan go-live time frame
   • Mike: SSA is the exception to the general rule. Most NHIN work between providers does not require this under the DURSA. Which has the autonomy principle, which basically says, the Consent directives are created and maintained by each provider. SSA is a little different
   • Tom: This is what is contained in this use case – which states providers have the opportunity to review and decide whether they are going to accept or not.
   • Tom will send use case to Mike once he feeds it through the ONC process. Details of what is needed out of TP30 for the January timeframe.
   • Mike: It would be useful for Don who is collecting use cases
   • Tom is leveraging what is currently defined via BPPC. SSA doesn’t have structured definition for Consent Directives, so trying to leverage what’s supported via the scanned document and the signature embedded within. This sets the stage for the work being proposed here today.
   • Tom: SSA doesn’t have granular Consents. At SSA the default is all encompassing – when people sign authorizations they are agreeing to consent to all information including sensitive information - substance abuse, mental health and sexually transmitted diseases. This is explicitly stated. There are times when consumers may constrain this information however, so need the ability to exchange those constraints in a structured manner. Up to the responder to evaluate and determine whether they are able to accept the constraints. Tom will share the use case with the list.
   • Ioana: Want to close on Item #9 – Collaborating with HITSP Consumer Preferences. Do we need an action item to follow up with them?
   • Mike: This group is already being formed, and many of the participants on this call have volunteered to work on HITSP Consumer Preferences already, so the collaboration will be underway when the work begins (the group is forming right now). Action Item: Don: we can bring this CDA project to their attention
   • Don: expressed concern that CDA going forward will be the solo approach. Particularly with the SSA use cases where a SAML type assertion is included in a WS-Security header that can convey the information in a way that is compatible with existing processes
   • Tom: SAML data does not contain enough information to convey what is being conveyed in these consents
   • Mike: Agreed. Two processes, one is a Front end process with SAML assertion or WS-Trust where the users authorizations are being asserted and a back end communication that may be a pub. subscribe or pull request to get this information
   • Don: SAML assertions very generic, extensible, carry the information that you need, provide a framework for security and privacy digital signing, security tokens WS-Trust
   • Current profiles do not support passing privacy supporting attributes
   • Ioana: A Consent Directive has a dual purpose – one, as part of the medical record (as perceived by Canada primarily) but is also the repository for a particular authorization or restriction requirements. For that reason alone, reasonable that you would have a representation of the Consent Directive that would be a document and another representation that would be a set of assertions or rules that would enforce access to data or user authorization. So the consent could start out as a structured document with fully coded entries and could become through the process of enforcement other kinds of artifacts. One has to be a user-readable consent that says I agree to this and I sign off on this. If you don’t have a user-readable representation, how could a person consent to something?
   • Mike concurs. This is the problem that we continue to face. The difference between the management aspect of consent and the enforcement aspect of consent (machine processes). Need to be able to have the patient construct a Consent Directive that goes into a repository that can then be mapped to specific policies, to specific attributes, to an XACML or whatever. Need to distinguish between management processes and actual machine-processes. TP30 side is the management side.
   • Don: agrees that a patient’s Consent Directive will be mapped into something that is computable whether it is a SAML policy or SAML rule or an assertion. But still has concern about the whether CDA is the appropriate vehicle to convey this information to the policy decision.
   • Tom: Don’t know if CDA is meant to do this, but it is useful because it has the ability to capture images of a wet signature, type of credentialing, has readability format. CDA itself does not become the underlying executable format. The CDA structured document has the ability to be transformed into something that is executable, i.e., a potential XACML statement.
   • Don: Still trying to understand why CDA for this purpose. What’s the use case that makes this appropriate.
   • Ioana: the CDA as opposed to what? Perhaps if we understood we could address Don’s objections.
   • Tom: In the current health care industry, these signatures occur and signed pieces of paper containing Consent are considered clinical documents – these are signature and access documents and are part of the medical record. In other words, Consent forms naturally align with the CDA document structure as the result, and as an existing standard, is less of an uphill climb. Is it possible to express this in an XACML form only – yes, but not aware of XACML or other options that can express images or wet signatures.
   • Mike: TP20 revision provides for three ways for expressing the Consent Directive.
     1. PDF form that can include images, signatures
     2. an XACML form that was created from the PDF or
     3. A form of pure attributes under the assumption that you can say the Consent attributes apply to a specific policy that was standardized somewhere. Haven’t gotten to that. For example, Policy #5 has a set of attributes. Those attributes can be shared and the receiver knows those attributes apply to policy 5 without creating the XACML policy to say here are the attributes for Policy #5.
     • There’s no CDA representation currently being discussed in HITSP. This would lead to this option.
   • Don: How do you see the CDA document being consumed? Who is the target audience ?
   • Mike: Target audience is the management side of the Consent Directive. These Consent Directives are going to be provided to that side, an organization approves Consent Directives and puts them in an XDS repository which is authoritative now ] once the organization has approved and accepted these Directives, it is that authoritative repository that is accessed by the Security System, it’s placed there in a form that the Security system can consume.
     • Security system not responsible for making the policies or getting the patients’ Consent Directives, it is merely consumes it from the authoritative source
     • Management side is interested in this repository because they have to get the Consent Directives and then they have to manage the changes, cancellations, etc.
     • Security system simply enforces whatever the authoritative policy is established and the management side determines what that is
   • Don: In the SDS environment requires pulling out the metadata and putting it in a register to make it accessible.
   • Mike: Already have done this – proof of concept – extracting the data out of a PDF; that’s currently the approach. What is needed a standard Consent Directive since they are currently ad hoc. How to you determine in a machine-computable way if you don’t have a “form” of sort
   • Question for Mike: PDF was mentioned. HITSP didn’t recognize a scanned representation of a CDA? No – not at this point. All that was proposed to HITSP are the three above.
   • Mike: Question for Tom: when a patient submits Consent that implies the release of sensitive information but at the time of signature doesn’t have anything sensitive and subsequently sensitive information develops, does the consent apply to this new information? Does the new information negate the consent?
   • Tom: Good question – probably has to be legally interpreted. If they sign release without restrictions, tends to apply for the legal duration (SSA Authorizations are only maintained for one year). We use this only as a single request/response, we are not doing this as a subscription mechanism so it is only at that point in time .
   • Mike to Tom: Might want to speak with your lawyers. VA lawyers have ruled that even if the patient says they do not have HIV at the time they make their Consent Directive, it is up to the VA to monitor that and negate the Consent Directive if that information should turn up positive later .
   • Ioana: Salient points of the discussion
     • CDA support multiple representations of CD
     • Not intended to be the underlying computer representation of of a consult directive or a constraint policy
     • Opportunities to sign up as a member of the project team – Tom, Mike, would you like to be named as interested parties?
   • Mike: Yes, there are two action items:
     • Mike will take this proposal to the security TC as a proposed joint project for their approval
     • Don/Tom – take to the Consumer Preferences workgroup at HITSP and introduce it as an initiative
   • Ioana will add a comment indicating that Don/Tom will introduce the proposal to the Consumer Preferences work group at HITSP and will send the draft out for additional review and additional comments.
   • No need to take a motion to approve the scope statement until additional review and comments have taken place. Instead Ioana will just distribute the draft and will make a motion to approve in a future call
3. (25 min) Discussion Q3-Q4 Monday Agenda for WGM reports from other countries and the PASS SAEAF Alpha project'
   • Don, Pat and Richard have the floor to discuss Monday’s Q3/Q4 meeting agenda:
   • Don: Outline the path for the specific artifacts to Consent work being built upon to take the information model and map it into a service environment; isolating the capabilities, specifying the semantics for verifying the input and output, generally making it service-ready. Some of the questions being asked in the previous discussion related to the role of the CDA. Alternatives to a service presentation and how we would expect Access control engine to request consent policy information and bring it in. There needs to be standards that are mappable into schemas and value-sets. Seems there are two related efforts going on that Ioana has proposed today and it may be appropriate to have further discussion today before we go into next Monday.
   • Pat: Don has outlined the approach we planned to take – take the Use cases, identify them in the DAM, extract the requirements from those use cases and identify capabilities. There’s been good discussion around the management side versus execution side and we need to make sure that as a for group we’re in synch in terms of specifications for the management of Consent Directives or the management of any Privacy or Security policy versus the execution of those policies.
   • Don: we were very focused on the execution aspect of it. In a lot of ways that payload element carries the Consent Directive information or the decision from a policy engine processing Consent Directives and there may be some overlap.
   • Mike: You may have missed the last hours’ call Don. There are currently two efforts underway in HL7 to create Security and Privacy information models with a bridge between them being something called the Patients Constraint catalog. I would view the work being done here, a CDA representation of a patient’s Consent Directive as something that would populate this constraint catalog which is the expression of the patient’s privacy and computable ways in which the Security system can support. This is the bridge between the Privacy management side and the Security enforcement side
   • Don: OK. And this is a repository that the access control system can query?
   • Mike: Yes
   • Don: So what I’m talking about in that context is specifying an unambiguous service interface, so that the query, the request for that information is well-defined. That’s where we’ll need to cooperate. The Information model in terms of completeness has to have the same elements on both sides.
   • Mike: Are you defining the specification or the capability?
   • Don: Capabilities and agreed-upon semantic signifiers about the information – what is being passed back and forth – usually these days described as a schema. In return, the response includes the policy statement which may be in an XACML form or some other form, is passed back to the access control service. That’s the area where we’re concerned about. A compatible information model is essential for both of us.
   • Does this answer your question Mike?
   • Mike: Yes, because in the SOA work – the actual specifications are out of scope for PASS where we’re defining the services and the capabilities, we’re defining requirements, trying to focus on whether we’ve actually defined any specific vocabularies so far; I don’t think we have?
   • Don: No, I don’t think we have.
   • Has the SAEAF environment changed any of that?
   • Don: I think gives us license to address whether it’s necessary to have an implementable…
   • Mike: But for whom? Is this a US-Realm view?
   • Don: No, I hope not. I’m talking about the Structure, SOA, what’s expected at the interface, if we have the service that defines where those Consent Directives are aggregated and the Access Control engine is requesting the information it needs, the policies, Consent Directives it needs; taking about the interface and the form of the request, but most importantly about is the form that the response that includes the policy information, what that format is.
   • Mike: The data is contained in the Constraint Catalog – definition of what gets passed is there. Some of that work is on-going.
   • Don: And those are name-value pairs, or they can fit in a structure of an element in a schema.
   • Mike: Right now, they are a proposed class in the information models
   • Don: It’s going to be Important that those information classes are common or easily mappable between information models and then everthing will work out fine.
   • Mike: Agreed. It’s the intent to make them mappable.
   • Rob: Mike, I have a sense but I don’t now if I am in tune with how you envision how the Constraint Catalog will interact with the two sides of the process. Can we have a presentation or something that has visuals, obviously it won’t happen before the meeting and we can talk about it in Atlanta. If everyone else gets it great, we can talk about it one on one.
   • Pat: I feel the same way. Where I’m coming from is (dropped off call). Group feels that it would be great to have a presentation like this.
   • Mike agrees – a powerpoint to tell the story would be good.
   • Rob: There was discussion from the Security meeting a month or so ago dealing with the need for a legal binding contract – the issue is that someone in HITSP says we need a new construct. But what I understand is the interaction process between a management agency and an enforcement point, is that just needs another step in the interaction process where the enforcement entity responds yes, I will enforce this and it becomes some kind of a legally responsibility. I didn’t understand the conversation that this becomes a whole new kind of negotiation process. You stated something like the management service has to give the enforcement point the final policy.
   • Mike: I’m tying to use those terms because there are several use cases here: one is a manually driven one, one is an automated one and one is an emergency situation so the final state is that however you get there regardless of the process or the use case or exactly how its formulated, there’s an authoritative repository which belongs to the management side because they are in control and make management decisions about it and it contains the authoritative version of the policies, patient consent is a kind of policy that’s going to be enforced. And that’s what the access control system needs to see. It is not responsible for making the policy it responsible for enforcing it. All this discussion, whatever happens on the front end, it all boils down to on the management side saying this is the authoritative policy, it is in this repository. From there we can do things that Tom’s interested in, a pull of that or the NHIN subscribe model against that. The key thing is to come up with this thing and the content of that is what we’ve been talking about in this meeting, potentially using the CDA.
   • Rob: I get blocked somehow. How do we reconcile conflicts (negotiation)/differences. We haven’t discussed how this would happen. In a HITSP context, whatever. Who would become the final authority?
   • Mike: It’s a legal decision. In the US, the provider is entirely in control. They do not have to accept and enforce any policy that’s proposed by a patient. Once the provider has accepted the patient’s constraint, it becomes enforceable – legally binding. But providers are only obligated to accept a patient’s constraint and either accept or deny it.
   • Rob: I’m happy with legally binding but I’m not sure I agree with the previous part of your statement. That’s another conversation.
   • Mike: This is just HIPAA law.
   • Rob: This goes beyond HIPAA with Part 2 kind of stuff and in the new environment ONC and the US Realm, the ONC trying to come out of a broader framework.
   • Mike: There’s nothing I’ve found in ARRA that really gives us any additional law that defines this effort.
   • Rob: HIPAA is just one context and ARRA has expanded the scope of HIPAA, as part of Consumer Preferences they are trying think more broadly about what will be required and they aren’t being restricted just to HIPAA. When there are conflicts, complex situations, what do you do? Hoping that we’ll get into the flexibility stuff and that PASS will provide some insight into this.
   • Suzanne: Coming to the close of this meeting. Don, do you know how much time will be needed for the Monday afternoon meeting?
   • Don: Q3 & Q4, but we’d be happy to accommodate other business. We can use
   • Rob: You mean like Report-outs?
   • Suzanne: Yes and other projects. On the agenda for the CBCC and Security meeting: discuss the Security DAM ballot while both teams are there
   • Mike: Stuff that needs to be discussed between the Security and CBCC teams that we are mutually engaged in. The DAMs are things that we are both joint sponsors. I’ve been negligent in getting the Security project out and approved. One thing is to get a vote by the committees on Security project.
   • There are at least four projects to discuss, the two DAMs, Jonathan’s PASS SAEAF Alpha project and conversation about the project that was just proposed – the CDA project.
   • Each project has to come with it’s own resources – the CDA proposal already a staffed project and is funded, but is looking for additional stakeholders
   • Joint Session is Monday Q3/Q4. Want to make sure everyone who is unable to join these calls is able to make their comments and discuss.
   • Motion to adjourn - Seconded@3pmE ST

Back to CBCC Main Page