June 18, 2013 Security WG Conference Call

Security Working Group Meeting

• Meeting Information

Back to Security Main Page

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

Back to Security Main Page

Agenda

1. (05 min) Roll Call, Approve Minutes & Accept Agenda
2. (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

Action Items

Back to Security Main Page