Difference between revisions of "February 21st, 2012 Security Working Group Conference Call"
Line 35: | Line 35: | ||
'''Harmonization Proposals ''' Update (Kathleen) | '''Harmonization Proposals ''' Update (Kathleen) | ||
*Kathleen updated the WG on some technical corrections made to the coversheets per input from vocabulary. She will continue to refine the proposals with further input and get these to the WG for final approval to submit by next week’s call (February 28th). | *Kathleen updated the WG on some technical corrections made to the coversheets per input from vocabulary. She will continue to refine the proposals with further input and get these to the WG for final approval to submit by next week’s call (February 28th). | ||
− | *She discussed [http://gforge.hl7.org/gf/download/docmanfileversion/6666/9132/March2012ProposedHarmonizationVocabulary.pptx March 2012 Proposed Harmonization Vocabulary] slides: (1) a diagram showing the structure and relationships among the proposed vocabulary, (2) a Visio version of the DAM to which she is adding relevant standards and vocabularies, and (3) a diagram illustrating how the DAM includes RBAC permissions as a refinement. Kathleen noted that the DAM represents RBAC Permissions as components of a Security Role (Figure 1.1.1: Authorization (Role-based Access Control) rather than as a Basic Policy, which does not align with the DAM’s Security perspective. This last topic will likely need follow up discussion to clarify questions raised by Mike and John about the relationship between RBAC Permission Catalog as a vocabulary and as a class in the DAM. | + | *She discussed [http://gforge.hl7.org/gf/download/docmanfileversion/6666/9132/March2012ProposedHarmonizationVocabulary.pptx March 2012 Proposed Harmonization Vocabulary] slides: (1) a diagram showing the structure and relationships among the proposed vocabulary, (2) a Visio version of the DAM to which she is adding relevant standards and vocabularies, and (3) a diagram illustrating how the DAM includes RBAC permissions as a refinement. Kathleen noted that the DAM represents RBAC Permissions as components of a Security Role (Figure 1.1.1: Authorization (Role-based Access Control) rather than as a Basic Policy, which does not align with the DAM’s Security perspective. This last topic will likely need follow up discussion to clarify questions raised by Mike and John about the relationship between RBAC Permission Catalog as a vocabulary and as a class in the DAM. See slides 5 - 7 added after the call to [http://gforge.hl7.org/gf/download/docmanfileversion/6666/9132/March2012ProposedHarmonizationVocabulary.pptx March 2012 Proposed Harmonization Vocabulary] |
**[http://gforge.hl7.org/gf/download/docmanfileversion/6653/9119/HL7HarmonizationProposalMarch2012PurposeofUse.doc Purpose of Use Vocabulary Update Harmonization Proposal] | **[http://gforge.hl7.org/gf/download/docmanfileversion/6653/9119/HL7HarmonizationProposalMarch2012PurposeofUse.doc Purpose of Use Vocabulary Update Harmonization Proposal] | ||
**[http://gforge.hl7.org/gf/download/docmanfileversion/6654/9120/HL7HarmonizationProposalMarch2012TechnicalCorrectionActPolicyType.doc ActPrivacyPolicy Technical Corrections Harmonization proposal] | **[http://gforge.hl7.org/gf/download/docmanfileversion/6654/9120/HL7HarmonizationProposalMarch2012TechnicalCorrectionActPolicyType.doc ActPrivacyPolicy Technical Corrections Harmonization proposal] |
Revision as of 07:06, 22 February 2012
Contents
Security Working Group Meeting
Attendees
- Kathleen Connor
- Mike Davis Security Co-chair
- Suzanne Gonzales-Webb CBCC Co-chair
- John Moehrke Security Co-chair
Agenda
- (05 min) Roll Call, Approve Minutes & Accept Agenda
- (15 min) ONC Privacy & Security Mobile Device Roundtable Input
- (15 min) Security and Privacy Ontology- Update (Tony unable to make today's call)
- (10 min) Harmonization Proposals Update (Kathleen)
- (10 min) Security WG Documents - update Bill Braithwaite
- (10 min) Interim Co-Chair appointment
Meeting Minutes
Mike Davis - Presiding Cochair
- Roll Call: Many are attending HIMSS.
- Approval of Minutes – deferred.
- Agenda modifications:
- Add update on Security and Privacy Ontology ballot status and project scope statement
- Defer Security and Privacy Ontology Update (Tony unable to make today's call)
Agenda item pushed to next week. Will contact Tony to request a report be distributed via the Security listserve.
- Security and Privacy Ontology Project Wiki
- Defer Security WG Documents update because Bill is absent.
Discussion Items
Update on Security and Privacy Ontology ballot status and project scope statement.
- Mike announced that the Security and Privacy Ontology will be balloted in May as a for comment only ballot because Tony will not be able to complete the work before then. Mike recommended that the Ontology be balloted as normative in September rather than DSTU. Kathleen noted that the TSC has ruled that domain analysis models should not be balloted as DSTU because they cannot be implemented directly, and that the same reasoning would likely apply to an ontology.
- Mike walk-through the updates he proposed for the Security and Privacy Ontology Project Scope statement that reflect the change in balloting status and dates. Suzanne offered additional corrections to artifact names and assignments. Mike has already asked for agenda time on the upcoming Domain Expert Steering Division call to ask for approval for these changes if the Security WG approves them.
- Suzanne moved to approve; John seconded; motion carried without discussion 3-0-0.
Kathleen will research the status of the May 2011 Ontology ballot reconciliation and the steps needed to complete that in order to ballot this May. Interim Co-Chair appointment
- Mike announced the outcome of the online voting as 18-0-0 in favor of a fourth Security WG cochair. He noted that the WG may nominate an interim fourth cochair who may serve through September by which time the WG needs to officially petition for an election of a fourth cochair.
Harmonization Proposals Update (Kathleen)
- Kathleen updated the WG on some technical corrections made to the coversheets per input from vocabulary. She will continue to refine the proposals with further input and get these to the WG for final approval to submit by next week’s call (February 28th).
- She discussed March 2012 Proposed Harmonization Vocabulary slides: (1) a diagram showing the structure and relationships among the proposed vocabulary, (2) a Visio version of the DAM to which she is adding relevant standards and vocabularies, and (3) a diagram illustrating how the DAM includes RBAC permissions as a refinement. Kathleen noted that the DAM represents RBAC Permissions as components of a Security Role (Figure 1.1.1: Authorization (Role-based Access Control) rather than as a Basic Policy, which does not align with the DAM’s Security perspective. This last topic will likely need follow up discussion to clarify questions raised by Mike and John about the relationship between RBAC Permission Catalog as a vocabulary and as a class in the DAM. See slides 5 - 7 added after the call to March 2012 Proposed Harmonization Vocabulary
ONC Privacy & Security Mobile Device Roundtable Input – For reference only, but not discussed during call. John’s response to the HL7 Policy Committee below. e-mail to HL7 Co-Chairs: ONC's Office of the Chief Privacy Officer in cooperation with the HHS Office for Civil Rights (OCR) launched a Privacy & Security Mobile Device project. HL7 may have an opportunity this Spring to provide input into this project during a public roundtable. Although the focus is on privacy and security and many of those elements may be outside of HL7's domain as they are managed through lower level protocols, operating systems, etc., there is a sense that some of our standards may be, or may need to be applicable and sensitive to the context of a mobile device where the data exchanged is consumed. We would like to get your input whether your workgroup already has, is planning to develop, or would believe there should be HL7 standards and/or guidance to enhance on the privacy and security of mobile devices. For example, are hardware/OS/network solutions sufficient to achieve appropriate privacy & security levels unique to mobile devices, or should additional data be available at the application level to enable appropriate restrictions by the application at that mobile device, or should we be completely agnostic to that context? Are there capabilities in the functional model that should be further defined uniquely to mobile devices, or is that context irrelevant? A further question may be whether with the expansion of mobile devices there are other aspects beyond privacy & security in particular and that are unique to mobile computing that HL7 workgroups are already focusing on, have plans for, or should be considering. Although the primary focus of this question is on the Security, Healthcare Devices, EHR, CIC, and CBCC workgroups, other workgroups may have some perspectives as well that we should consider. We would appreciate your feedback by March 31 to help us determine how HL7 should respond to a request to contribute to the public roundtable. You may post this on the PAC wiki page for Privacy & Security for Mobile Devices, or forward to either John Speakman or Hans Buitendijk.
Policy Advisory Committee Co-Chairs: Hans J. Buitendijk
Siemens Medical Solutions USA, Inc. Standards & Regulations Manager John Speakman Chief Program Office NCI Center for biomedical Informatics and Information Technology John’s response to HL7 Policy Committee Hans, I would request that you include: • Security WG – Basic security and privacy • CBCC WG – Privacy – Consent Directive CDA template • SOA WG -- Services Oriented view used by many mobile devices; also include Access Control and Audit Control services • EHR FM WG – Functional Model that includes Security and Privacy functional capabilities
My overall my answer is, that mobile devices are not different than any other. Mobile Devices are just more likely to get lost or stolen (for pawn). It is this increased likelihood (of known risks) that needs to be considered. Thus good application design keeps sensitive information off of the device. Since this is a USA domain, it is quite easy to point at NIST who have excellent guidelines on this topic: • NIST Guidelines on Cell Phone and PDA Security SP800-124.pdf • NIST Guide to Storage Encryption Technologies for End User Devices SP800-111.pdf • NIST Recommended Security Controls for Federal Information Systems and Organizations SP800-53-rev3-db
The policy, methods, and technology used to protect a mobile device are common place in IT security circles. There is little that HL7 should add except where there are deep specifics to Healthcare and specifically HL7 artifacts. In the HL7 space, we do encourage a Risk Assessment/Management approach to reasonable applying security technology according to risk Impact and likelihood. This is the core of our Security Risk Assessment Cookbook, that which is being included in the fabric of HL7 standards development. Beyond this we do have tools in the HL7 family that are not specific to Mobile devices but are just as applicable: EHR Functional Model that includes security and privacy functionality – with efforts to align with ISO-1441 security functional models; Services for Access Control, and Audit Controls; Role-Based Access Control Permissions Catalog; ConfidentialityCode vocabulary; and Composite Consent Directive (CDA). John Moehrke Co-chair Security WG