October 20th 2009 Security Conference Call

Security Work Group Weekly Conference Call

Attendees

• Bernd Blobel Security Co-chair, absent
• Tom Bonina
• Steven Connolly
• Tom Davidson
• Mike Davis Security Co-chair, absent
• Suzanne Gonzales-Webb CBCC Co-chair
• Jean Duteau
• Don Jorgenson
• Glen Marshall Security Co-chair
• Milan Petkovic
• Pat Pyette
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Craig Winter
• Pat Christiansen

Agenda

1. (05 min) Roll Call, Approve Minutes & Agenda
2. (25 min) Security Use Cases Analysis Discussion
3. (30 min) Harmonization Proposal for review

Minutes

Action Item: First agenda item for next week’s Security meeting: Review Harmonization proposal (sensitivity and confidentiality)

1. Security Use Cases Analysis

• Ioana presented updates to the Security Use Cases found on the Security Wiki site based on Mike’s request for a gap analysis (map Use Cases to existing classes in the DAM).
• So far, the only other use cases that have been submitted for addition to the DAM have nothing to do with interoperability. There is a scenario that deals with data integrity which of potential interest.
• One use case was referred to PASS Audit – the Accounting of Disclosures. This is because this use case more properly belongs to the Structure and Semantic Design Steering Division as it is an end-user application, not a tool or building block. This use case is potentially two distinct use cases: audit data collection and disclosure accounting. What might be expected from PASS is a service to supply some input data to the disclosure accounting application.
• There are two use cases that appear to be based on the EHR functional model and have no explicit health care related information requirements for Security (Access Control in particular). As as result they are deemed out of scope.

1. 1.5 Enforce authenticity of legal healthcare documents
2. 1.6 Enforce secure exchange of health records

• The Introduction section contains the Security Analysis Information Model and sample terminology to support the coded concepts in the model.
• The classes that support each use case in the list were identified. Each use case contains a separate diagram depicting those classes involved in the use case.
• The DAM will clarify that the example terminologies are not intended to be prescriptive value sets. They are for illustrative purposes only in order to grasp the contexts.
  • There may be a variety of code sets for a single attribute, e.g., confidentiality.
  • There are existing value sets for certain information objects that could be referenced in the document, for instance, the RBAC normative specification or some other coding system. But values for those code sets will not be included.
  • Specific projects or national profiles would reference very precise value sets or coding systems as needed.

2. Harmonization Proposal – Sensitivity and Confidentiality

• There was considerable discussion about the Harmonization proposal (sensitivity and confidentiality) which we were unable to complete by meeting's end. There were concerns raised about endorsing the proposal without further discussion. This will be the first item on next week's agenda (10/27).
• The Meeting Minutes message announcement to the ListServ will request participation in next week's meeting in an effort to gain as much input from the Security WG as possible.
• The proposal will also be sent to M&M for their review.

Summary of the issue:

• In version 3 of the HL7 RIM, the attribute Act.confidentialityCode combines the concepts for confidentiality as defined by ISO with that of sensitivity. (Act, is the base class for all classes that document clinical and financial information for health care)
• In the HL7 RIM, the definition for confidentiality is consistent with ISO while the usage notes (how that particular attribute would be used) are consistent with sensitivity.
• The first comment is to make sure the definition for confidentiality and the usage notes are consistent.
  • When this issue was brought up in Atlanta in September, it was stated combining these two concepts into a single attribute was intentional.
  • However, if you have a Privacy or a Security Policy that deals with sensitivity but does not affect confidentiality, or if you have a policy that deals with both types of information attributes and you want to make different statements regarding levels of sensitivity and confidentiality, you are unable to make them if the semantics are mixed into one attribute.
• The second part of this proposal is to add sensitivityCode to the Role class and Act class in the RIM. Right now if you read the definition for the Role confidentialityCode it does not say this is the confidentiality of the information this role may act on but rather this is the confidentiality of the role itself. I’m not even sure this is correct since there is no intrinsic confidentiality assigned to instances of Roles. But we do need to say that a specific role has a specific sensitivity, for example, a specific type of user can use the classified information.

The following is a transcript of the Security Use Case and Harmonization proposal discussions

• Glen: We should not be developing any new standards
• Ioana: We’re not creating an additional standard. We’re describing how existing standards can be profiled. In the domain analysis, we identify those information attributes that are resources specific to this protocol.
• Glen: Would HL7 be providing the profiling on this?
• Ioana: That would be done by other organizations like OASIS and others
• Steve: Back to the terminology diagram, are we are making a distinction between sensitivity and confidentiality?
• Ioana: Yes we are. I’m not even sure there is a relationship between sensitivity and confidentiality or if they are just orthogonal concepts. Take the specialization relationship in the diagram with a grain of salt.
• Glen: When I think of something as sensitive, I think of a lab result that has to be discussed with the patient before it’s released. It doesn’t mean that it’s private; it means that it needs special treatment.
• Ioana: If there are no other questions we could move to the next topic.
• Steve: I have a question about Use Case 1.5 Enforce authenticity of legal healthcare documents. Is this in scope? There were a number of emails over the last week pertaining to this use case. I don’t know whether there is consensus on what this means.
• Ioana: Are you suggesting it should be kept in scope?
• Steve: I’m suggesting this should be out based on Mike’s statement in last week’s call.
• Glen: the concept of legal EHR is a national issue. It is currently under discussion in the US HIT Policy Committee in various ways. Because of that, I don’t know whether HL7 can define this except in the national context
• Steve: It’s not so much a legal question as it is a non-repudiation question
• Don: The way this use case is worded, Enforce Authenticity, it sounds like it’s related to behavior, and in terms of behavior would probably be out of scope. In terms of capturing the information model needed to support these behaviors in the context of policy, that’s what it seems this is about.
• Ioana: Is there anything apart from requiring digital signatures as a means for ensuring authenticity of a health care record that makes this specific to health care?
• Steve: Last week, we said we are focusing on access control. This use case isn’t strictly dealing with Access Control.
• Ioana: My brief analysis shows there are no specific health care requirements. There are some technological requirements; same is true for secure exchange of health records. You need to apply consistent use of technology and algorithms, but we don’t have any requirements to constrain an existing standard that are specific to healthcare. What is the consensus of the group?
• Pat: I have no problem constraining the analysis to authorization, but this needs to be called out in the Document. Calling it a Security DAM implies you’re dealing with every facet of security. You might consider either changing the name of the document or in the introduction, call out the fact it is restricted to Authorization and Access Control
• Ioana: We make it very clear what is the scope of the analysis for version 1 of the Security DAM in the introduction – Version 1 covers A, B & C. We will have very explicit references to the use cases used for the analysis in the Appendix. We don’t have flexibility to rename artifacts due to the tie in with the balloting and the project scope.
  • We will update the website to distinguish those use cases that are in scope for version 1 and those that are out of scope (but which may be handled in future analysis). Included will be a comment documenting the reason the use case is currently out of scope.
• Steve: Is the negotiation use case still in scope?
• Ioana: Yes, Negotiate Privacy Policy use case is on the wiki. The outcome of negotiation is the agreed upon policy. I’ve illustrated this with the information model that’s for the assertion of a specific type of policy. That could the be result of a one time declaration or the result of a negotiation, but you would need some type of structure in which to store and exchange the result of the negotiation. What information is needed to store the outcome of the negotiation?
• Richard: Is it the negotiation process itself? Does it include the four parts of XACML?
  • PAP- Policy Administration Point - Point which manages policies
  • PDP- Policy Decision Point - Point which evaluates and issues authorization decisions
  • PEP- Policy Enforcement Point - Point which intercepts user's access request to a resource and enforces PDP's decision.
  • PIP- Policy Information Point - Point which can provide external information to a PDP, such as LDAP attribute information.
• Ioana: I don’t see those four criteria in this use case Richard. Could you review and see whether anything is missing?
• Milan: Is Enforce secure exchange of health records in or out of scope? I thought when you are exchanging Directives you may also include the consent policy, for instance the patient consent, and then the data model will be needed.
• Ioana: the way the EHR functional model describes this functionality has to do more with data obfuscation and encryption than exchanging privacy policies or consent directives. It assumes there are consistent policies at both ends.
• Milan: It doesn’t assume that the policy is sent with the data?
• Ioana: It may or may not. It’s silent on whether along with the obfuscated data you have send the privacy policy. It seems to imply that the privacy policy is agreed upon between the parties of exchange by some bilateral or multilateral agreement. What you’re suggesting is a variation on this use case, in addition to the information you have to exchange the consent. Is that what you’re saying.
• Milan: Yes, for example from a DMO you send the data in a secure way to a hospital and you have to include the constraint policy, for example, patient consent.
• Ioana: If the privacy policy calls for consent to be explicitly issued for instance, when you exchange mental health information, the consent will be part of the payload.
• Pat: Other approach that’s been taking, pass a token that’s non-repudiable. Yes, consent has been given, we guarantee this.
• Tom: I’ll refer to what SSA is doing in terms of HITSP constructs.
  • In the initial request to discover the patient, we are asserting a policy identifier, we’re sending along an OID of a particular access policy. We’re using the SAML assertion header – particularly authorization decision statement which is meant to be used for information that is in addition to the generic request. That token/policy is meant to be a hint to the responder to look at it, at the policies being asserted to, and if they don’t recognize one, they have the opportunity to retrieve that policy document. This is what HITSP TP30 allows for.
  • Step 1 – We assert our permissions, it’s up to the responding facility to look at that data and decide if they are going to allow the access or attempt to retrieve the policy document that is asserted to so they can further consider whether they want to allow access to the data. I’m not asserting that we are exchanging an executable policy. We’re asserting a signed document that contains legal statements as well as describes the type of data being allowed access to and the duration that the access is allowed. That’s what they retrieve, the facility then reviews that document and determines whether they want to accept the guidelines and coverage and the access allowed, and if so, they would convert that into an executable policy in their enterprise.
  • Part of what I’m hoping will come out of these efforts (Privacy and Security DAMS, etc.) gets converted into a structured CDA document where these consent directives and policies can get expressed in a computable way.
• Glen: We need to be cautious of the stuff coming down the pike. We need to say (those of us working on the NHIN), we’re not able to say anything policy wise, all we can say is the nature of what we’re doing because there’s been no rule making. And in the absence of rule-making all we can make are vague statements.
• Tom: So far all we’ve done is to facilitate the exchange of what can be called a security policy or a consent document and we’ve have not stated what is in it.
• Glen: And that’s the state of the art and it’s very close to HITSP TP30, which is essentially a text image of a document wrapped in CDA metadata using IHE’s XDS SD
• Pat: To go back to the statement on internationalization. There’s more work that’s being done outside of the US, so a simple document is probably not going to cut it for the rest of the world.
• Glen: The initial push is in the non-US sphere; particularly European nations who want to have structured data of some sort.
• Pat: It may not be in the form of CDA.
• Glen: The problem is that it’s an XML object and I don’t know who’s defining the structure. That’s a legitimate question for HL7. Should HL7 be defining it?
• Tom: Are you referring to the XACML work?
• Glen: No – if you look at the XSPA use case, which is just exiting ballot, that really goes in the WS-header. It would be part of the message header. We’re talking about document content that would be communicated in message payload. The message payload, the WS-header, has the duration of the message and then it’s up to the consumer of the message to do something with it that is consistent with the permissions in the WS-header. When you embed it in the document, you’re dealing with persistence. So when you retrieve that document later on, the privacy information that goes along with that document is embedded with it.
• Tom: This is part of the merit of not only leveraging TP30, but also a CDA based solution.
• Ioana: Do we need more time to review and augment these use cases? If so, is the rest of this week sufficient?

2. Sensitivity and Confidentiality

• Glen: There’s a combination of Role and Sensitivity in the sense of the nature of the data that can be accessed. There are really three concepts:
  1. Data that is labeled with that nature.
  2. The next is a person who has the ability to see that despite role
  3. And then the role itself.
• Ioana: That’s basically what Role "sensitivityCode" should say.
• Glen: The other thing to pursue is the concept of a data label. This is a generic security concept but we don’t have a place to put it in data content in HL7. It’s a label that is like a metadata element that would apply to messages and to documents
• Ioana: If you look at the way confidentialityCode has been used in CDA, it’s basically that kind of generic label, but it’s part of the information itself which is what you are concerned with.
• Glen: Can I develop a label that can be attached arbitrarily to data as an object that would indicate the properties of that relative to security levels, relative to policies, relative to confidentiality, to any number of things? The reason is because I would like to inspect that label before I disclose and open up the data, so I do not have to disclose the data electronically before my authority to access it is determined.
• Ioana: That would work in here as well. If we were to add confidentiality and sensitivity to the ControlAct class, that’s really supposed to be part of the wrapper to an HL7 V3 payload.
• Glen: Also attach a similar object as metadata to a CDA so I don’t have to look at a CDA?
• Ioana: But that would have to be part of the wrapper to work the way you want it.
• Glen: Opening a can of worms by mentioning this. Ability to tag individual data elements, means each would have to be wrapped and I want to avoid tagging individual data elements because of that
• Steve: With a personal health record where a client is determining sensitivity, they may be tagging sensitivity based on a particular illness, in which that particular illness may occur in a wide variety of objects…
• Pat: They could retroactively tag it as well. I’m concerned about the segmentation is mentioned in ARRA, and the patient determines this segmentation. I don’t mean to preclude this, but I don’t know if we’re technologically there yet.
• Ioana: Glen, I would like to propose an additional proposal for next spring, to make sure that the wrappers themselves contain the necessary sensitivity and confidentiality indicators
• Glen: Agreed. In particular a level that is at the application level to have a wrapper in addition to the WS-headers, which is the message wrapper.
• Tom: I don’t understand. If I’m sending a query/response, where I’ve got multiple sets of confidentialities and sensitivities. At a message level, I don’t know what you would put on the way in of ControlAct and I don’t know what you would put on the way out if you had multiple acts being returned
• Pat: That would be the combinatorial grammar associated with this and there is an opportunity to create a standard and there is the opportunity to develop that standard. I think what we need to deal with here is first what about the envelope and de-enveloping the data and then we can get into the semantics of the contents of the envelope? Layers of the envelopes and the content.
• Ioana: The two layers of envelopes in HL7 V3 are the Control Act and the Message Wrappers. There are two sets of wrappers.
  • The control act wrapper has to do with behavior;
  • The message wrapper has to do with acknowledgements.
  • It makes sense to include information about confidentiality, either as an input parameter or as a return value, in the Control Act wrapper. If you think about query/response, the query information could include IIHI and with it, it may have associated a specific set of external confidentiality and sensitivity codes as well as the individual elements of specific message content could have additional flags if necessary. In a CDA implementation guide, both the document and sections within the document could have their own confidentiality and sensitivity codes (e.g., a Continuity of Care Document (CCD) where different sections might be marked separately)
  • The only thing wrapped is the message; there are no wrappers for documents. You could have a message that contains a document that is wrapped.
  • This proposal addresses two items:
    • First, the ability to specific sensitivity in the document, section or entry level – this would not deal with the wrapper. That would have to be a separate proposal.
    • The second, this would improve the definition of confidentiality by delineating between confidentiality and sensitivity and provides the ability to indicate a sensitivity of the Role in relation to a specific information artifact that itself has as sensitivity indicator.
• Richard: is this all on the Wiki?
• Ioana: it is on the Harmonization website as well as was sent to the ListServ (Security and CBCC) on Sunday, 10/18
• Pat: Do we understand the impact to the rest of the implementers – concerns have been voiced in Canada – “this will break all kinds of things”. While I support the separation, if there’s a real use case, lets do the do the analysis.
• Ioana: That’s the purpose of harmonization (the analysis). How is confidentialityCode used in Canada? Is it used to specify sensitivity or confidentiality?
• Jean: It’s used for both. We have sensitivity – indicates a disease, no one tell the patient until I discuss it with them – something that is considered “taboo”. So it describes levels of Provider sensitivity. This is normal, you can release, you can release within my circle of care, and this cannot be released to anyone. I think it’s sensitivity but it is different from the way we’ve discussed sensitivity on this call today.
• Pat: This is true, sensitivity is used to describe how the information can or cannot be revealed as Jean indicated; the other way it is used is to mask information based on patient’s consent. The code set used in Canada is HL7’s code set.
• Ioana: I don’t think this will have an impact. Your implementations will conform to a specific version of the RIM and the normative structured terminology. So your implementations will be consistent. The only effect will be going forward, you will have the ability to be more precise. Your existing implementations will still conform to RIM version 2.17, whatever. In future implementations, if they need to separate confidentiality from sensitivity, they can use the new version; if there is no distinction, they can continue to use it the way they’ve used in the past.
• Jean: Since most models are using confidentialityCode, I submit this will break them. I agree that confidentialityCode is not describing confidentiality. But instead of this proposal, we might want to deprecate the code if it is being used incorrectly – if it is being used for sensitivity, not confidentiality.
• Ioana: This is beyond the purpose of this proposal. The purpose was to say, the definition for confidentiality is correct, but the usage notes are incorrect in relation to the definition. If some of the old implementations are using confidentiality to describe sensitivity and your new implementations are using sensitivity correctly, then you can map back the concepts appropriately.
• Jean: We may not know whether we’ve used confidentiality to describe confidentiality and sensitivity. The reason this breaks things is because the way confidentiality has been used is for both concepts; we can’t distinguish
• Question: So why isn’t this a vocabulary discussion? Because it’s a coded element. If you’re definition overloads the meaning, you have a specific vocabulary to yourself as opposed to those that separate that separate two different elements with two different vocabularies associated with it.
• Jean: This is what is being done in Canada – we have made it repeat twice and we’re using two different value sets, one for confidentiality and one for sensitivity and were sending it in the same coded elements.
• Ioana: This used to be done in HL7 version 2; you had a repeating attribute and every occurrence had a different meaning.
• Jean: I agree with Ioana that we need to separate these two concepts in the RIM, but it is also a vocabulary issue
• Ioana: Yes, it is also a vocabulary issue. We have confidentiality by access type, which is confidentiality, and then we have confidentiality modifiers, which are really sensitivity modifiers, and confidentiality by info type, which is also a sensitivity. Just as Jean indicates, the concept domains within the confidentiality abstract concept domain are also representative of the duality of this attribute
• Jean: It’s almost like we meant it to be post-coordinated, but didn’t
• Pat: So I have two issues. The other issue is that at the end of this document there’s a whole section on re-naming an attribute from immutable to read-only. The comment from Lloyd, this was already attempted and refuted as non-persuasive and what does it have to do with privacy and security. I think you should take it out and put it in a separate proposal. Does this have anything to do with Privacy and Security?
• Ioana: No
• Jean: There seems to be two harmonization proposals in one.
• Ioana: No, this is a coversheet. It contains several proposals. The way Harmonization works, is you submit a coversheet that includes multiple proposals and then you submit detailed proposals for each of the items. In order to suggest the changes for sensitivity and confidentiality we’re also asking for the associated vocabulary to reflect that change because these are part of the HL7 abstract Concept Domains that are declared and they basically reflect the issue the proposal is trying to address. This is an additional proposal dealing with the attribute immutable, which should be read-only because it’s an HL7 extension and does not require an extension. Every single change to the RIM has to go through Harmonization.
• Pat: The only problem I have is the fact this recommendation is coming from the Security Work Group and this has nothing to do with Privacy and Security. We’re the wrong domain of expertise to be talking about it. It should go to the right Work Group. Work groups are considered to be the domain experts and I’d like to make sure there are others who are weighing in.
• Ioana: Which Work Group(s)? This is a reasonable comment.
• Pat: Let’s put it out to the group.
• Glen: We should have this discussion with an agenda behind it. Let’s put it on the agenda for next week and broadcast to the larger audience.
• Ioana: I will send the proposal to M&M for review as well in the meantime.
• Meeting transitioned to CBCC Conference Call at 2:20 PM EDT
  • No major motions or decisions were made