December 16, 2014 Security WG Conference Call
Attendees
| x | Member Name | x | Member Name | x | Member Name | |||
|---|---|---|---|---|---|---|---|---|
| . | Mike DavisSecurity Co-chair | . | Duane DeCouteau | . | Chris Clark | |||
| x | John MoehrkeSecurity Co-chair | . | Johnathan Coleman | . | Aaron Seib | |||
| x | Alexander Mense Security Co-chair | . | Ken Salyards | . | Don Jorgenson | |||
| . | Trish WilliamsSecurity Co-chair | . | Gary Dickinson | . | Tim McKay | |||
| x | Kathleen Connor | . | Ioana Singureanu | . | Mohammed Jafari | |||
| x | Suzanne Gonzales-Webb | . | Paul Knapp | . | [ | |||
| x | Diana Proud-Madruga | . | Reed Gelzer | . | [ | |||
| x | Rick Grow | . | Steve Hufnagel | . | [ |
Agenda DRAFT
- (05 min) Roll Call, December 02 Meeting Minutes
- (10 min) FHIM S&P Modeling Project Wiki and Call Logistics - Kathleen
- (10 min) Vocabulary Alignment Project - Diana/Reed
- (15 min) January WGM Agenda
- Note: items with ? have been rolled over from previous WGM Agenda
- Security Holiday Meeting Schedule - Cancel 12/23, 12/30, 1/6 meetings?
- (05 min) Other business, action items, and adjournment
Meeting Minutes
Approval of meeting minutes Meeting minutes for December 02 - Meeting minutes were unanimously approved.
FHIM S&P Modeling Project
- Kathleen described the following link, which contains the FHIM UML Documentation: http://fhims.org/content/420A62FD03B6_root.html
- The FHIM WG is currently working to align the FHIM more closely with Bernd Blobel’s privilege management and access control (PMAC) concept. The group is also beginning to fill out more documentation from the old DAM and update it with a new understanding and to bring in conditions that are missing.
Vocabulary Alignment Project
- Diana brought forward questions to the Security WG that the EHR Interoperability WG posed in its meeting. Diana asked if it is okay to treat "Append" as a type of update, or if it has to be considered separately. John answered that it is a type of update, but needs to be explicitly indicated as such. Diana also asked if it is beyond the scope of HL7 to consider security requirements (such as "Encrypt" and "Decrypt") as core requirements for EHR systems. Rather than "Encrypt" and "Decrypt" being part of a Life Cycle event, they are more of an attribute of several of these events. Diana will take the discussion and answers back to the EHR Interoperability WG.
- Scroll down to the end of these minutes for the full discussion on the questions posed above.
FHIR Change Proposal
- John said that we will be creating another page for the FHIR specification that's related to the Security page that will be all about signatures. This page will have on it a set of signatures or scenarios comprising a library. It will not be a singular signature. The page will effectively say, "If this meets your use case, this is the type of signature that you will use, and this is when it will break." Ultimately, the page will have a library of signature types that will work for FHIR issues, whether it's FHIR resources, FHIR messaging, FHIR transactions, or multiple FHIR documents.
- Kathleen posted the following link that will contain the features John described above: http://wiki.hl7.org/index.php?title=FHIR_Digital_Signature_Working_Page
Security Holiday Meeting Schedule
The WG PASSED A MOTION to CANCEL the DECEMBER 23 and DECEMBER 30 Security meetings, but to hold the January 6 meeting as regularly scheduled.
Meeting adjourned at 1304 PST
Discussion on the Vocabulary Alignment project:
Diana
So, in the Vocabulary Alignment group, we’re looking at primarily the RBAC permissions catalog to look at the operations, and one of the things that Gary and Reed noted was that in the RBAC permissions catalog, “append” was pulled out as a separate operation. They’ve been looking at it from the CRUDEA with the “append” outside of that. Now, in one of the spreadsheets that I sent out from the RBAC Roadmap, it shows “append” as being a type of update; also, when you look at all of the different definitions, while “append” has been pulled out, it’s never actually in. So, one of the questions they had is: “Is it okay to treat ‘append’ as a type of update, or does it have to be considered separately?’”
John
No, it’s a type of update the way we originally noted, but it needs to be explicitly indicated (as such). But now that we have the broader set of verbs that we marry with some of the privacy use cases, I think we could probably go back to the fundamental verbs of “create,” “delete,” “execute.”
Kathleen
And that’s worded really nicely within the FHIM model. It actually differentiates operations that are security from the privacy operations.
John
“Append” isn’t necessarily a privacy specific broad verb, but there are other broad verbs that are not specifically privacy, too.
Diana
“Append” is considered a type of update?
Kathleen
Yeah.
John
Again, it is a type of update that has a very specific nature, meaning it is not allowed to change and is supposed to be permanent; it’s only allowed to have a very specific type of update. Kathleen, the thing you’re bringing up is exactly how is “append” expressed in the core verbs of “create,” “read,” “delete,” and “execute?”
Diana
I look at an “append service” differently now; that’s not an operation. The operation that happens is “append” because it’s a type of update. It’s a difference in viewpoint between the action that is taken when you append something versus the execution of the service that does that action. It’s just a matter of being very clear when you’re talking about the noun, which is the service versus the actual action that is taken on the record.
John
Again, it’s contextual.
Diana
It’s the difference between a noun and a verb. I don’t see that the verb “append” is being mapped to both update and execute. I’m saying that the verb “append” is a type of update. Now, if you’re talking about an “append service,” that’s completely different.
John
The point that I was trying to make is that “append” is a broader verb that is recognized as something that can be broken down into the core verbs, but my point specifically is that there usually is more than one way to map them to those core verbs.
Diana
What do you mean by broader because I see “create,” “read,” “update, “delete,” and “execute” as being the broadest of the verbs and “append” has a much narrower definition that falls under “update?”
John
Okay. Then I would agree.
Diana
So, I can go back (to the EHR Interoperability WG) and say, “It’s fine to look at just the crude without looking at it in CRUDEA?
John
Yes. Make sure that “append” is put into that other bucket.
Diana
Oh, it will be. The other thing that I brought up, and apparently other people have brought up the same question, is that I looked at these two things here that they’ve added as a Record Life Cycle event, “encrypt” and “decrypt,” and I questioned that. One of the questions that ensued from the discussion was, “Is it beyond the scope of HL7 to consider security requirements as core requirements for an EHR system?”
John
No. Well, it depends on the definition of “core.” I’m sorry I’m not understanding the question.
Diana
Well, the question is do you think that “encrypt” and “decrypt” link to these functions specifically of the EHR system, or are they going to be functions of some other system or service that works in conjunction with the EHR system, and therefore would not be considered core requirements for the EHR system?
John
Yeah, again I go back to my first response, which was it depends on what your definition of “core” is. I don’t know how to resolve this.
Diana
I was looking at them and those seem to be very specific security functions, but are they security functions that happen within the EHR system, or are they security functions that would happen outside the EHR system?
John
HL7 does not design encryption algorithms. We have other standards for that. So, are they a function of EHR? Probably. I’ll throw two examples out there. If I am using hard drive encryption that is generally considered not a core function of EHR, and I’ve argued that quite strongly for a number of standards, we have the ability to encrypt a specific package. In the U.S., DirectTrust.org is considered a function of EHR. If you were to say it is the ability to encrypt to these healthcare specific content packages like Direct, then it’s possible. But, just simply encryption is an environmental expectation of a function.
Diana
I like what you just said there. It’s an environmental precondition or expectation. I think what they’re trying to avoid is anything that seems like they’re trying to dictate how the encryption or decryption would be implemented. One of my arguments was that encryption or decryption is a subset of transmit, or of archive. It’s something that falls under several of these Life Cycle events, where the expectation is that these records will be protected, in some way shape or form, through some form of encryption.
John
For your example of transport, the act of encryption is considered an attribute of secure transport. Authentication is considered an attribute of secure transport.
Diana
So, rather than encrypting and decrypting a Life Cycle event, it is more an attribute of several of these events?
John
In the context of their Life Cycle diagram, the point of encryption is closer to the point of the Direct project. So, there is a separate mention of the transport agnostic encrypted form of something. That encrypted form, with the movement of the object of that form into that encrypted from, is considered to be a state transition. I’m trying to figure out what the right way to recognize that is, but, in the same way that when you sign something, you end up with a transform of what you signed, that is coming into being or modifying what you had, and that’s why they show it as a Life Cycle event.
Diana
Okay. Well, I will communicate back what this discussion was and, if there are additional questions, I’ll bring them back to this group. But, I think that makes sense to me; the question is whether or not it will make sense to them and if they will have more questions.
