Design and implementation of a comprehensive outpatient results manager

From Clinfowiki
Jump to: navigation, search

Test results are poorly managed by physicians. Poon and colleagues report on their implementation of a computerized Results Manager system that not only alerts physicians to test results but also assists them in the performance of the appropriate actions that should follow. Justification for the development of the system was prior research documenting poor patient safety and satisfaction outcomes when diagnostic test results were not attended to in a timely manner. 36% of clinicians do not routinely inform patients of their results (“no news is good news”) and only 26% of primary physicians have systems to assure abnormal test follow-up. Furthermore, 30% of office-based diagnosis-related malpractice cases are caused by this problem. Poon describes the development of a system to “prioritize, review and act upon streams of test results data.”


The setting of system development was Partners Healthcare in Boston which has a computerized CDR (Clinical Data Repository), results viewer, and LMR (Longitudinal Medical Record). Prior to development, passive notification of results required physicians to repeatedly check for the return of their ordered tests. The new system included active notification when results arrived.

Stakeholder meetings convened for determination of design principles determined system requirements including: highlighting results to the ordering physician that needed urgent attention, presenting the context of previous results, allowing clinicians to “acknowledge and act” on results, providing for clinical decision support, developing “test-ticklers”, generating patient result letters, allowing for result records to be “closed” while having fail-safe mechanisms when results were not acknowledged, and supporting workflow so that ancillary staff could use the system on behalf of physicians, An iterative development process for the user interface using mockups assured that communication continued between developers and clinicians.

The knowledge base component of the system included a “guidelines and alert” box for suggested courses of action including suggestions for repeat testing reminders as well as optional text for a patient results letter based on the degree of the specific test abnormalities. Software architecture used a clinical event monitor to process all test results and a rules engine to put the proper tests results into a results queue for the clinicians. The pilot phase of the project was completed with 20 clinicians in 2 clinics and a randomized clinical trial across a larger clinic population was planned.


The authors comment on three challenges faced in system development. Without ACPOE (ambulatory CPOE) identification of who ordered a test was not trivial but was surmounted with knowledge of the local workflows. Also the knowledge base had to be managed because of the changing nature of medical knowledge. Finally they note issues of completeness in getting all categories of test results to flow through the enterprise-wide database. While present, some of the results were not coded (an example being “nodule on a chest radiograph”).

The authors do not comment on what was likely to be the biggest future challenge: widespread user acceptance of a disruptive new technology. While laudable that the design phases involved key stakeholders, many an innovative computer system has fallen by the wayside when exposed to the harsh light of day-to-day user workflows. This system will ask more of the clinician user than the present, albeit sub par, paper systems. Hopefully, subsequent reports by the authors will determine if the worthy goals of patient safety and satisfaction were enough to ensure success.