Optum Practice Management & Physician EMR Defect Process Standard Operating Procedure

Transcription

1 ptum Practice Management & Physician EMR Defect Process Standard perating Procedure ptum 70 Royal Little Drive Providence, RI Copyright ptum. All rights reserved.

2 Document Information Author(s) Betty- Fay Jacques Release Date 6/6/12 Date Last Updated Version 1.01 Document Control Version Date Changed Completed By Description of Changes 1.0 5/31/12 Betty- Fay Jacques First Draft /12/12 Betty- Fay Jacques Corrected typos Review and Approval Version Approved Date Approved Approver s Name Approver s Title/Role 0.00 mm/dd/yyyy ptum_defect_process_sp_v1 01.doc 2 of 6

3 Table of Contents 1 Introduction Purpose Scope Procedures Reporting a Defect Contacting Support Entering into Microsoft Team Foundation Server Defect Review and Prioritization Escalating a Defect Work Item Deliverables... 6 ptum_defect_process_sp_v1 01.doc 3 of 6

4 1 Introduction 1.1 Purpose The purpose of this document is to describe the procedures and protocols that are in place to manage defects and defect backlog for CareTracker. 1.2 Scope This applies to all CareTracker products. 2 Procedures 2.1 Reporting a Defect Contacting Support All defects should be submitted to the CareTracker Support team via ToDo. ne ToDo should be logged for each issue being encountered. Each ToDo logged to report a defect should contain a detailed description of the issue being experienced, specifying the module and application where the issue is occurring as well as the patient example(s) involved. The ToDo should contain detailed steps on how the issue may be replicated, as well as the desired/ expected behavior that is not happening. ToDos reporting issues should contain specifics on frequency/ rate at which issue is encountered as well as screen prints/ other documentation to support the issue being reported. They should also specify when the issue began, if it is being experienced by some/ all operators and some/ all workstations. Channel Partner clients should also specify if the issue impacts multiple client companies and if it can be re-created in a test company. ToDos will be returned to the requestor if sufficient details are not supplied, or the issue being reported cannot be replicated Entering into Microsoft Team Foundation Server The Support team will review each ToDo to determine if the issue is known and already reported. ToDos reporting known issues will be sent back to the original requestor advising the issue is known and will contain the ID of the work item logged for the issue to be resolved. In these cases, Support will update the work item in Team Foundation to include the reporting client and examples to ensure resolution delivery is possible once resolution is available. If the issue presented in the ToDo is not already known and logged, Support will review the ToDo documentation and examples to determine if issue exists, can be replicated and the ptum_defect_process_sp_v1 01.doc 4 of 6

5 Procedures potential cause. If a resolution is immediately available, it will be supplied via ToDo reply to the requestor. If the issue is reproducible and needs to be presented to Development for repair, it will be logged as a work item in Team Foundation with a severity level indicating the impact to the client. The work item will include all details necessary for Development investigation and repair. The ToDo will be transferred back to the requestor advising the issue has been logged for repair and will supply the work item ID and any work- around that may be available. 2.2 Defect Review and Prioritization CareTracker defects are reviewed weekly by the Defect Control Board. The Defect Control Board consists of members representing each of the below departments within the rganization: Customer Support Quality Assurance Implementation and Training Compliance Revenue Cycle Management Development Sales The board determines the level of impact based on the details available of each defect logged weekly. Those that are most critical are prioritized for fastest possible attention and repair. Non- critical issues are set with an initial priority for repair in a future Service Pack or Release. Priority level is based on a number of different criteria, including but not limited to: industry requirements, volume of clients impacted, impact on productivity, revenue and/or patient care and work- around availability. Logged work items are periodically reviewed for additional client reports and details once a priority is assigned. Priority is re-assessed based on additional client reports/ additional informational developments that pertain to a specific issue. Critical issues which disrupt a practice s ability to utilize CareTracker or provide patient care are submitted to Development for immediate repair. 2.3 Escalating a Defect Work Item When a defect needs to be escalated to the high- priority work list, there are several factors taken into consideration, including but not limited to: existing high priority work list items, industry requirements, volume of clients impacted, impact on revenue and work- around availability. Clients requesting that a work item be escalated should use the original ToDo where the issue was reported to submit the request. The request may be submitted to the Support Department via the Support Center in CareTracker, or to the dedicated Support Liaison (for Channel Partner clients) if preferred. Escalation requests require business justification/details that support the request for escalation. Number of records impacted, financial analysis, number of clients impacted and ptum_defect_process_sp_v1 01.doc 5 of 6

6 other relevant details which support the escalation request and allow the work item to be added to the high priority list appropriately. Escalation requests that are received by Support that do not contain the business justification details will be returned to the requestor. Requests to escalate will be reviewed by the Defect Control Board weekly and the requestor will be notified accordingly of any new status applied to the work item upon review. 3 Deliverables Defect Work- around When available, alternate workflow/ method suggestions are supplied by Support staff to help immediately alleviate the impact caused by the defect. Defect Resolution Defect resolution is communicated to the reporting operator via the original ToDo once Development has deployed the software changes that will resolve the issue. Defect Resolutions are deployed via one of the following events: Rapid Repair - A Rapid Repair is a patch, usually for a bug that has been deemed critical or severe, and requires immediate attention by all parties. A Rapid Repair will typically only include a single bug fix, or change, and will only affect the portion of CareTracker that is being corrected. It would be rare for a Rapid Repair to contain an actual enhancement request, but if an item is deemed critical enough, it may be deployed in this manner. Service Pack - A Service Pack release is a maintenance release that includes bug fixes, or on a limited basis enhancements that have been identified as critical, or high priority, and cannot wait until the next release. Service Pack releases currently occur monthly and include only those updates corrected and documented in the logged change request. Enhancement items released in a Service Pack would be fully documented in the release notes of the subsequent, Product Release. Enhancement Release Major releases include new features that have been determined to provide enhancements to our customers, our sales efforts or for supportability reasons. These releases typically occur three times per year. ptum_defect_process_sp_v1 01.doc 6 of 6