February 10 2009
Security Working Group Meeting
Attendees
- Suzanne Gonzales-Webb CBCC Co-chair
- Glen Marshall Security Co-chair, absent
- Rob McClure
- Richard Thoreson CBCC Co-chair
- Ioana Singureanu
- Tony Weida
Agenda
- (05 min) Roll Call
- (05 min) Approve Minutes & Accept Agenda
- (45 min) Role Engineering Process review ~Suzanne HL7 Role Engineering Process
The purpose of the review was to assist the vocabulary analysts working on the CBCC-Security joint project on the development of the objects found in the current HL7 Permission Catalog. The Role Engineering Process was used in developing the balloted HL7 RBAC Permission Catalog. It was submitted with the balloted RBAC Permission Catalog as supporting data in determining/deriving our permission sets (action-object sets). Discussion highlights:
- See Figure 2: Scenario Model 'Neumann/Strembeck'
In determining Permissions, we start with
- Work Profile, within the work profile Task 1, Task 2...to Task n are determined.
- Tasks are then broken down into individual Scenarios (Scenarios may be viewed as 'business workflow' or use cases in the shown figure model.
- Scenarios are further broken down into individual Steps
- Steps are drilled down to individual Permissions or 'Actions on an Object'
An example of a Work Profile: A Pharmacist (Functional role) processing an outpatient prescription. Task: Pharmacist receives the prescription Scenario: Pharmacist has to clarify the patient information on the prescription and asks the patient the following information.
- Step 1: Correct spelling of patient name
- Step 2: patient date-of-birth
- Step 3: Patient address
- etc.
From each of these steps a Permission can be derived.
- Permission 1: Pharmacist can 'READ' 'Patient Demographic'
- Permission 2: Pharmacist can 'UPDATE' 'Patient Demographic'
- Permission 3: Pharmacist can 'CHANGE' 'Patient Demographic'
- etc.
It is know that this process is very tedious. Note that the Pharmacist has not even begun the process of actually processing the prescription which is another step in the scenario. The process was used in the clinical setting to determine the current list of permissions and will be used to determine permissions for financial management.
In determining a standard vocabulary for the permission catalog, the constraint catalog (including Privacy and Consent) as well as financial management will need to include those objects--or most of the objects used in each of these groups. The attendees agreed that the current permission catalog vocabulary will be the baseline (as Security WG has deemed as the minimum set for interoperability).
For Security purposes, if an object (physical or functional) can be identified it can be protected.
Standardized vocabularies reviewed do not map cleanly to the entire group, SNOMED CT was being more closely looked at as a starting point due to their extensive heirachy of terms. From this starting point, those objects missing from SNOMED CT can be dealt with either by referencing another standardized vocabulary or possible contacting SNOMED CT to add the missing object term into their vocabulary set.
It was noted that in order to continue work on extending the current permission catalog vocabulary with privacy, constraint and financial management the baseline of the permission catalog should be completed.
The vocabulary that will be needed to associated with the current permission catalog
(meeting ran over 12 minutes)
