May 5th, 2009 Security Conference Call
Contents
Security Working Group Meeting
==Attendees== (expected)
- Steven Connolly
- Mike Davis Security Co-chair
- Suzanne Gonzales-Webb CBCC Co-chair
- Milan Petkovik
- David Sperzel
- Richard Thoreson CBCC Co-chair
- Tony Weida
- Craig Winter
May 5 2009
Security Working Group Meeting
Agenda
- ’’ (05 min) Roll Call
- ’’ (05 min) Approve Minutes & Accept Agenda
- ’’ (15 min) RBAC Object Vocabulary (as of 5/5/2009)
ANSI-INSI 359 – any system resource…(workflow?—is that a system resource? per Mike yes. This is consistent w/earlier model of access control;”… …it contains or receives information.” it produces artifacts. (Steve)
The object definition is flexible, it receives data from users. The way the analysis was completed, we started with work flows, we then broke it down to tasks then steps to component pieces. The problem with work flow is that it could have multiple pieces. We start with scenario to work flow to task, a task can only be done by one user. It’s important that we have permissions. RBAC provides user authorization to use functions as well as to use objects.
- some of the issues may be resolved by splitting out the objects into artifacts.
Our intent is to control the operation of the system. (Execute is a verb, as is print and items like that.)
To participate in a workflow...that’s a verb. Within the workflow you have detailed functional 'things to do', it does not mean you can do all the details functional access involved.
An example of objects within a workflow might be: A bank service needs to send a check to a customer. Policy states that the bank personnel who authorizes and writes the check cannot be the same person who signs the check. There are two scenarios in the workflow, one scenario is authorizing/writing the check the other scenario is the signing of the check.
We will ask INCITS about their interpretation of an object is to resolve this issue. (Mike to do) If necessary, we can update/change the standard to clarify it.
Some of the objects currently listed are not data containers but are processes. We have committed ourselves to maintain the mapping for the current RBAC object list once we’ve involved ourselves with a standardized There is overlap with SNOMED CT and with LOINC and we can take advantage of these overlaps.
Some of the other requirements suggested for the project include: (Steve)
- comply with ANSI-INCITS
- improve the interoperability – that would require some kind of harmonization on permissions, operations, and objects. In the RBAC standard we made our ‘’verb’’ tables—the object tables—normative, but did not make the permissions normative.
If you create permissions using standard objects and operations….then by default it’s normative.
Rather than specify you can create your own operation-object tables. The notion behind ANSI-359 is action-object pairs. They’re saying the roles are composed of action-object pairs, and before ANSI-INSIT roles were just names (structural names) with no real structure was the notion of action-object pairs that you can build on…some of which overlap within the roles (MD, Nurse)… if you identify an MD at VA, vs. an MD at Kaiser…the definition may be slightly different. You have to have something finer grained, you can enumerate them, their MD w/these numerations can be identified with another MD with other numerations.
Mapping to an external code system…this is how we can extend the existing standard. I do not want security to be extending the vocabulary I want them to be using the standard. (Mike)
We are trying to reduce the ambiguity by mapping to the external code system.(Steve)
I would prefer everything to be mapped to SNOMED CT and find out where there are gaps. We would declare this (SNOMED CT or another standardized vocabulary) to be the vocabulary of choice, and then identify the gaps that LOINC (or another standardized vocabulary) might fill or something like that. I need terminologists to tell me which is the best vocabulary route to use. (Mike)
SNOMED CT is good for clarify clinical procedure, but not as good as defining what ANSI-INCITS calls an object (David)
I’m not an expert, the current vocabulary is the minimum interoperability set—so far it’s proven to be adequate. If we extend it, the EHR themselves how they operate internally…broader objects to … we need an ability to communicate objects (i.e. NHIN) the problem is we need to follow what the rest of the world is doing. None of these vocabularies will solve the world. (Mike)
The document ontology that HL7 and LOINC have worked out may be better; it’s richer than the hierarchy in SNOMED CT. That’s something for further discussion, we haven’t formed our conclusion. In the area of clinical documents LOINC and HL7 seem to be more closely aligned than SNOMED CT and HL7. (David)
That’s what the terminologist should tell me… if you want to use LOINC instead, make an argument for it instead, that’s fine… (Mike)
The original attempt done by Suzanne, and the subsequent attempts; what we found is that there were not a lot of things that could be directly mapped--there’s report, record entry, not order entry. There are a lot a good matches in terms of information containers. (David) Are you telling me that LOINC is a closer fit? (Mike) Not yet. (Mike)
If we relax the constraint… associating between a record and its procedure then we can map to SNOMED CT. (Steve) The central issue from the terminology standpoint is the notion between data containers and the container of that content. Order is an information container. A lab order is content in the container. SNOMED CT is fine for this kind of thing. Originally there was a feeling that these terms didn’t need to be separated out. Object as a system resource—is some kind of file maybe? But file as an information container is not adequate. In terms of restricting access there an issue of how the object vocabulary needs to reconcile these two differing ideas. The thing itself, or the thing the information contains. (David)
I’m interested in the container objects, not the detailed things the container contains. We were going to describe objects at a higher level, If we were going to define things at their elements we would never get done in a standards way what those objects were. We’re going to describe an order/outpatient prescription and different organizations can attach different definitions. There is no way to make an international standard and specify the each object at that granular a level (Mike)
(Steve’s spreadsheet) We’re building into the information model concept the idea that will require the knowledge of what the objects detail are. For your needs Mike, an order summary or report is not adequate but you don’t want to get down to the weeds (Steve) These could be self defining. That is correct about getting down into the weeds, I want to be able to reference a vocabulary to reference those in some way--to see if we could come up with a mechanism in that way. To take report and say we’ve got a H&P (History and Physical), Medication reports or whatever and those all should be objects (from my perspective) do we have a standard way of naming these things? Name the object and its attributes. A medical history report is distinct from a medical status report; I want to be able to distinguish between the two.
We have to hit the right level of granularly for security purposes (Steve) Yes, but we don’t want to go too far, leave it general enough to be comfortable with it. We should be able to come up with a schema of objects and attributes that’s suitable for that information set (Mike) We’ve gotten some mapping success to LOINC. In actions (processes), there are very few matches, (Steve)
The list of actions (processes) that we have is still small, let’s just define them and make them part of our HL7 standard and then for the objects we can build a process that allows us to get to those (Mike) These actions (processes) are on the object list, these are ADT functions that are on the object list...functions, etc., these are not in the objection/action pair these would be considered the object in that pair
We recognized that some do not match our stated definition. We can take those out or update them at a high level of granularity (Mike) People will understand what a prescription is, we can create a process, create a prescription this make sense in a work flow. We do not want to give an individual permission for every piece of data. (Suzanne) What about an Aids prescription? (R) That’s s good question. I don’t’ know the answer to that… the answer is difficult to come up with. It is not indicative per drug. The security system cannot make decision on something like that, if you tell me the drug has a special indication I can make a constraint to block that label. The security system cannot invent that stuff that has to be provided us. We have to have tagging for sensitivity levels that will be covered in the constraint catalog. You cannot bring unrelated things that are not sensitive by themselves. The level that we’re at right now, we have to be in your face it HAS to be something that says AIDs…and block that. Look at things like, such as notes that clinician’s make who knows what it says? (Mike)
To create that type of privacy and consent, you need to know the contents of these objects; we’re not at that level (Steve) Not exactly. The way it’s done in security now, the notion of levels, DoD has classified secret, top secret, etc...special intelligence, the way security system operations the sensitive information (known to be HIV at that level you either have to have the ability to read it or above, or if you only allowed to see the confidential stuff (maybe below HIV) you couldn’t read UP to the HIV stuff…HIV belongs to that bucket. We can specify to the system you have the ability to read UP to a level… we don’t’ classify the data. That’s called a labeled access control system, it would require to throw out everyone’s data base and insert a different data base…we’re trying to make due with what we have…reality touching idealism we can label things and make decision those labels, but it doesn’t give protections (Mike) You’re saying the defense systems have a more elaborate system of roles… (Richard) More that a person has a level of roles (David)
This may not be a good way to identify things in a healthcare system…patient safety trumps security. We don’t kill patients to protect their security. Some people disagree. Regardless the security system is not responsible for labeling data that’s the EHR, if we have the labels (i.e. those coming from CBCC) we can implement and security can enforce. When sensitive information is spaghetti coded you cannot expect the security system to control that…and protect that…it needs structure, structured data. Constraints can include such attributes…see RX except marked as HIV but that mark has to be there… we’re still arguing how to define an RX (Mike)
- (5 min) Other Business
