November 12th 2009 CDA R2 Implementation Guide Conference Call - Joint Call with Structured Documents

Attendees

• Tom Davidson
• Suzanne Gonzales-Webb CBCC Co-chair
• Gaby Jewell
• David Katz
• Rob McClure
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tammy Williams

Agenda

1. (15 min) Roll Call, Meeting Calendar with Structured Documents and Introduction to CDA R2 Implementation Guide Project
2. (45 min) Review CDA R2 IG Mapping/Gaps Document

Action Items

Note: A follow up meeting with Structured Documents has been scheduled for Tuesday, 11/17 to continue discussion, receive feedback and to introduce enhancement proposal for CDA R3 (to allow both scanned document and structured text within the XML body)

• Ioana to update the cardinality on UserIdentity from 0..1 to 0..* in the Consent Directive Information Analysis diagram
• Ioana will send out a revised version of the draft CDA Implementation Guide and a reminder about the Tuesday 4-6 PM EST meeting with the Structured Documents Work Group

Minutes

Ioana presented material from the draft CDA Implementation Guide that included a model diagram and a first draft Mapping Consent Directive Domain Analysis to CDA R2 using XPATH notation. The left column refers to the Consent Directive classes and attributes, and the right column, to elements within the CDA structure.

• Project Background:
  • The CBCC WG has had a project to identify the environment for representing Consent Directives and Privacy Policies. That project produced a Composite Privacy Domain Analysis Model (DAM) that includes among other artifacts, an information model for a Consent Directive and a Privacy policy. A new project has been approved to take the DAM and map it to a CDA R2 structure to see if it will represent the structure of a Consent Directive using Structured Documents architecture.
  • The Consent Directive Information Analysis diagram is a class diagram taken from the Composite Privacy DAM.
  • Tom pointed out that the existing HL7 V3 specification for Data Consent (approved a couple of years ago) contains a lot of this model. That model combines some of the policies with consent overrides and is even a little bigger than what is needed at this point. As part of the domain analysis, we separated the privacy policy specification from consent directive, and the Consent Directive is expected to reference specific privacy policies.
  • Tom: I also have questions about some of the modeling they reflected. That consent that they modeled, it’s one, but it references potentially many consent directives and many policies, so it seems to be a realization of a Consent that allows or denies access but doesn’t have the ability to express both allows and denies in a single form.
  • Ioana: That version (currently normative) was supposed to be replaced based on the content of this analysis. In May of this year, we balloted only for comment a new version of that topic, using some of the service-oriented concepts put forth by the Services-Aware Enterprise Architecture Framework (SAEAF). This was done to facilitate the separation of concerns so you can have a very rich Consent Directive that stipulates several different rules within it that map to a security policy. This simplified consent directive diagram shows you the contents of what we have found to represent the information in a Consent Directive.
• UML Notation Review
  • Classes: have properties or attributes
  • Attributes have a type. If the attribute is a coded attribute, that type is expressed as an enumeration. E.g., The provider taxonomy is a placeholder for the HIPAA provider taxonomy. It’s basically two value sets – a structural role code is the reference to a value set that may come from ASTM codes. Sensitivity and confidentiality are coded concepts.
  • Then we have relationships between classes. In a couple of places we’re using specialization, generalization. So a published consent is a specific kind of ConsentDirective that is available through a URI, so that is a specialization of ConsentDirective that adds an additional attribute to the attributes already supported by ConsentDirective. The notation is the open triangle association. Similarly a privacy policy may be published, and so requires a URI as well.
  • Other notation elements are associations and aggregations. A ConsentDirective is basically a structure that contains other kinds of information, so it is composed of other objects. The solid diamond is used.
  • In other cases where we’re suggesting this object references another object, we use a simple direct association.
  • The direction of the association tells you how this particular structure would be traversed. You need to have a reference to a ConsentDirective to find the privacy policy to which it’s related. Bidirectional associations do not have arrows (can traverse either way).
  • Endpoint names describe how objects relate to each other. The opposite end describes the relationship.
  • This notation describes how these objects relate to one another. This is the conceptual model we’re trying to map to CDA R2.
  • A ConsentDirective consists of several ConsentRules that refer to specific operations
    • OperationTypes can be enabled or disabled.
    • ConsentRules can be associated with obligations (obligationCode) and a specific purpose-of-use (purpose) and they may have priority (that's what ConsentRule.sequence indicates). **ConsentRules can refer to specific target: InformationReference. One element that appears in some privacy policies refers to the type of insurance coverage responsible for creating some information PolicyProgramSource. So for example, CFR 42 Part II does not apply to people who have PrivateInsurance, but does apply to information created by PublicServices.
    • Some objects are common across Privacy and Security and are being used by the Role Based Access Control (RBAC) permission catalog. The OperationType and the InformationObjectReference are elements of a Permission.
    • There is also information about the information recipient and current custodian. These don't stand out as separate classes. They are an association between a ConsentRule and a ProviderOrganization or an InformationReference and a ProviderOrganization.
    • You can specify not only an organization, but you can specify consent-specific roles of users that may take an action on the information. You can go so far as to specify not only a structuralRole, but also a functionalRole and even a UserIdentity. So Consents can be expressed you down to very specific individuals who may be able to access, or not access, client information.

CDA R2 Implementation Guide – Discussion and Initial Feedback

• After initially sending out the draft, it occurred that it would be useful to lay out the document structure. This will be included in subsequent updates to the document.
  • The CDA consists of header and document body. The document body contains sections and sections contain clinical statements. The assumption for now is that everyone is familiar with the document structure.
• The challenge is to find the appropriate representation for these analysis concepts in a document structure.
• The Mapping table describes the mapping of concepts to specific elements in the document. Those could be specific element or attributes in the CDA XML schema.
• Cursory mapping revealed a few places that reveal issues or gaps.
• A primary objective is to represent the Consent Directive as structured information as well as being able to represent a Consent as a signed, scanned document.
  • One possibility is to include a document by reference.
  • The other possibility is to include the document as an image, but the only choice we have a in a structured body of a CDA R2 instance is a Diagnostic Image (DI). We could suggest to the Structured Documents WG that we could use a DI entry to support the document image. Not the most elegant or ideal way. Most on the call did not think this is a good idea.
• Tom: Are we going to attempt to break a Consent Directives into its various sections?
• Ioana: We could break it down into sections, or we could break it down into entries. We could include the entire Consent description in the section text. We could include the target, information reference, the operation,
• Tom: We'd be using multiple clinical statements for each individual area that we want.
• Ioana: We could use one or more entries. The more I think about it, it makes sense to use one Act, which corresponds to the ConsentRule, and Observation that would correspond to the InformationReference. Observation would always be associated with ActReferences to represent the InformationReference. The rest – InformationRecipient, Custodian, Role, UserIdentity, Consenter, Client, and PersonalHealthRecords. Those would be part of the header information. The only entries would revolve around the set of ConsentRules as Acts and InformationReference as Observations.
• Question was raised about confidentiality
  • Confidentiality and Sensitivity are very important attributes of the information you are referencing in the Consent.
  • Tom: Where is confidentialityCode carried if we go down to the Act level? The last one is at the section level. CDA has removed some of the attributes that would typically be there.
  • Ioana: Confidentiality would have to be an associated Act. It's been excised.
  • There is already an Act.confidentialityCode declared in the RIM. Any time we need to work around the fact that attribute was not picked up in the clinical statement, we need to mark that as a gap and bring it up with Structured Documents.
• Tom: Given all the variations, if we attempt to identify them, Structured Documents can let us know, this is good, this is not good. I know they don't like widening out on the CDA. So the only option might be to request in for an R3 enhancement that puts it back in.
• Ioana: There are several other things that that affect Digital Signature, Signature Type – those are only available on the Legal Authenticator.
• Tom: Legal Authenticator only supports signature on file. You cannot embed a signature.
• Ioana: I have marked Digital Signature as an outstanding issue for us. There are going to be some gaps that we can overcome by saying these will be available in a CDA R3 version of this document.
• Tom: If you read some of the current descriptions for some of these elements – Authenticator, Legal Authenticator, are we twisting the interpretation a lot just because it exists there.
• Ioana: The idea of a constraint is that as long as we're not expanding the meaning outside what Legal Authenticator means…
• Tom: Then we have to know, what's the interpretation for Legal Authenticator from a Consent Directive perspective. Is it the person at the facility who is the Legal Authenticator since they are working on behalf of the organization whose document this is, versus the person who signed it as being the Consenter? We had the same question in yesterday's CBCC meeting about the definition of Author.
• Ioana: The way the Consent Directive analysis reads now, we have a Consenter and a Consenter could be the Client or could be the Substitute Decision Maker acting on behalf of that Client.
• Tom: It's a matter of the relationship between the Consenter and the Legal Authenticator of a document. Is the Legal Authenticator of the document the person within the enterprise that is accepting the representation of information on the document on behalf of the enterprise? What is CDA's meaning of Legal Authenticator?
• Ioana: The Legal Authenticator is the person who authenticates the Consent itself. So all the information in the header refers to who has signed off on the document at hand. Who is the author, who is the enterer (could be two different individuals because someone at the organization could be entering the information on my behalf but I am the authenticator of that information – the Consenter)? We really only have a single concept of Consenter. That is the individual who signs off on this particular consent directive. It may be the client or the SDM.
• Tom: There is a need for multiple signatures with Consent Directives. There is the Consenter's signature, then the person within that enterprise who witnesses that signature and who accepts the signing of it. There can be two additional signatures required. Let's say a Consenter signs with an 'X', there has to be a witness to it. (This is a rare occurrence but when it occurs, it requires a witness' signature.) There is also the signature of the person who witnesses the consenter's signature. (This implies they 'credentialed' you – you are who you are).
• Ioana: So there are potentially two other signatures that are required; these requirements are not currently reflected in the DAM.
• Tom: The question is, is the organization's representative an Authenticator to the document, or are they the Legal Authenticator because they are the custodian of the document? This gets confusing. One option is the consenter is the Legal Authenticator on the CDA. The other option is from a CDA point of view, the Legal Authenticator represents the organization, the custodian of the document. So in that scenario, for example, an SSA employee. So therefore, the Consenter would be relegated to being an Authenticator on the document. We have a limit with the current CDA because only one element supports a signature value. So this becomes a gap depending on how we interpret. Right now CDA only supports signature-on-file, another gap. I referenced the need to support digital signatures, digitized signatures (scanned copy, the other is I signed a pad, a digitized representation of a signature); the other is an audio signature.
• Ioana: In the Consenter class, we have explicitly included a digitalSignature or a signatureRecorded, which is essentially what CDA does. For a forward-looking specification, it would be preferable to have support for a digital signature. Whether it's exercised or not depends on the implementation but in the CDA R2 specification, there is no place for this right now, so, we don't have that choice.
  • There is one Participation in the header, the Legal Authenticator, that supports anything like a signature. Even the Custodian or the Organization representative can carry a signature.
• Tom: There is a proposal (CDA R3) to expand the cardinality on Legal Authenticator. That would be one option (to support multiple signatures at the document level).
• Ioana: What would be your preference right now for the Organizational representative? Is the Organizational representative the same as the individual who represents the Custodian Organization? Let's refer back to the Domain Analysis.
  • The Information Custodian belongs to an Organization, may have an Identity; may also have a functionalRole. We could use the User Custodian for the placeholder for the person who accepts.
  • Tom: Yes
  • Ioana: So I'm going to say under UserIdentity, that's the person. I didn’t have the UserIdentity of the Consenter here, I did not map it over.
• Tom: Custodian in CDA ties to an organization. So your options are going to be either a Participant or an Authenticator.
• Ioana: I believe the custodian could be an Organization and/or a specific individual. So you could have an Organization and an individual named as Custodian.
• Tom: The model I printed out has a an assigned Custodian with a class code that has a 1:1 and a Custodian organization, but there's nothing related to it being a person, unless it's in the XML and not represented in the model.
• Ioana; I looked at the XML, I must admit. I'll double-check this.
• Tom: From the CDA documentation, the Custodian is the organization that is in charge of maintaining the document. It is not a person. From SSA's standpoint, that would mean SSA is the Custodian of this document. The originator of the document is the Custodian of the document.
• Ioana: I'll double check whether the Custodian organization supports an assigned person. Otherwise we'll use the header Participation to map the representative…If there is a place to group it with the Custodian Organization it would be preferable. Otherwise we'll put the Custodian, the user (human) representative of the Organization part of the header Participation. We have to work within the structure that is available for us.
  • Another thing I could not find for information recipient is a way of specifying roleCode. I don't believe there's an information recipient functionalRole or intended recipient roleCode. I think this may because intended recipient is supposed to be a named person, not a role.
  • The intended recipient can be an Organization, but how do you define the role of an organization?
• Tammy or Gaby: It's the roles within the organization, isn't it?
• Ioana: If that's the case, if you're restricting information access to roles within an organization, doesn't that become defined within the assents or dissents that we realize. So along with the confidentiality code, do not release mental health information, that becomes part of the body doesn't it the because it's the rules associated with this Privacy policy or Consent Directive?
  • Within the entries will be specified what information, for what purpose; within the header, will be specified who's the intended recipient, down to the functional role the user or the structural role of the user.
• Tom: Even in the diagram, the organization doesn't have a role. So the intended recipient would be the organization itself.
• Ioana: The intended recipient can be an organization or a person in the CDA. The cardinality is 0..*. So if you're sending it to the organization, it's up to them to resolve roles: who does what. If you want to specify a specific role of user who is supposed to operate on the information…are you suggesting we should put this information recipient part of the entry, not part of the header?
• Tom: Yes. It becomes a make up of the role. You want to say that only a psychiatrist at the facility can see this information. That becomes more of a conditional mechanism.
• Ioana: I agree. We still inherit the issue that we don't have a way of including…The functional code does appear in some of those entries. That is the functional role.
• Tom: Which are you referring to?
• Ioana: The functional code is an attribute on Participation, not on Role. The information recipient is a Participation, the intended recipient is a Role.
• Tom: Except that the participant role off of clinical statement does not have the function code. It sits on an associated entity, but it's not on all of them. Off the header, participant is an associated entity and it has a function code. But there is not an equivalent down to the Acts and entries.
• Ioana: Maybe we'll use that functional code.
• Tom: What's the purpose? Are you trying to say that I'm releasing the information to this provider organization and only individuals within a certain functional role can see this data?
• Ioana: Yes
• Rob: Are we talking about who can see a Consent versus who can see the data based on the Consent? So if you're talking about who can see the Consent this is not about who can see data based on the Consent.
• Ioana: That's correct, this is about who can see the data that is the target of the consent. I think our proper design is to make that part of the entry, which is in the body of the Consent Directive. It becomes part of the conditions on the information recipient Access Control system. So they need to enforce only those roles that are specified within the Consent may access the information.
• Tom: So if we go down that path, we definitely have a gap.
• Ioana: Where I think it belongs, based on our discussion and Rob's comment, this is not a functionalRole restriction on the person who can read the Consent, it is a structuralRole (functionalRole?) restriction on people who can access information referenced in the Consent.
• Rob: It's one piece of many that are a part of what is a Consent. There are many Consents that could easily not specify a functionalRole.
• Tom: That supports the notion that this should be put at an Entry level. Because an Act or a Clinical Statement can have a Participant role and we could use that to imply the related functionalRole that the condition and rule is going to be applied to.
• Rob: We should probably have a marker somewhere. It might not make sense to have something that travels with a Consent where someone can say this isn't about my data, it's about my Consent, but it's easy to imagine people talking about that possibility. If someone says, I don't want people to see my mental health data in my Consent, just the fact of viewing that Consent may imply those data are there.
• Ioana: It becomes recursive at some point. You could set a marker on the Consent to say whether it is confidential, and then those policies will kick in whatever they are.
• Rob: Set that one aside and note that it is not yet addressed (no use case has been presented).
• Ioana: I'll mark this as a possible new requirement and a gap.
• Richard: Pat Pyette was saying that Consent Directives are potentially more sensitive than the clinical data.
• Rob: This gets to a use case that has not yet been articulated.
• Tom: Why would a consent directive be more sensitive than the IIHI?
• Rob: Because it encapsulates potentially sensitive information.
• Ioana: This is only if the Consent is very detailed. This is something that we should track as a possible enhancement if the use case presents.
• Ioana: Another thing: The Consenter is the Author and Legal Authenticator of the document. It was suggested that the Author may be the organization that allows you to express your consent? Legal Authenticator would be the Client or the Substitute Decision Maker.
• Tom: Author is strange, because if you think of an authorization to release information. Typically this is a canned document, written by an organization that someone signs. So the Author is the organization not the patient signing it. So if you are a PHR and the patient starts writing their own release of information, they would be the Author.
• Ioana: We want to have a choice of saying that the Author is either the consenter (e.g., PHR) or the organization (Release of information).
• Rob: I have some concerns about this use of the word Author. Who put the material that you're seeing into the Consent. In this context, I think when you have something where someone else puts all the stuff there and a person says, I accept this, I think this is unique for CDA projects. I'm worried we haven’t thought this thoroughly. Two aspects, do we know what we nee to have? Is it important to know the creator of the Consent? I think that we do, because we've talked about the fact that organizations will have defined policies and people may accept them or they don't. If we use Author to capture that, I think this is reasonable. I think it means a slightly different thing than the way Author is used by other CDA documents. If you use Author in that particular way, have a very clear understanding of the use case and how it is similar or different from other CDA use cases. And secondarily, that the consenter signing it, has a unique way of communicating something else. Most of the time a physician (Author) creates a discharge summary and signs it, it's a very simple. Here it's very different. It's somebody else said something, I read it and I say, I agree.
• Richard: It becomes My Policy.
• Tom: Can I flip this around? The CDA definition for Author says represents the humans or the machines that authored the document. Let's say that a physician dictates notes, they're transcribed, and goes into an EHR and from that, a computer generates the document that a physician legally authenticates it. The physician isn't the Author of the document, they are the Legal Authenticator.
• Ioana: This is not that kind of thing. My understanding is that the thing you're signing off is a form, and that is there for all time. Someone could dictate it to you and you could write it in long hand and it would be the same thing.
• Rob: I'm not sure it is sufficiently different. By signing it, I've taken on a responsibility that it's mine. I'm our context, we want to track whose policy this was originally, who is it tied to. I don't know whether Author is the place where we want to capture that it's Shady Grove's hospital's policy that I'm agreeing with.
• Tom: We should track this as a gap. There are some other constraints that we should consider. It is a required element in CDA. This is a weird morphing. Author is a very interesting concept and meaning that may not always apply to a Consent Directive or Privacy Policy. Custodian may be a place to capture the information that distinguishes the originator of the "policy" that the consenter (Author) has signed off on.
• Ioana: We have reference to a Privacy policy, so if you want to say that this Consent is based on a HIPAA notice, or CFR 42 Part II…
• Tom: In that example, would that be a parent document in that scenario?
• Ioana: The parent document, the way the header is supposed to work. If you're thinking about the parent document in the CDA header, my understanding is this is referencing a specific document that may be another consent directive this one is replacing. I think this should be part of the entry information. Because you want to be precise. This is not necessarily another document.
• Tom: The implication of crossing out something on a form would be conditions within the entry. Just trying to keep track of the root policy that we started with.
• Ioana: If you want to track the root policy, it should be put in the entry. That is my recommendation right now, but I could be persuaded otherwise. I think we need to keep the header parent document, the related document, parent document id, as the Consent Directive that this one is replacing. Because we do have the idea of revoking and replacing Consent Directives. If we want to support that, this is the place. I'll delve into this to see if we can also include the Policy author. We don't have this in the Domain Analysis now; we'll have to add this as a new requirement. In the Privacy Policy description we have extensive associated classes, which talk about who the Author is. So we might put this a merging requirement to include as part of the Consent Directive as well.
• Rob: Remember, this is separating the idea o authorship based on someone's original policy. This has been an on-going component of the entire analysis. The Security realm thinks this starts with the security or privacy policy for an institution and then the client is agreeing with or modifying it so that IIHI is managed in a way that's consistent with that institution's normal process.
• Ioana: In Canada, they do have the idea of a Consent Template that contains the prevailing organizational and jurisdictional policies, which a client can select. So the thing we have here, if your Consent Directive is derived from zero or more Privacy policies, you can name them and reference them.
• Tom: Was that the intent of the Data Consent R-MIM? It has a zero to one privacy policies with a source of being referenced.
• Ioana: If I recall correctly, the Data Consent R-MIM May 2007. In that model, it has the idea of replacing Consent Directive, it has the previous Consent, the next Consent, a few things that imply state. It has a reference to an existing privacy policy and a reason code for overriding it; all of these things are in one place. The point of this domain analysis model was to revise that Data Consent release 1. There is an approved normative and there is a draft. The draft would have to conform to this model. It may be worthwhile to continue to map the DAM to an RMIM, and make sure we've covered everything. Because if we cannot support it in CDA, we need to a have a good idea of how we could support it with R-MIM. I think we have a very precise set of requirements, so that's part of the issue. On the left hand side of this mapping table, we have a clear idea of what we want.
• Tom: The clinical document, while Consent Policies may be considered a clinical document, it's really about medical information and this is about accessing medical information so we have very different requirements.
• Ioana: It's also about financial information. There is a different limitation as well. A document is intended to communicate from one human being to another human being. The structure part of it was an after thought. You could communicate a lot between human beings without touching the structure. And we're trying to fit everything into one structure.
• Richard: And you mentioned that you can only do one or the other: send a scanned document or structured information about a Consent.
• Ioana: If you're trying to send a scanned consent directive you need to make a choice that you are not going to use a structured body.
• Tom: There is an R3 proposal to allow for structured body text, which would allow for the sending of a scanned document along with the structured information.
• Ioana: I think one of the things that will happen is that if we have specific R3 requirements for CDA, we can submit a change proposal. Are they still taking change proposals for R3 CDA?
• Dave: I think there is a week, if that.
• Ioana: In addition to submitting a change proposal we need to be more involved with Structured Documents WG as the change proposals are being discussed.
• Richard: Who will take that responsibility?
• Tom: SSA sits in on those calls. CDA R3 enhancements calls are held Tuesday's 4-6 PM EST.
• Ioana: We are going to attend next Tuesday, 4-6 to discuss our outstanding issues, and maybe our action item is to document the change proposal.
• Ioana will send out a revised draft and a reminder to join the Tuesday 4:00 PM call. Discussion should be continued on the CBCC listserv.

Meeting adjourned at 2:25 PM EST