From SHARP Project Wiki
Revision as of 21:04, 27 January 2012 by Admin (talk | contribs) (→‎Area 4: SHARPn Notes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Pan-SHARP Success Criteria

How should the success of a Pan-SHARP project be judged? Here we propose criteria for the success of the Pan-SHARP endeavor.

Phase 1 – Mercury proof-of-concept (SHARPFest July 2012 deliverable)
Construct a processing pipeline that is able to:
Take data from different underlying systems (SHARPn)
Translate it to a common representation (SHARPn)
Expose it via the SMART API (SMART)
Present it to the user for medication reconciliation (SHARPC)
Do so securely and maintaining provenance information (SHARPS)
Demonstrate effective collaboration among the SHARP programs
Phase 2 - Gemini (SHARPFest July 2013 deliverable)
Feature-complete code release
Proceed to lab User Experience (UX)/User Interface (UI) testing at UT-Houston
Proceed to clinical testing at a site TBD
Use of the code, in whole or part, by members of the Open Source community
Adoption of SHARPC UI/UX design for Medication Reconciliation in a different commercial product


Product Manager
Jorge Herskovic – SHARPc, UTH
Product Requirements Document, Software Requirement Specification, Testing, Overall technical management of Pan-SHARP Med Rec
Project Manager
Jessica Nadler – SHARPn, Deloitte
Integrated Project Plan, Facilitating dependencies, Support of ongoing communications

The Medication Reconciliation Opportunity

Justification: We believe that the driving clinical need is to prevent Adverse Drug Events (ADEs) and improper medication administration through the review and careful curating of medication lists.

Demo Use Case: To address the production of a reconciled medication list at the time of patient discharge. User Story for Mercury: An adult inpatient in an internal medicine service is ready for discharge. The resident needs to prepare a discharge summary and final orders for the patient to take home. The resident needs to review the medications the patient was taking upon admission to the hospital, understand the evolution of the patient throughout the hospital stay, review the patient’s problem list, and produce a new list of medications for the patient to take home. The resident runs a Med Rec Program that pulls information from the patient’s admission information and his inpatient medication history inside the hospital. The Med Rec Program compares the admission medication list with the last known medication list and uses the results of the comparison to propose a final medication list.

The resident then edits this medication list and produces a print-out, including precise and visually clear instructions to aid compliance, for the patient and a secure email for the patient’s Primary Care Provider (PCP).

User Story for Gemini: The Gemini iteration will enable alternate methods of input, such as entering information directly, or pulling data from prescription fulfillment repositories or devices directly. The user stories for Gemini will therefore be varied. For example,

  1. The patient was referred to the hospital with a referral note containing medication information.
    1. Optionally, the patient has supplemented or contradicted some of this information. In this case, the resident’s task is putting together this information with the new desired treatment to figure out the correct medication orders.
  2. The patient brings a bag containing medications from her medicine cabinet at home to the PCP’s office. The PCP wants to reconcile these with her own Active Medications list.
  3. Data from the patient’s wearable insulin pump is downloaded and reconciled with the original treatment plan by a diabetologist.
  4. The patient’s PCP receives a discharge summary from the hospital and must reconcile it with the medication list in his/her own Electronic Health Record (EHR).

Goals for Proposed Med Rec Process: Improved patient safety through fewer medication errors and fewer ADEs. The reconciliation process becomes faster and more accurate, making for more effective use of clinicians’ time.

Key factors For Med Rec Success: As complete and accurate a medication history as possible, an accurate and updated problem list, and a clear and unambiguous hand-off medication document to the patient.

Desirable factors For Med Rec Software: The end-user software should:

  • be discoverable, i.e., the user should require little or no training to use it
  • provide all relevant information and no more – accurate medication history [and problem history]
  • label medications with provenance information when available and pass the original text through to the user interface for presentation to the user if necessary and/or desirable
  • provide task-related cognitive cues (which do not violate the proximity-compatibility principle)
  • provide a high data to ink ratio, i.e., low/no decorative overhead (see the SMART Reynolds Risk Score for an example)
  • allow the user to be in control, i.e. every decision should be made by the clinician.
  • be resilient, i.e. degrade gracefully because data can be incorrect, misleading, contain typos or unfamiliar terms, units, etc., and the back-end should pass data through unadulterated if it does not recognize medications or information
  • have no impact on the integrity of the back-end system that is passing data to it; and
  • be predictable, i.e. given same two inputs, then it should produce the same output


Area 4: SHARPn Notes