November 24th 2009 CBCC Conference Call

Attendees

• Kate Bolster
• Steven Connolly
• Mike Davis Security Co-chair
• Tom Davidson
• Suzanne Gonzales-Webb CBCC Co-chair
• Allen Hobbs
• Don Jorgenson
• Glen Marshall Security Co-Chair
• Steve Meyer
• John Moehrke
• Milan Petkovic
• Pat Pyette
• Scott Robertson
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida

Agenda

1. (05 min) Roll Call, Call for Additional Items & Accept Agenda
2. (10 min) PASS Update
3. (25 min) CDA R3 Proposals

Minutes

1. Actions:

• Team: Please review the CDA R3 Proposals on the CBCC wiki. A vote will be taken to officially endorse the proposals in the next meeting.
• Team: The update to the PASS Access Control Conceptual Model version 0.6, is now available on the PASS Wiki site. This will be discussed in PASS Conference Call Monday 11/30

2. Resolutions:

• Despire concerns we are moving too fast to ballot the Consent Directives Implementation Guide based on CDA R2, we will continue as planned and ballot the CDA R2 Implementation Guide. this link doesn't work, needs update from Ioana
• This is because CDA R3 is at least one year from publication, and perhaps even longer (see CBCC ListServ response to Tom Davidson's 11/24/09 email to Liora Alschuler).
• CBCC WG to attend Structured Documents WG meetings related to CDA R3 Proposals to ensure CBCC proposals are adopted into CDA R3.

3. Announcements:

1. Response from Liora Alschuler/Structured Documents Work Group on 11/24:
   • "Current plans call for an initial ballot in May, 2010. If previous CDA releases are a good indication, it will take 3 ballots, possibly spread over 4 cycles, although could be shorter (or longer)."

4. Updates/Discussion:

PASS Update

1. PASS Access Control
   • Available on Wiki site. Version 0.6 will be posted by Nov 26.
   • A formal walkthrough to be conducted in the PASS meeting Monday 11/30
2. Pass Architecture Framework
   • Document will be sent out for review in Monday PASS Call via the list.

CDA R3 Proposals (related to support for the CDA R2 Implementation Guide)

1. Presented the Map of Consent Directive Domain Analysis to CDA R2 document to CDA R2 mapping document the Structured Documents workgroup on 11/17/09 to discuss some of the concepts that it is not clear how they map to CDA R2.
   • SD WG provided useful guidance on the support of scanned signatures using ObservationMedia
   • Based on their feedback, although the deadline has already passed, they advised us to submit enhancement proposals for CDA R3 which they will consider. Four CDA R3 proposals have been submitted on the Wiki site for consideration.
   • These proposals have already been included on the CDA_R3_Open_Proposals site as well.
2. Please review the following proposals so we can discuss them on the next conference call. It makes sense for the CBCC WG to endorse them as well as to elaborate on anything necessary to give Structured Documents a more complete view of what we're asking for in Release 3.
   • Role codes for information recipient and other participations
     • Currently there is no way to specify functional role in the CDA . The proposal requests the addition of two fields:
       • functionCode to POCD_MT000040.InformationRecipient (Participant)
       • code to POCD_MT000040.IntendedRecipient (Role)
     • There are two separate concepts: structural and functional roles. There are times when you may need to communicate both roles
   • Confidentiality code support in ClinicalStatement choices
     • Currently there is no way to specify the confidentiality and sensitivity of a act, observation, procedure, etc. choice in a ClinicalStatement. This information is often required in specifying the Consent Directive or Privacy Policy.
   • Digital signature for header participations – author, authenticator, legalAuthenticator
     • Currently there is no way include a digital signature in the document header along with the identity of an author, authenticator, or legal authenticator. This information is often mandatory for legally binding documents.
   • Participation sequence number
     • Currently there is no way to specify the order in which participations or act relationships are to be processed. In some cases the order/priority is relevant to processing definitional elements (e.g. privacy rules).
3. CDA R3 Publication Timeframe Discussion
   • Question raised whether we should proceed developing the IG using workarounds under R2, or wait for CDA R3?
     • Ioana: I have no intention to stop the debate, but in my personal view, it makes sense to have a CDA R2 representation of Consent. Particularly for the NHIN prototype. If that is not an overriding assumption, then we could wait for CDA R3.
   • Tom: SSA can survive with the BPPC scanned document for now. I have a concern that we may publish a CDA R2 guide, but then shortly come out with CDA R3 that will be vastly different. (causing backward compatibility issues). What are the thoughts of the group? I am happy to move forward with the CDA R2 IG if that's the consensus.
   • John: Do we need to encode the policy content in RIM-based encoding?
     • Why are we working so hard to get the Consent DAM encoded in something that is unnatural. Why don't we create a consent schema that is natural to what we're trying to encode and that becomes a blob to the CDA. It is still computable to those who understand the "CLOB"
   • Tom: That's the argument of embedding an XACML document into the body of a CDA
   • John: We should support multiple encoding languages
   • Tom: Because it is XML, it is always possible to translate the signature and legal text into an XACML statement within the CDA.
   • Ioana: It's nice to have an implementation-neutral representation, but how do you ensure interoperability? (e.g., you send XACML and I'm expecting DRM). This is the argument for why we're trying hard to relate things to RIM-based entries in a CDA document.
   • Concern was expressed that XACML approach will be too enterprise specific
     • The XACML profile uses vocabulary that is standards-based (for the purposes of interoperability).
     • There are two ways that you can describe the DAM concepts to make them interoperable:
       • 1. Create a design information model, e.g., Refined Message Information Model (R-MIM). Map everything in the DAM to the RIM which is an interoperable representation. Everything that appears in the DAM #***2. Map the DAM to a document model. This is more challenging.
     • Whatever on-the-wire representation, those concepts can be mapped to XACML, M-PEG4, etc. The concepts are in the conceptual model and the platform independent specific or platform independent models can be separate.
     • CDA does not support R-MIMs except as extensions.
       • We could create a RIM extension (which results in a one-of-a kind document), or we could have a standards-based approach, similar to Data Consent R1, and create an information model based on the RIM using all the HL7 relevant coding systems
       • Mike: We should Identify a set of supported consent directive policies, privacy constraints and policies (a generic set, not with supplied vocabulary). Then populate those policies in a CDA message with #**Sounds like there isn't anyone clamouring for a CDA R2 approach to Consent Directives?
       • Tom: I am not aware of the need. NHIN is coming out with BPPC support and some internally developed XACML mechanism (because there is nothing else available).
       • NHIN not trying to be complex. Only very simple directives will be specified at first, opt-in, opt-out.
     • Some under the impression that NHIN Connect 2.3 has the ability to support more complex policies.
       • The specs do. But internally, they can only support transport, they can't evaluate it without customizing the policy engine.
       • That's the capability of the Policy Evaluation Engine – the gateway.
   • Two requirements are needed from the CDA to represent Policy:
     • Human readable text
     • Quality statement that defines the human readable information in machine language
   • Ioana: This is the scope of the CDA R2 IG
     • Backward compatibility between CDA R2 and CDA R3-based Consent Directive should not be an issue, because we're creating RIM-based extensions.
     • Everything in CDA R2 is re-usable. The CDA R3 IG will yield documents instantiated the same way, except the extensions would be part of the CDA R3 specification. (Instances will validate against CDA R2 & CDA R3).
     • Looking for input from the group: should we use RIM-extensions? These are proposals for R3, but they can also be the basis of CDA R2 extensions.
       • 1. A CDA R2 schema won't recognize them unless an additional schema is declared, and these attributes would have to be declared as optional.
       • 2. If our CDA R3 proposals are approved, the R2 RIM-based extensions would be fully compatible with CDA R3.
       • 3. One concern is whether or not the proposed attributes will be adopted and included in CDA R3.
       • 4. Good news about CDA R3, there are only two options: they either add the attribute or not. They will not assign the same semantic meaning to some other part of the structure. There is the assumption that by presenting these attributes, our WG has the domain expertise.
       • 5. However, if these attributes are not accepted, and we've created a (one-off) CDA document with extensions, anyone implementing this way will have to use the extensions.
     • Clinical Statement (Act – which may be anything) is quite flexible. The problem is not that it is intended only for clinical use, but that it's defined to narrowly and we need these additional attributes.
     • The SD WG suggested that we submit these change proposals.
       • If we want to influence CDA R3 in any way, it is not sufficient to show up on calls; we have to submit change proposals.
     • Another issue is the Document expiration date: currently there is only a single timestamp – so we’re unable to capture data range. The Service Event has a duration, but the document only has a single date.
       • BPPC uses the Service Event. (This is a workaround because Service Event is the consent directive issue date.)
   • If we expect to ballot (a CDA Implementation Guide) in January, we can submit the CDA R2 ballot as planned, or change the scope statement to make it CDA R3.
   • Question: The rush to implement consent directives via CDA R2 seems US-realm specific.
   • Not clear what the rush is. While this is important, it's not clear that by rushing, that we will get it right. HITSP Consumer Preferences is currently analyzing the Consumer Preferences Use Cases. Out of that analysis will come gaps. It looks like we're presuming what those gaps will be and hurrying to fill the need. A more pensive approach makes more sense.
   • The scope statement already indicates how we intent to ballot this item. To change the ballot level now means you have to take it back to the TSC. This will impact the project schedule (adding another year to the project is a major change.)
   • A DSTU is intended to be reissued. If we pass in Jan 2010, people can use it, we get feedback, and then we can reissue it again after CDA R3 is published. We will make it clear that people are taking a risk if implementing CDA R2, that they will have to re-work things when CDA R3 is available; that this IG is only for trial purpose.
   • This also keeps the momentum going (by moving forward with CDA R2)
   • There is no need to take a motion to move forward with the intended CDA R2 ballot since we have already indicated our intention.
   • A comment will be added to the CDA R2 document that indicates changes will be necessary once CDA R3 is published.
   • Response from the Structured Documents Work Group on 11/24:
     • Per Liora Alschuler: Current plans call for an initial ballot in May, 2010. If previous CDA releases are a good indication, it will take 3 ballots, possibly spread over 4 cycles, although could be shorter (or longer).

Meeting was adjourned at 3:00 PM EST. No significant motions or decisions were made.

Back to CBCC Main Page