|
|
| Line 28: |
Line 28: |
| | | | |
| | ==Minutes== | | ==Minutes== |
| − | Ioana proposed an additional agenda item
| |
| − | *Vote on the scope of the Security Domain Analysis Use Cases so we can move forward elaborating them.
| |
| − |
| |
| − | '''Summary of the meeting:'''
| |
| − | *Motion for the Security Work Group to endorse the Harmonization Proposal for Confidentiality and Sensitivity was passed. None opposed, none abstained.
| |
| − | *Motion for the Security Work Group to agree on the scope of the Security DAM Use Cases passed. None Opposed, None Abstained.
| |
| − |
| |
| − | '''Transcript of the Discussion follows:'''
| |
| − |
| |
| − | Ioana presented the RIM Harmonization proposal – changes to confidentialityCode and addition of a new sensitivityCode
| |
| − |
| |
| − | *Glen suggested it would be useful to include sensitivity as part of the message envelope. This harmonization proposal supports that suggestion because the message wrappers and control (?) wrappers are based on the generic Act. You could glean the sensitivity and confidentiality of the payload without actually opening up the payload. This is the crux of the issue – don’t give away a secret to keep it.
| |
| − | *This proposal has several elements, which clarify the current Act.confidentialityCode that has mixed semantics.
| |
| − | *#Add Role.sensitivityCode to indicate the level of sensitivity of the information that someone may access. Right now there is a Role.confidentialityCode that refers to the confidentiality of the role not in the information that role is allowed to access.
| |
| − | *#*So we would have a Role.sensitivityCode and Act.sensitivityCode.
| |
| − | *#Suggested changes to vocabulary/terminology
| |
| − | *#*Right now there is the confidentiality abstract domain, with three sub domains
| |
| − | *#**ConfidentialityByAccess type
| |
| − | *#**Confidentiality modifiers
| |
| − | *#**ConfidentialityByInfoType.
| |
| − | *#Addition of a new Sensitivity abstract domain that would hold SensitivityModifier and SensitivityByInfoType
| |
| − | *The Harmonization process will determine the optimal way to address these concerns. It would straighten out some of the issues that Steve has identified with this abstract domain.
| |
| − | *Confidentiality is an abstract concept and ConfidentialityByAccess type is a specialization of Confidentiality
| |
| − | **Richard: does this proposal impact anyone/anything?
| |
| − | *Pat: the comment received from Lloyd – the issue is that the existing definition of confidentialityCode. His preferred solution is to modify definition of confidentialityCode. You can repeat confidentialityCode and it is currently being done, conflating confidentiality and sensitivity. There are many models where this change will have an impact.
| |
| − | *Ioana: this doesn’t effect existing implementations. This proposal will only impact future implementation guides. Right now CDA R2 implementations are tied to a particular version of the RIM. There have been many changes to the RIM since CDA R2 was released. And CDA was not affected by any of these changes. This is not a retroactive effect.
| |
| − | *Don: Does Lloyd usually participate in Harmonization.
| |
| − | *Ioana: Yes, and he will be there. He will have the chance to respond to this proposal at the Harmonization meeting in mid November. This proposal doesn’t change the RIM until Harmonization approves it.
| |
| − | *Steve: I have one issue that I would like to bring up. Not sure whether the harmonization group will address this but it has to at some point . The fact that you have the role.Sensitivity type and Act.sensitivity type and you want to use the same value set for both attributes, that will cause some problems. The concepts in the value set have role implications, such as taboo and clinician. Those concepts come with a certain role implication and so they’re not easily switched between the role attribute and the act attribute.
| |
| − | *Ioana: so you’re saying the coded concepts associated with actSensitivity are different from roleSensitivity?
| |
| − | *Steve: I’m saying if we want to use those coded concepts we probably should make them role independent.
| |
| − | *Ioana: They are. You are correct. This, in my opinion, is the problem with the current roleConfidentiality. The way it reads in the RIM, this attribute is an attribute of this Role that deems it to be Confidential. I don’t know of anything that would imply that a role is Confidential. But I know that associated with that role is associated a specific level of sensitivity that is assigned to that Role. I, as an analyst, can look at classified information. That’s what my Role.sensitivity is. I may not be able to look at classified information. That’s a different Role.sensitivity. So I concur with you, it’s a qualifier of the role, but it speaks about the information that the role is intending to access. That’s what I am trying to capture here.
| |
| − | *Steve: I may be talking about something different. For example, the coded concept of taboo carries with it an implication of Role, i.e., this is information that should be kept from the patient. The provider has access to that information, but the patient does not have access. So within that concept, there is an implication of role. So if you apply taboo to a role of clinician, it doesn’t really make any sense
| |
| − | *Ioana: would it mean that they could look at taboo information?
| |
| − | *Steve: The definition of taboo in the HL7 sense, is information that is kept from the patient but is accessible to the provider.
| |
| − | *Ioana: there has to be some organizational policy, some XACML policy that says if you’re the subject of the record you can’t see this information
| |
| − | *Mike: I don’t see this is any different than anything else. The patient is also an IT user. So in order to grant the patient access to something whether it is taboo or whatever, it would have to have that attribute.
| |
| − | *Ioana: It would be an authorization you run against enforcing the specific set of authorization policies that would include whether taboo information can be disclosed to someone who authenticates them self as a patient and is the subject of the record.
| |
| − | *Steve: I’m not saying this is not a condition, this is a requirement that a system has to block access to certain information to the patient but not to the provider. But to have that concept and now be able to use that as a value for this roleSensitivity attribute, then you can tack that concept onto a role of clinician. What does it mean at that point? It’s meaningless.
| |
| − | *Pat: There might be another way of looking at this, not necessarily the read part. But in terms of which roles have the authority to flag records as taboo. Is it only primary care physicians that should have that authority. In countries where patients are the owners of information, there would only be a finite set of folks who have the right to withhold that information that in theory they have the right to, and in theory only for a short period of time.
| |
| − | *Steve: I see your point and that’s valid. I think we’re going to have some problems in using concepts in these value sets that have this built-in role. What would probably be preferable is to have some role-ambiguous concept that says you can block access to this certain group, and this other group has access.
| |
| − | *Pat: So treat it as a Permission as opposed to a specific role attribute.
| |
| − | *Ioana: And I think that’s a valid point, but it’s out of the scope for what this proposal was originally intended to do.
| |
| − | *Steve: But you’re introducing this Role.sensitivityCode attribute. You’re pushing the value set to a place where it was never intended to go.
| |
| − | *Ioana: There is a Role.confidentialityCode already. This particular confidentiality modifier of taboo was already defined as a modifier for a Role. That’s why I say this is a little out of the scope for this proposal. We haven’t changed things very much, and this is not a drastic change. It is just casting these different coded concepts to different abstract concepts. So right now if you want to say this role has a confidentiality of taboo (confidentiality modifier), you can do that right now.
| |
| − | *Don: How is this impacting your work? Why do you see the need to do this right now?
| |
| − | *Ioana: During domain analysis for security, we need to have a sensitivity indicator that would be separate and distinct from confidentiality and Security, two things became clear.
| |
| − | *#We need to have a sensitivity indicator that would be distinct from a confidentiality indicator that is more focused on access control versus sensitivity that deals with specific qualities of the data.
| |
| − | *#The users in the security policy have to also have specific security level that matches the information. So this comes from the domain analysis.
| |
| − | **In discussions with Lloyd, he does not disagree that they deliberately combined confidentiality (with sensitivity). If you look at the RIM, the definition of confidentiality reads like ISO confidentiality, but the usage notes describes sensitivity. So the definition for confidentiality is correct in the RIM. The RIM has confidentiality, but it does not have sensitivity. The usage notes are confusing, and I hear what Pat is saying is that in Canada they’ve taken the usage notes to be more normative. They are using confidentiality to describe sensitivity.
| |
| − | *Pat: The code set we use for confidentiality is Normal, Restricted and Taboo – so even in that code set there’s a conflation there.
| |
| − | *Ioana: You’ve combined ConfidentialityByAccessCode with confidentiality modifier. So we don’t have to endorse this proposal if people would like to continue to use the old ways of combing these concepts. This is the gist of this proposal. We don’t have to endorse this if we don’t think this prevents us from representing security concepts in the future. But right now we would not be able to create a policy that distinguishes between confidentiality and sensitivity.
| |
| − | *Don: So what are the groups that are the other half of this . Who are the consumers of those codes. Who provisions them? What are the groups that are responsible for the Documents and the messages and what do they have to say?
| |
| − | *Ioana: You’re correct. It would be similarly difficult to distinguish the intent of the documents. When they are using confidentiality in Canada, they use ConfidentialityByAccessCode and confidentiality modifiers. That’s their analogy. Their artifacts would not distinguish between confidentiality and sensitivity.
| |
| − | *Richard: so will Canada be affected by this change if they are truly tied to a version of the RIM where confidentiality is represented in the way it is being used?
| |
| − | *Pat: Each year, there is a maintenance cycle for the Canadian standards, and the intent is to stay current with the RIM whenever we can. CDA is not big player at this time. So from the message perspective we try and stay as consistent with the current RIM as possible. So there will be some impact in Canada for this. But Ioana is right, if we want to stay with a certain version of the RIM, then this would not have an impact. But I can’t see that ever happening.
| |
| − | *Richard: so will this make Lloyd upset?
| |
| − | *Pat: I think Lloyd will be upset, but I don’t think we need to deal with that here. We can deal with this in harmonization.
| |
| − | *Steve: One detail, the value set is called ConfidentialityByAccessKind, not Type.
| |
| − | *Richard: The downside is perhaps in Canada, but in terms of the security DAM it makes an important distinction, so it makes sense to pursue this?
| |
| − | *Pat: To Don’s point, who are the other consumers for this? What groups are provisioning, what are the implications from their perspective. Should we try and take that into consideration before we do this, or is that something that happens at harmonization and we let them fend for themselves.
| |
| − | *Ioana: The only things provisioning anything in the US are those who are producing HL7 version 2 messages. They may or may not care about confidentiality codes at all. The only change this will introduce is for those reading the RIM for the first time, they will notice that the conf code description is consistent with its usage. Right now it’s not. I think we’ve discussed this effectively. If this work group does not wish to endorse the proposal we don’t have to take this any further. I’d like to make a motion that to vote on whether security wishes to endorse this proposal or not.
| |
| − | *Mike: seconds the motion. For me it’s very simple. We’re trying to get this aligned with existing security standards, which it’s not
| |
| − | *Glen: chair. Call for vote –None opposed No abstentions. Motion passed.
| |
| − |
| |
| − | '''Security Use Cases'''
| |
| − |
| |
| − | Based on last week's discussion:
| |
| − | *Decided 1.9 Accounting of Disclosures use case would be referred to PASS. Don is aware of this, and PASS will be addressing the use case. The Security Wiki will be updated to note that PASS is addressing this use case.
| |
| − | *Even though 1.6 Enforce Secure Exchange of Health Records (functionality in the EHR- Functional model) is not in scope for he Security DAM, the exchange of consent directives is. On closer examination, we found this is addressed in the Composite Privacy DAM, so 1.6 is deemed out-of-scope in Security for now. Since it is addressed by the Composite Privacy DAM, we haven't lost track of this use case. We have explicitly discussed the exchange, query and look up of consent directives with detailed scenarios.
| |
| − | *1.5 Enforce authenticity of legal healthcare documents, 1.6 Enforce Secure Exchange of Health Records and 1.9 Accounting of Disclosures are out of scope for this version of the Security DAM.
| |
| − | *The other use cases will be further elaborated, especially 1.4 Enforce privacy policy and consent directives using access control.
| |
| − |
| |
| − | Today's Discussion:
| |
| − | *Milan: One question. It is not completely clear. Are you for an integrated Privacy and Security DAM or just Security DAM.
| |
| − | *Ioana: I’ll let Mike and Richard talk about that . I think they are considering an integrated DAM for perhaps a May ballot. So I think we are probably going to do that after January. Maybe this is a good time to discuss the strategy.
| |
| − | *Mike: The strategy is to go to ballot in Jan with a Security DAM; the last CBCC ballot – DSTU for Privacy DAM. These have been worked in parallel and Ioana has notions of how they can be put together but we haven’t really discussed that a lot. The idea was that we would go ahead with the Security DAM as it is written and then we would integrate it with the Privacy DAM at some later point. This was based on a couple of things discovered doing this work, #1 it was clear that CBCC’s interest in the privacy dam was patient focused, and security was the focus, so they have two endpoints and outputs. But there is a lot of vocabulary on the patient side that is not of interest to Security. We’re interested in integrating privacy vocabulary with security DAM as far as enforcement of authorizations and patient consent is concerned. The notion is that we can combine them into one giant DAM that was harmonized or we could create some binding classes to provide that interoperability, but we haven’t had that discussion as to how that might happen. We can find usefulness for both, they’ve been on parallel tracks for now. The strategy is let them keep on parallel tracks to get votes and comments on the Security DAM in January, and then do a harmonization effort for May or maybe for September.
| |
| − | *Richard: And this all feeds into PASS?
| |
| − | *Mike: Part of this is feeding into PASS. They are adopting the information models themselves, so it would be more useful to have something balloted rather than something draft, for them to be working with,
| |
| − | *Don: That’s my principal concern now. In terms of the classes, they seem to be almost there. Getting a harmonized policy structure, regardless of a vocabulary would be helpful to have at the earliest possible time.
| |
| − | *Mike: We know what we want to get to but we’re trying to do it in chewable steps. These are achievable outcomes that we can see are getting us there. Similar to what we’re doing with the RBAC permission catalog. The original catalog was very restrictive in its vocabulary and we knew there were gaps, and we had comments on the ballot. So in the next iteration we addressed those things. We had something that provided a minimal interoperability set. So I think our strategy is not to say that whatever we ballot in January is the final version, but it’s the DSTU. It’s important to get the exposure, to get the comments and that puts us in a good position to do the harmonization effort which we will start for May or for September. That’s the goal of the project, between Security and CBCC is to create a harmonized Domain Analysis Model.
| |
| − | *Ioana: Milan, do you have any concerns about 1.6?
| |
| − | *Milan: I have a question with respect to the scope. Scope is Access Control. I think the part about policy exchange is addressed in the Composite Privacy DAM, but the core is the secure exchange of data obfuscation or using cryptography, this is probably something that will be addressed in future versions?
| |
| − | *Ioana: I will defer to Mike. You reminded me that the two major use cases that were deemed in scope were authorization and access control. I want to mark authentication is out of scope as well.
| |
| − | *Glen: The other thing that occurs to me is that we have to be somewhat careful about diving into technologies prior to getting our context specified. Use of encryption, for example, is a way to enforce confidentiality. The question is what is the entire thing that needs to be protected? What are the risks that we are attempting to cover, do we have a model for people to use for that purpose? Diving into technology would be prematurely if not. We should focus on getting the level of detail that we are currently working on down right before we go into discussions about specific technologies.
| |
| − | *Mike: Glen is right in that respect. Ioana made a point that we need to emphasize. We are treating this DAM, the Privacy and Security DAMS as about enforcing Access Control.
| |
| − | *Glen: Access Control is a good level playing field to be on.
| |
| − | *Mike: That’s not to say that you couldn’t view Access Control as a kind of confidentiality because you’re restricting access to information, which is to your technology point. We would expect that you could use Access Control as mechanism to enforce confidentiality. But our primary focus is more to the point of authorization, access control and enforcement of patient privacy. We should take the authentication use case off the table. And we should make sure the access control use cases are sufficiently informative so people understand what we’re trying to do.
| |
| − | *Glen: For those people who are going to read this who are not been involved in Security day-to-day, that kind of focus is critical to understanding; otherwise we’re going to continue to get questions about policy that can’t be answered or things that tell me more about clarity of understanding the document as opposed to technical points. We’ll continue to get questions that are not pointed to the purpose of the document.
| |
| − | *Richard: The question of authentication should be considered an access control issue.
| |
| − | *Glen: To get to the point of authorization, you have to be authenticated, you have to associate credentials with who ever has been allowed into the system. A use case for allowing someone into a system is a separate act; you have to assume that it’s been done.
| |
| − | *Mike: We all understand that authentication is the primary service that must occur before any other service can operate. The issue about authentication would be very academic to put it in. Technically an Authentication alone in some cases might be enough to authorize access, but in that case you wouldn’t be using the Security or Policy DAMs at all.
| |
| − | *Richard: So for the naïve reader, sort of statement that explains why something that looks like it should be in scope is out-of-scope.
| |
| − | *Glen: This shows that we haven’t completely explained things.
| |
| − | *Ioana: can we say that this use case does not re quire health care specific information?
| |
| − | *Mike: Fine with me. If we’re saying there’s a use case that’s the zero-end use case where the user authenticates and gains access, but it’s unlikely that that use case is going to apply to any realistic health care situation where you’re accessing protected health information. Normally the access at that level is to non-protected information.
| |
| − | *Ioana: Back to Milan’s question, things like encryption and mechanisms for assuring secure exchange of information. These are out-of-scope because there is nothing specific to health information in those use cases you would have to apply the same mechanisms
| |
| − | *Glen: To put this in context, in HITSP there are two things we are concerned with – encryption of data in transit which would be transmission security, and we already have those things specified and they are actually very general, they are not health care specific. The other is encryption of data at rest. There is a very specific provisions in the HITECH act for data that is unprotected at rest, such as a USB key, laptop out of its natural environment, CD, etc. that it would be rendered unusable by someone who does not possess an encryption key. Prior to this, for encrypted data at rest, you have to have established an authenticated connection. There are some precedent acts – getting a hold of a decryption key. And the Access Control happens to be in that family
| |
| − | *Mike: It may sound strange, but security folks are used to thinking of these things, Access Control, Authentication and Audit as orthogonal. Services in their own right. We don’t have use cases for Audit, but if you looked at the information model for audit, you would find the same information objects that are in the RBAC model. The audit would be linked to the terminology here, but it doesn’t drive it. We don’t create authorizations for the purposes of satisfying an audit requirement. It’s the other way around. Audit is accessing the permissions and objects that the user is accessing. I think for our purposes and for clarity, these are things that a Security person has some worries about but the focus should be on clarity and to be as pure as possible. The canonical…this is Authorization. We’ve cited particular ISO standards that are about Authorization. They have standards about these other things as well, but they are not germane.
| |
| − | *Richard: Access Control is really about Authorization.
| |
| − | *Ioana: Authorization and Access Control
| |
| − | *Mike: It’s simpler to talk about it in terms of Access Control. Access Conrol makes more sense because it is a broader term. Access Control makes more sense because we’re including privacy considerations and the models we’re using are about Access Control. Authorization is included in that – the rights someone is given that the Access Control system is making decisions on.
| |
| − | *Ioana: This also gives a nod to the RBAC work that has already been done, and we have a specification that delves into considerable detail about Authorizing users based on their structure and functional roles and identifies information objects and operations that apply to those objects. It makes sense to call it out that this is just a specialization of Access Control.
| |
| − | *Mike: We need to a couple of sub-use cases of the existing ones of patient privacy to demonstrate some significant aspects of that.
| |
| − | *Ioana: these would make very good elaborations with sequence diagrams and show them off as supporting the overall enforcement of privacy and consent. You provided those use cases to me and we discussed them informally last wee. Those will be included as well. They apply to enforcement.
| |
| − | *Ioana: I'd like to make a motion to accept the Security Use Cases including the ones we’ve identified as out of scope with a caveat that specific aspects of exchanging consent directives have already been address in the Composite Privacy DAM. Do we have a second?
| |
| − | **Motion seconded by Richard
| |
| − | *Pat: Is there any chance of amending that by saying “for the current ballot”.
| |
| − | *Glen: Is that a friendly amendment?
| |
| − | **Yes
| |
| − | *Vote: None opposed, no abstentions, motion accepted
| |
| − |
| |
| − | Meeting adjourned at 2:03 PM PDT
| |
