HL7
Insert Project ID: TBD
Role-Based Access Control (RBAC)
Insert Project Classification: TBD>
Project Plan – Security and Privacy Update
January 2008
Version 1.1
TABLE OF CONTENTS
1.0 Revision History 1
2.0 Project Overview / Description 2
2.1 Strategic Fit 2
2.1.1 HL7 Strategic Imperative 2
2.1.2 The mandate of the project is to: 2
2.2 Completion and Success Criteria: 3
2.2.1 We have reached completion when: 3
2.2.2 We have achieved success when: 3
2.2.3 Who gets to vote on completion and success? 3
3.0 Project Scope 3
3.1 Scope Inclusions 3
3.2 Scope Exclusions 3
4.0 Project Goals, Objectives and Deliverables 4
5.0 Project Stakeholders, Participants and Resources 5
5.1 Leadership Team 5
5.2 Active Participants & Required Resources 5
6.0 Project Assumptions and Constraints 6
6.1 Project Assumptions are: 6
6.2 Project Constraints are: 6
7.0 Project Risks 6
7.1 Project Risks 6
8.0 Preliminary Project Schedule 7
8.1 Project Schedule 7
9.0 Inter-Project Dependencies 7
10.0 Project Plan Acceptance/ Approvals 8
11.0 Appendices 9
11.1 Appendix A – Client Engagement 9
11.1.1 Project Plan 9
11.2 Appendix B – Project Controls 9
11.2.1 Project schedule (high level work plan) 9
11.2.2 Project status reporting 9
11.2.3 Project change management 10
11.2.4 Project Issue Management 10
HL7
Project ID / TBDProject Name / Role Based Access Control (RBAC), Security and Privacy update
Classifications / Type of Product / Security and Privacy update to current HL7 RBAC Project
Type of Development / Analysis and Update to current documentation
Scope of Participation / HL7 Enterprise
Source of Resources / HL7 Security Technical Committee and
Responsible Party: / Mike Davis (VHA), Suzanne Gonzales-Webb (VHA)
Project Sponsor(s): / HL7 Security Technical Committee, Community Based Health Services
Project Steering Team: / HL7 Security Technical Committee
Project Leader / Manager: / Mike Davis
HL7 Facilitators / Modeling / <insert MnM Facilitator TBD
Vocabulary / <insert Vocabulary Facilitator TBD
Publishing / <insert Scope of Participation> TBD
1.0 Revision History
File Name / HL7 Project Plan - RBAC Security and Privacy UpdateVersion / Date / Author / Description
1.0 / 01/01/2008 / Suzanne Gonzales-Webb / Initial draft
1.1 / 01/09/2008 / Craig Winter / QA Review / Revision
Note: Changes to project scope are subject to the project scope change management processes. See section 11.2.3, “Project change management.”
2.0 Project Overview / Description
2.1 Strategic Fit
2.1.1 HL7 Strategic Imperative
The initial documentation approved by HL7 ballot was recognized to be incomplete. At the time of draft, Security was the main idea relayed in the documentation. The Security Technical Committee post the ballot approval has recognized that the current RBAC documentation required more than just security information but also Privacy. This project management plan is an effort to add these necessary missing privacy elements.
2.1.2 The mandate of the project is to:
The goal of the RBAC Security and Privacy Update is an effort to add the necessary mission privacy elements in compliance with other standards organizations (SDOs) such as HITSP, HIPAA and others (Sarbanes Oxley, Graham Leach Bliley), while allowing for continued flexibility in implementation and international usage.
· HITSP
· Privacy consent encoding (later discussion for this TC) is an open issue. Otherwise, no requests for HL7.
· Note that HITSP uses IHE DSG profile, which coincides with the HL7 Security TC’s advice that Structured Documents use the XML digital signature specification as-is.
· Access control construct references the HL7 RBAC permission vocabulary.
· Mike Davis will drive evaluation of HL7 RBAC vocabulary relative to HITSP use cases.
From RBAC Ballot reconciliation dated September 2007
Rationale for non-persuasive items: The Security TC identified negative ballot items from Fox Systems (provided by Kathleen Connor) as good candidates for future work, but not in the intended scope of the current ballot. The offer to resolve these negative items as “accepted as future items” was rejected. The Security TC then determined that it was not persuaded to add new permission use cases to the current ballot. All of the non-persuasive items will be candidates for future extensions to the permission vocabulary.
Motion [Davis, Blobel] Accept the ballot resolution document.
· Discussion: Bernd Blobel offered to change his “abstain” vote to “affirmative with comment.” He offered to provide resolution text for his comment within six weeks.
· Motion to table this motion until Bernd’s text is available. [Blobel, Davis] passed [8-0-0]
2.2 Completion and Success Criteria:
2.2.1 We have reached completion when:
Completion of the RBAC Security and Privacy update documentation when satisfactory agreement has been achieved by interested parties (HL7 Security Technical Committee, and other) and the HL7 balloting process has completed.
2.2.2 We have achieved success when:
Success has been achieved once both security and privacy awareness for users and patients (and their families) have been satisfactorily accounted for.
2.2.3 Who gets to vote on completion and success?
Initial documentation to be approved by the following stakeholders:
· Security Technical Committee Co-Chairs
· Selected Privacy Participants
§ Kathleen Conner (Fox Systems)
§ VHA Privacy Associate (Marlene Haddad-tentative)
§ TBD (Vendor – i.e., GE, Siemens)
· Suzanne Gonzales-Webb (co-author)
Final documentation to be balloted by HL7.
3.0 Project Scope
3.1 Scope Inclusions
The scope of this project includes assessment of current HL7, SDO Privacy coding and regulations. Additions to the current RBAC Permission Catalogue will be added as necessary and appropriate for the scope of this project. Regular maintenance reviews as decided by the HL7 Security TC will be scheduled (i.e., annual, bi-annual) as necessary to maintain the most current practices. A review group selected from the Security TC shall be formed for consistency in documentation and future balloting may be necessary. The committee members may be required to attend outside SDO to clarify security and privacy inconsistencies with the HL7 Security and Privacy Update.
3.2 Scope Exclusions
The scope of this project does not include: the creation or assessment specifics of outside SDO Security and/or Privacy coding, requirements or related issues outside of HL7 interests.
4.0 Project Goals, Objectives and Deliverables
Goals: Describe the purpose of this project in terms of its goals - what it hopes to achieve, and what business problems or opportunities it addresses.
Objectives: For each goal, describe the project objectives that directly support that goal.
Deliverables: Any measurable, tangible, verifiable outcomes, results, or items that must be produced to complete a project.
Goals / Objectives / Deliverables / Measure of Deliverable CompletionGoal 1
Role-Based Access Control (RBAC) Security and Privacy Update / Objective A
Submit draft of RBAC Security and Privacy Update / Deliverable 1
Deliverable 2
Deliverable 3
Objective B
Peer Review of Draft / Deliverable 4
Deliverable 5
Deliverable 6
Objective C
Submit Final Draft to Security TC, Stakeholders / Deliverable 7
Deliverable 8
Deliverable 9
Deliverable 10
Deliverable 11
Deliverable 12
Goal 2
Formation of the review group (Security TC membership) / Objective D / Deliverable 13 / Names for participating members for review group
Deliverable 14 / Identification of review group leader, POC
Deliverable 15
Goal 3
Ballot Approval of Final Documentation / Objective E / Deliverable 16 / Approved HL7 Ballot
Deliverable 17
Deliverable 16
5.0 Project Stakeholders, Participants and Resources
5.1 Leadership Team
· Project Sponsor – HL7 Security Technical Committee
· Responsible Party – Mike Davis, Kathleen Conner, Suzanne Gonzales-Webb
Technical Committee – Security TC, Community Based Health Services
· HL7 Facilitator – Security TC Co-Chairs
· Project Leader / Manager – Mike Davis
· Beneficiaries – All of HL7
· Project Steering Committee –
The Project Steering Committee consists of the following members:
Name / RoleMike Davis / Lead, Project Manager
Kathleen Conner / Contributor/Reviewer
Suzanne Gonzales-Webb / Contributor/Reviewer
Bernd Blobel / Contributor/Reviewer
Glen Marshall / Contributor/Reviewer
VA Privacy Associate (TBD) / Contributor/Reviewer
Vendor Privacy Associate (TBD) / Contributor/Reviewer
5.2 Active Participants & Required Resources
Team Member / Role / Focus AreaMike Davis / Project Manager / Security
Kathleen Conner / Contributor/Reviewer / Privacy Requirements, Coding
VA Privacy Associate (TBD) / Contributor/Reviewer
Vendor Privacy Associate (TBD) / Contributor/Reviewer
Suzanne Gonzales-Webb / Contributor/Reviewer / RBAC, Security
6.0 Project Assumptions and Constraints
6.1 Project Assumptions are:
Acceptance of the RBAC Security and Privacy document between HL7 SIG Groups and Committees
6.2 Project Constraints are:
RBAC Security and Privacy document should be limited to HL7 Organization, this is an internal document, but conceptually can be used outside of HL7 with our permission.
7.0 Project Risks
7.1 Project Risks
Risk Factor Description / Probability of Occurrence (H/M/L) / Severity of Impact (H/M/L) / Risk Strategy / Mitigation Plan / Contingency Action / Anticipated Start – End Date /Describe the risk factor / Describe the strategy to remove or reduce/mitigate the risk. / Describe the action to be taken if the risk materializes. / Start when?
End when?
Non-adherence / L / H / Notification to committees of importance of security and privacy awareness, its support and adherence across the board, to mitigate possible security risks. / Meet w/individual, committees and groups that do not adhere, listen to concerns, update as necessary / Start date: 01/01/20087
End date:
09/30/08
8.0 Preliminary Project Schedule
A project schedule is to be developed to identify and manage all project related activities utilizing the Project Team’s tool of choice (e.g., MS Project, Word, or Excel). When developing the project schedule, ensure that all activities in all project phases are identified.
8.1 Project Schedule
Phase, Major Deliverable, Activity or Milestone / Responsible / Start Date / End DateProject Initiation
1. / Initial Phase – Document Delivery / M. Davis / 01/01/078
2. / Phase II – Ballot / M. Davis / 09/30/20087
3. / Phase III – Adherence (Adoption) / M. Davis / 01/01/098
4. / Phase V – Ongoing Process improvement, training and education / M. Davis
9.0 Inter-Project Dependencies
Inputs Required
Document the deliverables that are required from other areas or projects.
Area or Predecessor Project / Deliverables Needed as Input / Date RequiredInitial / HL7 RBAC Role Engineering Process, Permission Catalog and other HL7 RBAC related documentation / delivered
Initial / HITSP and other SDO documentation
Outputs to be supplied
Document the deliverables this project needs to supply to other areas or projects.
Area or Successor Project / Deliverables Supplied to Successor / Date RequiredHL7 Security & Privacy / Updated documentation: HL7 RBAC Security and Privacy Update (Draft, Final)
HL7 Security & Privacy / Ballot Documentation
10.0 Project Plan Acceptance/ Approvals
The following approvals indicate acceptance of the project plan.
Date / Status / Change Approved / Approval Body / Reference to Decision11.0 Appendices
11.1 Appendix A – Client Engagement
11.1.1 Project Plan
This Project Plan identifies the project’s deliverables, timing, and scope. It also includes specific reference to the project’s governance and project benefits.
Customer Commitments
We need your commitment to the following through your continued support and championing of this initiative throughout HL7;
· The current scope outlined in the plan will be observed, and that changes to scope will be managed through the appropriate change control processes established jointly by the project and steering teams,
· The issues escalation and resolution processes established jointly by the project team and the steering team will be followed by all members,
· Agreement on project governance roles with clear delineation of accountabilities between the project team and your role in steering direction of the initiative,
· Business requirements, recommendations and agreed solutions,
· Provide access to required information and resources that may be outside the formal assignment to the initiative,
· Project schedule and resource plan (people and funding),
· Agreement to the appropriate project objectives and performance indicators for measurement of project success, and
· Establishment of the appropriate accountability for jointly creating and signing project acceptance documents.
11.2 Appendix B – Project Controls
11.2.1 Project schedule (high level work plan)
A detailed project schedule identifying the prime, start and finish and durations of project deliverables will be developed and managed throughout the life of the project. This plan will be available to all project team members. The plan will include any assumptions used to estimate the project effort and approach. Status and variance on each identified activity will form the basis of status reporting by the assigned resource.
11.2.2 Project status reporting
Project status will be provided; the regularity of the reporting will be determined by the requirements of Responsible Party and the project type.
11.2.3 Project change management
All change requests will formally documented and managed through the Change Management processes and approvals.
As change requests are submitted, they will be assigned for assessment and impacts, after which it will be determined if the change request is approved or not. Changes to the scope, schedule, budget, resources, and risk of the project caused by an approved change request will be documented, logged and communicated to the project team and Steering Team. Rejected change requests will be returned to the originator with the rationale for rejecting the change request.
11.2.4 Project Issue Management
All issues identified that may impact the successful outcome of this project must be submitted immediately to the Project Leader / Manager. All issues will be formally documented and logged in a project issue log that will be managed throughout the project lifecycle. The Project Leader / Manager will review these to determine the potential project impacts and whether the issue will be escalated for resolution. As issues are identified, they will be assigned to the appropriate individual or group for resolution in the requested specified timeframe.
As issues are resolved, they will be closed. Before the project can be formally closed, all open issues must be addressed and resolved.
Identify in what form issues are to be reported, where and for how long they will be stored, and who will have what access to them.
Stds_20080109_SW_22.6_HL7 Project Plan - RBAC Security and Privacy Update v1.1.doc 4
Note: This document contains Privileged and Confidential information