Difference between revisions of "June 18, 2013 Security WG Conference Call"
(→Agenda) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 28: | Line 28: | ||
==Meeting Minutes== | ==Meeting Minutes== | ||
'''Roll Call, Approve Minutes & Accept Agenda''' | '''Roll Call, Approve Minutes & Accept Agenda''' | ||
| + | Motion made to accept meeting minutes for June 4, June 11 and May 28. (Kahleen / Suzanne) | ||
| + | No objections,, No obstations, motion passes (0/0/8) | ||
'''Statement on Conformance''' Tony Weida | '''Statement on Conformance''' Tony Weida | ||
| + | MOTION: //Security and Privacy Ontology//mark line 48 as persuasive (Kathleen / Tony) | ||
| + | No objections, No abstentions, motion passes (0/0/8) | ||
from e-mail: 6/18/2013, 0815 AM PST | from e-mail: 6/18/2013, 0815 AM PST | ||
| − | ''to support reconciliation of Comment 55 (and Comment 13), has been revised based on initial discussion during last week’s call. | + | ''to support reconciliation of Comment 55 (and Comment 13), has been revised based on initial discussion during last week’s call.'' |
To expand on several column headings, a sub-ontology is considered … | To expand on several column headings, a sub-ontology is considered … | ||
| − | + | * Extensible, if the sub-ontology MAY be imported into a new sub-ontology and augmented therein, e.g., by adding new classes (descendants or siblings of existing classes), so that the new sub-ontology may be used together with the original. | |
| − | + | * Replaceable, if a different sub-ontology MAY be used instead. | |
| − | + | * Dynamic, if the most recent available version of a sub-ontology SHOULD be used, potentially a new version published after publication of the Security and Privacy Ontology specification. | |
| − | For example, making SensitivityOntology extensible permits additional types of sensitivity not presently represented in the corresponding HL7 vocabulary. Making it replaceable supports a jurisdiction where a completely different set of sensitivity codes is mandated. Making SensitivityOntology dynamic would enable it to track future harmonization changes. (Although there was earlier discussion in favor of the dynamic approach as reflected in the May ballot document, discussion during last week’s call was opposed to dynamic sub-ontologies; instead it was felt that the ontology specification should designate specific versions of HL7 vocabulary resources, namely, the latest versions at the time the ontology specification is published.) | + | ''For example, making SensitivityOntology extensible permits additional types of sensitivity not presently represented in the corresponding HL7 vocabulary. Making it replaceable supports a jurisdiction where a completely different set of sensitivity codes is mandated. Making SensitivityOntology dynamic would enable it to track future harmonization changes. (Although there was earlier discussion in favor of the dynamic approach as reflected in the May ballot document, discussion during last week’s call was opposed to dynamic sub-ontologies; instead it was felt that the ontology specification should designate specific versions of HL7 vocabulary resources, namely, the latest versions at the time the ontology specification is published.) '' |
| − | Considering the preceding, conformance statements for SensitivityOntology could be revised to: | + | ''Considering the preceding, conformance statements for SensitivityOntology could be revised to:'' |
| − | This sub-ontology is intended to have “static stability” in the parlance of HL7 “Core Principles” (26). Thus it MUST represent the most recent harmonized version available for the HL7 v3 ActInformationSensitivityPolicy value set as of <MONTH DATE, YEAR>. | + | ''This sub-ontology is intended to have “static stability” in the parlance of HL7 “Core Principles” (26). Thus it MUST represent the most recent harmonized version available for the HL7 v3 ActInformationSensitivityPolicy value set as of <MONTH DATE, YEAR>. '' |
| − | + | ''In a conforming application, sensitivity values SHOULD be selected via SensitivityOntology.owl. For example, values of the OWL hasSensitivity property SHOULD be chosen from the preceding table. If, in the process of deciding whether to allow an access request, a conforming application encounters a specified sensitivity value which it does not recognize, that access request SHALL be denied.'' | |
| − | + | ''We noted that the current HL7 RBAC Healthcare Permission Catalog does not allow additional operations or objects. Participants on the call advocated a similarly conservative approach for the corresponding sub-ontologies. On the other hand, permissions in the HL7 RBAC Healthcare Permission Catalog were positioned as examples, so an extended or replacement set of permissions can be used, as long as they are built strictly from the normative operations and objects.'' | |
| − | |||
| − | We noted that the current HL7 RBAC Healthcare Permission Catalog does not allow additional operations or objects. Participants on the call advocated a similarly conservative approach for the corresponding sub-ontologies. On the other hand, permissions in the HL7 RBAC Healthcare Permission Catalog were positioned as examples, so an extended or replacement set of permissions can be used, as long as they are built strictly from the normative operations and objects.'' | ||
Latest revision as of 22:07, 18 June 2013
Contents
Security Working Group Meeting
Attendees
- Kathleen Connor
- Mike Davis Security Co-chair
- Mike Dufel, Jericho Solutions
- [mailto: Duane Decouteau}
- Suzanne Gonzales-Webb CBCC Co-chair
- [mailto: Brian Handpicker]
- Adrianne James
- John Moehrke Security Co-chair
- Diana Proud-Madruga
- [mailto: Harry Rhoades]
- David Staggs, Jericho Systems
- Tony Weida
Agenda
- (05 min) Roll Call, Approve Minutes & Accept Agenda
- (15 min) Update on Conformance Statements Tony Weida
Meeting Minutes
Roll Call, Approve Minutes & Accept Agenda Motion made to accept meeting minutes for June 4, June 11 and May 28. (Kahleen / Suzanne) No objections,, No obstations, motion passes (0/0/8)
Statement on Conformance Tony Weida
MOTION: //Security and Privacy Ontology//mark line 48 as persuasive (Kathleen / Tony)
No objections, No abstentions, motion passes (0/0/8)
from e-mail: 6/18/2013, 0815 AM PST to support reconciliation of Comment 55 (and Comment 13), has been revised based on initial discussion during last week’s call.
To expand on several column headings, a sub-ontology is considered …
- Extensible, if the sub-ontology MAY be imported into a new sub-ontology and augmented therein, e.g., by adding new classes (descendants or siblings of existing classes), so that the new sub-ontology may be used together with the original.
- Replaceable, if a different sub-ontology MAY be used instead.
- Dynamic, if the most recent available version of a sub-ontology SHOULD be used, potentially a new version published after publication of the Security and Privacy Ontology specification.
For example, making SensitivityOntology extensible permits additional types of sensitivity not presently represented in the corresponding HL7 vocabulary. Making it replaceable supports a jurisdiction where a completely different set of sensitivity codes is mandated. Making SensitivityOntology dynamic would enable it to track future harmonization changes. (Although there was earlier discussion in favor of the dynamic approach as reflected in the May ballot document, discussion during last week’s call was opposed to dynamic sub-ontologies; instead it was felt that the ontology specification should designate specific versions of HL7 vocabulary resources, namely, the latest versions at the time the ontology specification is published.)
Considering the preceding, conformance statements for SensitivityOntology could be revised to:
This sub-ontology is intended to have “static stability” in the parlance of HL7 “Core Principles” (26). Thus it MUST represent the most recent harmonized version available for the HL7 v3 ActInformationSensitivityPolicy value set as of <MONTH DATE, YEAR>.
In a conforming application, sensitivity values SHOULD be selected via SensitivityOntology.owl. For example, values of the OWL hasSensitivity property SHOULD be chosen from the preceding table. If, in the process of deciding whether to allow an access request, a conforming application encounters a specified sensitivity value which it does not recognize, that access request SHALL be denied.
We noted that the current HL7 RBAC Healthcare Permission Catalog does not allow additional operations or objects. Participants on the call advocated a similarly conservative approach for the corresponding sub-ontologies. On the other hand, permissions in the HL7 RBAC Healthcare Permission Catalog were positioned as examples, so an extended or replacement set of permissions can be used, as long as they are built strictly from the normative operations and objects.
Item 2
Item3
Other Business
