Difference between revisions of "March 10th 2009 Security Conference Call"
(New page: =Security Working Group Meeting= * Meeting Information ==Attendees== (expected) * [mailto:sconnolley@apelon.com Steven Connolley] * [mailto:coynee@saic.com Ed Coyne] * [mai...) |
|||
(6 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
* [mailto:sconnolley@apelon.com Steven Connolley] | * [mailto:sconnolley@apelon.com Steven Connolley] | ||
− | |||
* [mailto:mike.davis@va.gov Mike Davis] Security Co-chair | * [mailto:mike.davis@va.gov Mike Davis] Security Co-chair | ||
* [mailto:gonzaleswebs@saic.com Suzanne Gonzales-Webb] CBCC Co-chair | * [mailto:gonzaleswebs@saic.com Suzanne Gonzales-Webb] CBCC Co-chair | ||
* [mailto:robert.horn@agfa.com Bob Horn] | * [mailto:robert.horn@agfa.com Bob Horn] | ||
− | * [mailto: | + | * [mailto:ken@claricode.com Ken Tubman] |
− | * [mailto:glen.f.marshall@siemans.com Glen Marshall] Security Co-chair | + | * [mailto:glen.f.marshall@siemans.com Glen Marshall] Security Co-chair |
* [mailto:rmcclure@apelon.com Rob McClure] | * [mailto:rmcclure@apelon.com Rob McClure] | ||
* [mailto:john.moehrke@med.ge.com John Moehrke] | * [mailto:john.moehrke@med.ge.com John Moehrke] | ||
− | * [mailto: | + | * [mailto:ppyette@perimind.com Pat Pyette] |
− | * [mailto:richard.thoreson@samhsa.hhs.gov Richard Thoreson] CBCC Co-chair | + | * [mailto:dsperzel@apelon.com David Sperzel] |
+ | * [mailto:richard.thoreson@samhsa.hhs.gov Richard Thoreson] CBCC Co-chair, absent | ||
* [mailto:ioana@eversolve.com Ioana Singureanu] | * [mailto:ioana@eversolve.com Ioana Singureanu] | ||
* [mailto:weida@apelon.com Tony Weida] | * [mailto:weida@apelon.com Tony Weida] | ||
Line 23: | Line 23: | ||
− | ==Agenda== | + | ==Agenda and Minutes '''(DRAFT)'''== |
#''(05 min)'' Roll Call | #''(05 min)'' Roll Call | ||
#''(05 min)'' Approve Minutes & Accept Agenda | #''(05 min)'' Approve Minutes & Accept Agenda | ||
− | #''( | + | #''(30 min)'' '''[http://hl7projects.hl7.nscee.edu/docman/view.php/59/1455/Operations%20Comments%20JMD.xls Operations Spreadsheet comments] ''' - Mike Davis |
− | + | (concern) 'Mixed concept' within the spreadsheet - | |
− | # | + | Mike's table is a table of verbs, there is no problem to add more terms outside of 'CRUDE' but it needs to make sense to do that. |
− | + | '''[Updated Operations Spreadsheet - need from Tony W] ''' - Tony Weida | |
+ | |||
+ | There are several dualities in the spreadsheet | ||
+ | * We have two views on the spreadsheet: | ||
+ | # operations on the object (which is what security is interested) | ||
+ | # operations on attributes (changing the status of an object attribute) | ||
+ | |||
+ | Status modification should be placed under ‘’update’’ | ||
+ | CRUDE is a known taxonomy, if we place terms under CRUDE… | ||
+ | I would be most interested in those things ‘not’ placed under CRUDE (or CRUDEA) | ||
+ | |||
+ | Let’s stay with the ANSI-INCITS definition: object: passive entity… | ||
+ | |||
+ | * So, If I give someone permission to cancel, I am giving them permission to cancel…’the real world’ meaning the actual … | ||
+ | |||
+ | Currently: (Pat) the things on the list are workflow and would not be seen as part of a patient consent request. Patient would want to | ||
+ | In the patient Consent: can you read, can you write..that’s what it boils down to. When a patient says ‘I don’t want x-person to see or read this portion of my record…’’ | ||
+ | |||
+ | We will need to address the dualities, if the patient is expressing control | ||
+ | |||
+ | The spreadhsset is to be seen as an operation code system. They will not necessarily all be used together. Suggestion: is to map the privacy terms and the security terms into this spreadsheet. If you want to focus on just the RBAC, then you can create a value set of CRUDEA, then you would include those. If you want to address privacy and consent and you want to categorize usage and disclosure, you can look at the | ||
+ | |||
+ | '''Creating suitable value sets, mapping''' | ||
+ | '''Define the terms so that they are shared, so that we don’t have to map everything to everything.''' | ||
+ | |||
+ | The use of the terms here are descriptive terms that are overloading primitives here with the name of a policy. Includes who the person is who is involved in the disclose—which is part of the policy. Disclosure (collection, use and dis..) these are the 3 privacy terms that are understood for privacy and consent. | ||
+ | *disclose – definition: | ||
+ | * collects | ||
+ | *use | ||
+ | * | ||
+ | |||
+ | 10:45 – | ||
+ | |||
+ | Agreement: modify status is a revision… | ||
+ | Proposal: to swap revise and update. Revise is defined as being a revision (not clear) update is clear- results; update is the primitive and revise is a subset of that | ||
+ | |||
+ | Note the consumer of this vocabulary | ||
+ | |||
+ | Goal: Ballot update | ||
+ | What do we need to update for the Security ‘and Privacy’ for the upcoming ballot in September. If these are not directly linked to the consent directive then we should be put aside—continue to work on them but concentrate efforts on the things we need to have for the ballot update | ||
+ | |||
==Action Items== | ==Action Items== | ||
+ | |||
+ | '''Need to separate which area(s) of the spreadsheet are part of the Security-CBCC Joint project and which is vocabulary solely in the CBCC domain.''' | ||
[[Security|Back to Meetings]] | [[Security|Back to Meetings]] |
Latest revision as of 18:16, 10 March 2009
Security Working Group Meeting
==Attendees== (expected)
- Steven Connolley
- Mike Davis Security Co-chair
- Suzanne Gonzales-Webb CBCC Co-chair
- Bob Horn
- Ken Tubman
- Glen Marshall Security Co-chair
- Rob McClure
- John Moehrke
- Pat Pyette
- David Sperzel
- Richard Thoreson CBCC Co-chair, absent
- Ioana Singureanu
- Tony Weida
- Craig Winter
Agenda and Minutes (DRAFT)
- (05 min) Roll Call
- (05 min) Approve Minutes & Accept Agenda
- (30 min) Operations Spreadsheet comments - Mike Davis
(concern) 'Mixed concept' within the spreadsheet - Mike's table is a table of verbs, there is no problem to add more terms outside of 'CRUDE' but it needs to make sense to do that. [Updated Operations Spreadsheet - need from Tony W] - Tony Weida
There are several dualities in the spreadsheet
- We have two views on the spreadsheet:
- operations on the object (which is what security is interested)
- operations on attributes (changing the status of an object attribute)
Status modification should be placed under ‘’update’’ CRUDE is a known taxonomy, if we place terms under CRUDE… I would be most interested in those things ‘not’ placed under CRUDE (or CRUDEA)
Let’s stay with the ANSI-INCITS definition: object: passive entity…
- So, If I give someone permission to cancel, I am giving them permission to cancel…’the real world’ meaning the actual …
Currently: (Pat) the things on the list are workflow and would not be seen as part of a patient consent request. Patient would want to In the patient Consent: can you read, can you write..that’s what it boils down to. When a patient says ‘I don’t want x-person to see or read this portion of my record…’’
We will need to address the dualities, if the patient is expressing control
The spreadhsset is to be seen as an operation code system. They will not necessarily all be used together. Suggestion: is to map the privacy terms and the security terms into this spreadsheet. If you want to focus on just the RBAC, then you can create a value set of CRUDEA, then you would include those. If you want to address privacy and consent and you want to categorize usage and disclosure, you can look at the
Creating suitable value sets, mapping Define the terms so that they are shared, so that we don’t have to map everything to everything.
The use of the terms here are descriptive terms that are overloading primitives here with the name of a policy. Includes who the person is who is involved in the disclose—which is part of the policy. Disclosure (collection, use and dis..) these are the 3 privacy terms that are understood for privacy and consent.
- disclose – definition:
- collects
- use
10:45 –
Agreement: modify status is a revision… Proposal: to swap revise and update. Revise is defined as being a revision (not clear) update is clear- results; update is the primitive and revise is a subset of that
Note the consumer of this vocabulary
Goal: Ballot update What do we need to update for the Security ‘and Privacy’ for the upcoming ballot in September. If these are not directly linked to the consent directive then we should be put aside—continue to work on them but concentrate efforts on the things we need to have for the ballot update
Action Items
Need to separate which area(s) of the spreadsheet are part of the Security-CBCC Joint project and which is vocabulary solely in the CBCC domain.