Optum Practice Management & Physician EMR Defect Process Standard Operating Procedure

(1)

Optum Practice Management &

Physician EMR Defect Process

Standard Operating Procedure

Optum

70 Royal Little Drive Providence, RI 02904

(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 1.01 6/12/12 Betty- Fay Jacques Corrected typos

Review and Approval

Version Approved

Date

Approved Approver’s Name Approver’s Title/Role

(3)

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

2.1.1 Contacting Support



All defects should be submitted to the CareTracker Support team via ToDo. One 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.

2.1.2 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

(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

Organization:



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

(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 theDefect 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.

Optum Practice Management & Physician EMR Defect Process Standard Operating Procedure