Project Plan

Project Information

Project: TAPAS
Project Time-frame: January, 2005- March 31, 2006
Internal Release Number: $Revision: 1.5 $ $State: Exp $
Attached worksheets:
Related Documents:


Summary of Project

The TAPAS | e-MS project proposes to extend the North Shore Mobile Network project design to include electronic patient medical summaries. For the medical summaries, a Clinical Document Architecture (CDA) that adopts the e-MS standard will be used to represent clinical documents in a structured and standard way.

The project will deliver a component-based, open source practice system to include a patient summary; this builds upon the communication system of the Virtual Practice Network Server, to support patient alerts that enhance decision making and communication between family physicians while on call within a single call group. The project will consist of the addition of several components, including a CDA document standardized on the e-MS standard. Other additional modules include:

  • Medical Summary Module
  • Enhanced Communication Module
  • Consultation Module
  • Prescription Module
  • PDA Conduits for the medical summary
  • Clinical Decision Support through the proposed integration of EGADSS
  • Additional Modules

All modules will be available through the Virtual Practice Network Server. All software, source code and releasable documentation will be made available under open source licenses.


For more information see the Project proposal.

Summary of Methodology

Development  Approach
The project will be developed and implemented in phased approach, Rational Unified Process (RUP), as described below:

1.       Inception Phase

Depending on project needs, the phase may include developing a business plan and project plan that outline approach to project, including resources, scope, timing and costs of the project.

2.       Elaboration Phase

This phase focuses on the user experience through user modeling and interface planning and the technical software architecture. The team designs and codes the software architecture in order to address risks and build the essential pieces of the application.

3.       Construction Phase

The focus at this stage is on iterative design, implementing, and testing of the remaining functionality. Deployment plans are finalized. Each iteration continues to produce a working version of the application, increasing functionality and quality until reaching the agreed to scope.

4.       Deployment Phase

This phase is where clients perform final acceptance testing, marketing campaigns are run, and the developed system goes Live. This phase includes monitoring and evaluating the live site, and fine-tuning for optimum performance and results.


Team Organization
The development team will consist of:
  • Conduit Developer:
    • Coding, development and testing of system components according to business and functional system requirements to provide secure and robust data transfer between the virtual practice server and the users PDAs
    • Assure the user authentication and secure transmission of data between PDA and server is robust and consistent with PIA
    • Assures that data transmission and synchronization maintains integrity of data and system
    • Delivers development and user documentation for all Conduit software as appropriate
  • Clinical Informatics Lead: 
    • Has authority over and responsibility for the project; approves or disapproves continuance of the project
    • Secures executive commitment, approvals, and funding
    • Approves changes to the scope
    • Approves project deliverables
    • Provides  clinical input and expertise
    • Defines broad scope and objectives and communicates Stakeholders
  • PDA Developer:
    • Coding and development of system components according to business and functional system requirements that reside on the PDA
    • Assure that data is stored securely on the PDA
    • Delivers development and user documentation for all applications and components as appropriate

  • Programmers / Developers:
    • Coding of system components according to business and functional system requirements for components required on the server.
    • Testing of system components in Development and Testing environment
    • Document all aspects of source and configuration files
  • Project Manager:
    • Consults on and assists with the project management process for the project
    • Develops project-related documentation
    • Ensures that team members are completing assigned tasks in a timely manner and that deliverables are on time
    • Submit regular Status Reports to project stakeholders
    • Escalates ssues and changes )
    • Communicates with the project team and stakeholders
  • Technical Architect / Lead:
    • Provide system or technical development and architectural, based on a good understanding of functional and systems requirements
    • Defines the software development process and methodology
    • Plan, schedule, and coordinate activities related to system development projects
    • To work with the Clinical Informatics Leadr and Project Manager to develop a reasonable project plan
  • User Interface Designer / Developer:
    • Developing a consistent user experience for the TAPAS modules
    • Responsible for maintaining Developers Guide for Consistent Users Interface
  • User Technical Support:
    • Support the user group in installing appropriate hardware (wireless access points with appropriate security)
    • Use of configuration station to set-up PDA
    • Ensure proper wireless synchronization between PDAs and Production Server
    • Document all user procedures in a User Guide document

An Implementation Team will implement the system and develop business processes to manage and sustain the system after implementation.

An Evaluation Team will conduct an Impact Assessment of the North Shore Mobile Network project, including the tools developed in the TAPAS | e-MS project.


Collaboration Tools
We plan to use the following tools at some points in the duration of the project:
  • SourceForge website for TAPAS
  • Project mailing lists
  • Issue tracking system
  • Version control system
  • Task tracking system
Change Control
  • Requests for requirements changes will be discussed in mailing lists and tracked in the issue tracker
  • The project will review requested changes and authorize work on them as appropriate
  • After the feature complete milestone, no new features will be added to this release.
  • After the code complete milestone, no entirely new product source code will be added to this release.
  • All source code commit log messages must refer to a specific issue ID, after the feature complete milestone.
Updating the Plan
The project plan will be updated as needed throughout the project. It will be placed under version control. Any change to the plan be communicated to the development team through the project mailing list. Minor changes to the plan will be made internally with the development team and will be tracked and managed by the Project Manager.
 
Major development issues / changes in timelines and features will be brought back to the stakeholders for further discussion.

Deliverables in this Project



A high-level timeline is below.
Phase Timelines Release Description of Deliverables
Elaboration Jan 1- March 31, 2005 Paperchild
  • Establishment of Team
  • Documents:
    • Project Proposal
    • Project Charter
    • Letter of Agreement
    • Draft of Privacy Impact Assessment
    • QA Plan
Construction Phase 1 April 1- June 31, 2005 Strawman
  • Documents:
    • Software Requirements Specification
    • Security Specification
    • Use Cases
    • Design document
    • Implementation Plan
  • Develop database design document
  • Develop server infrastructure, including server business logic components
  • Develop client user interface components
  • Develop PDA conduit security model, implementation of security and encryption
  • Develop PDA database, design and implement file structure and develop cache manager
  • Develop PDA application, develop user interface components and implement security and encryption
Construction Phase 2 July 1- September 30, 2005 Woodwoman
  • Further develop server infrastructure, including components
  • Develop PDA conduit
  • Further develop PDA applications, complete testing
  • Integrate server with EGADSS through CDA Messaging
Construction Phase 3 October 1 - December 31, 2005 Ironcat
  • Perform systems testing
  • Perform usability testing and evaluation
  • Do implementation
  • Deliver refined implementation
Deployment / Transitioning January 1 - March 31, 2006 Diamonddog
  • Refine documenation and code
  • Report and address bugs / fixes
  • Develop further user interface enhancements
  • Develop user education information (guided tour)
  • Deliver installation and deployment packaging
  • Perform Evaluation
  • Do and deliver Evaluation Report


Risk Management


The project risks are identified below.

Risk Impact Likelihood Mitigation Strategy
Security and Privacy - There are significant security issues in using PDAs for clinical data that will need to be addressed High - The physicians will be using PDAs to access various operational and clinical information. There is a possibility that a PDA is lost.  Unauthorized access may occur. Low – The server is being built with robust technologies to ensure that information is secure and unauthorized access is prohibited.
  • Several have already been addressed by PalmSource in the current release of their OS.
  • Issues such as proper authentication will need to be addressed as will adequate user training.
  • Notification of lost PDAs will result in immediate denial of access for that PDA to current server data.
  • All clinical data on the PDA will be encrypted.
  • Access to all PDA applications will be restricted by password authentication.
  • PDA syncing to the server will use a form of two factor authentication: the user password and the PDA itself.
  • The PDA will be known to the server, once initialized, and will only allow access for a single physician account.
Clinical use of the summary tool - A strategy will need to be developed to promote adoption of tools by physicians, including addressing the amount of time for entering e-MS data by physicians in their practice. Medium - Insufficient uptake and adoption of the tool by physicians could result in ineffective utilization and dependability of the system. High – Given the workload family physicians, the impact on workflow and time required to enter data may be significant.
  • The roll out of this tool is planned to complement the change management workshops with the NSMobile groups (this would also be the case as this tool is rolled out to other physician groups)
  • Education around which patients would be the high impact patients to manage in the system will illustrate clinical benefits to the users while decreasing amount of work.  i.e. The patients  who are complex, have multiple referrals, and multiple visits to the hospital will be targeted for inclusion in the system first as better information about those patients will have an significant impact on the shared care delievery.
  • User interfaces will be designed with physicians to ensure that they support efficient workflows. The workload can be reduced while still providing a significant impact by encouraging physicians to focus on their most active and acute patients and build up their summaries over time. It is expected that significant impact would be seen if the physicians simply targeted patient groups with multiple chronic illnesses, diagnoses of Cancer, etc. Populating the database from their current electronic information (i.e. the billing systems) will also aid the adoption
  • Adding tools that leverage the e-MS data – such as adding an automatic consultation letter generation tools and clinical decision support for patients would also promote use of the system
  • Additional support and training of office staff to aid in the input of baseline data will encourage use.
  • Understanding that the adoption of the e-MS as a standard within BC will further encourage physicians to use and maintain patient data in the system, as they can see that the data could be migrated to a full EMR in the future, should the decide to use one
Time Constraints – This project has a defined end date: March 31, 2006, as determined by the Primary Care Transition Funds. High - Significant delays. High – The collaboration of four large organizations (UBC, VCH, VIHA, and MoHS) may result in significant delays.
  • Transparent process to ensure that stakeholders understand the nature of the project
  • Leveraging of existing open source tools
  • Strong project management
  • Regular electronic communication
  • Timely response from e-MS Steering Committee members and the user groups will be key



Project Planning Dependencies

  • Project Resourcing
This project does compete with other EGADSS-related projects for resources so and we have determined how many hours each person can actually dedicate to this project.
  • Impact of Version Maintenance
This is the first release and we will not plan the next release. However, the team will be expected to maintain a related project (Virtual Practice Network Server) and we predict that team members will spend an average of 10% of their time maintaining this system.
  • Project Dependencies
This project is dependent upon the sucess of the e-MS project and the North Shore Mobile Network project.
  • Project Interdependencies
The North Shore Mobile Network project depends on this project for the implementation and evaluation of their project. The VCH PC IT Strategy is looking to this project for lessons learnt.
  • Other Project Dependencies
None identified to date.
Company Proprietary
Copyright © 2003-2004 Jason Robbins. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.
0