High Priority Practices

Download Guide

Download the PDF guide to access the checklist of recommended practices for self assessment and a supporting worksheet to identify action steps to achieve those recommended practices.

The High Priority Practices SAFER Guide identifies “high risk” and “high priority” recommended safety practices intended to optimize the safety and safe use of EHRs. It broadly addresses the EHR safety concerns discussed in greater detail in the other eight SAFER Guides. Assembling a multi-disciplinary safety team is recommended to complete this guide, as a team will be best equipped to identify which EHR-related safety practices should be addressed first and which of the other SAFER Guides to turn to next.

The potential benefits of EHRs may not be fully maximized unless the people responsible for their implementation, maintenance, and use are prepared for (and manage) the new challenges and risks they create.1-6 These new risks are both “social” (involving people, leadership, workflow, and policies) and “technical” (involving EHR hardware and software and system-to-system interfaces, configurations, upgrades, and maintenance). This guide is designed to help the people responsible for EHR safety in each specific complex “sociotechnical” healthcare organization focus on the most important safety challenges and risks introduced by EHRs.

Completing the self-assessment in the High Priority Practices SAFER Guide requires the engagement of people both within and outside the organization (such as EHR technology developers and diagnostic services providers). Because this guide is designed to help organizations prioritize EHR-related safety concerns, clinician leadership in the organization should be engaged to assess whether and how any particular recommended practice affects the organization’s ability to deliver safe, high quality care. Collaboration between clinicians and staff members while completing the self-assessment in this guide will enable an accurate snapshot of the organization’s EHR status (in terms of safety) and, even more importantly, should lead to a consensus about the organization’s future path to optimize EHR-related safety and quality: setting priorities among the recommended practices not yet addressed, ensuring a plan is in place to maintain recommended practices already in place, dedicating the required resources to make necessary improvements, and working together to mitigate the highest priority safety risks introduced by the EHR.

1

Data and application configurations are backed up and hardware systems are redundant.8-10

More About This Practice

Rationale:

Hardware and software failures are inevitable. Without redundant backup hardware, delays in restoring system operation can affect business continuity. Without data backups, key clinical and administrative information can be lost.

Examples:

  • Mission-critical hardware systems (e.g., database servers, network routers, connections to the Internet) are duplicated.
  • Data are encrypted and backed up frequently, and transferred to an off-site storage location at least weekly.
  • System backups are tested (e.g., restored to the test environment) on a monthly basis.

See the Contingency Planning Guide for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, Health IT support staff

2

EHR downtime and reactivation policies and procedures are complete, available, and reviewed regularly.11

More About This Practice

Rationale:

Failure to prepare for the inevitability of EHR downtimes greatly increases the potential for errors in patient care during these difficult times.

Examples:

  • Policies describe:
    • When a “downtime” should be called (including when the EHR is functionally unavailable [e.g., very slow response time]),
    • Who will be in charge during the downtime,
    • How everyone will be notified, and
    • Who is responsible for entering data collected during the downtime.
  • Hospital personnel are trained (and tested annually) in these procedures.
  • The organization regularly conducts tabletop downtime and reactivation simulations or “drills.”

See the Contingency Planning Guide for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, Health IT support staff

3

Allergies, problem list entries, and diagnostic test results (including interpretations of those results, such as “normal” and “high”), are entered/stored using standard, coded data elements in the EHR.7,12-21

More About This Practice

Rationale:

Free text data cannot be used by clinical decision support logic22 to check for data entry errors or notify clinicians about important new information.

Examples:

  • RxNorm is used for coding medications and NDF-RT for medication classes.
  • SNOMED-CT is used for coding allergens, reactions, and severity.
  • SNOMED-CT, ICD-10, or ICD-9 is used for coding clinical problems and diagnoses.
  • LOINC and SNOMED-CT are used for coding clinical laboratory results.
  • Abnormal laboratory results are coded as such.

See the Computerized Provider Order Entry with Decision Support and Test Results Reporting and Follow-Up Guides for related recommended practices

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer

4

Evidence-based order sets and charting templates are available for common clinical conditions, procedures, and services.7, 23

More About This Practice

Rationale:

Requiring clinicians to enter individual orders for routine clinical practices increases risk of overlooking one or more items. Allowing individual clinicians to create order sets runs the risk of institutionalizing poor practice.

Examples:

  • Clinical content is developed or modified based on evidence through consensus by experts, relying, where available, on nationally recognized, consensus-based clinical decision support (CDS) recommendations. See AHRQ’s Clinical Decision Support Initiative.
  • Institute for Safe Medication Practices (ISMP) order set guidelines24 are used to create order sets.
  • Order sets exist for the 10 most common clinical conditions (e.g., management of chest pain), procedures (e.g., insulin administration and monitoring), and clinical services (e.g., admission to labor and delivery).

See the Computerized Provider Order Entry with Decision Support Guide for related recommended practices

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff

5

Interactive clinical decision support features and functions (e.g., interruptive warnings, passive suggestions, or info buttons) are available and functioning.25-30

More About This Practice

Rationale:

Interactive clinical decision support interventions help reduce the risks associated with ordering inappropriate, contraindicated, and non-therapeutic doses (i.e., under or overdoses), and provide just-in-time clinical knowledge to clinicians.

Examples:

  • Each practice identifies a minimum number of highly specific CDS features and functions and monitors their availability and use.
  • Appropriate CDS features and functions include:
    • Alerts for abnormal laboratory test results.5
    • Tiered drug-drug interaction checks.26
    • Drug-allergy interaction checks.31
    • “Reverse allergy” checking occurs when a new allergen is entered for a patient.
    • Drug-food interaction support.
    • Drug-condition interaction checks (e.g., Accutane or tetracycline prescribed for a pregnant woman).
    • Drug-patient age interaction checks (e.g., medications contraindicated in the elderly).
    • Drug dosing support for maximum (dose, daily, and lifetime), minimum, renal,32 weight-based, and age-appropriateness.

See the Computerized Provider Order Entry with Decision Support Guide for related recommended practices

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff

6

Hardware and software modifications and system-system interfaces are tested (pre- and post-go-live) to ensure data are not lost or incorrectly entered, displayed, or transmitted within or between EHR system components.33-36

More About This Practice

Rationale:

Failure to test new or modified hardware and software functions along with system-system interfaces, both pre- and post-go-live, increases the risk of inadvertent errors and patient harm. Routine changes can result in unexpected side-effects leading to incomplete or unreliable functionality.

Examples:

  • Hardware and software should be tested both pre- and post-go-live. Include tests using clearly named “test” patients (e.g., ZZtest345 with patient ID 999999999) in the “live” environment.
  • High-priority clinical processes should be simulated using real clinicians.
  • Use the Leapfrog Group’s “Evaluation Tool for Computerized Physician Order Entry” (or some similar automated tool) to assess point-of-care CDS intervention completeness and reliability on a regular basis.33
  • Applications and system-system interfaces are tested to ensure that data are neither lost nor incorrectly entered, displayed, or transmitted.
  • Interfaces (e.g., HL-7) capable of sending, receiving, acknowledging, and cancelling orders and results exist and are tested between ADT – Laboratory, -Pharmacy, and -Radiology; and CPOE – Pharmacy, -Laboratory, and -Radiology.
  • Error logs are regularly inspected and errors fixed.

See the System Configuration, System Interfaces, and Test Results Reporting and Follow-Up Guides for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff

7

Clinical knowledge, rules, and logic embedded in the EHR are reviewed and addressed regularly and whenever changes are made in related systems.30, 37-40

More About This Practice

Rationale:

Medical knowledge is constantly evolving. Failure to review and update clinical content can result in outdated practices continuing long after they should be discontinued or updated.

Examples:

  • Clinical content (e.g., order sets, default values, charting templates, patient education materials, and health maintenance reminders) are reviewed at least bi-annually or as needed (e.g., following user feedback, changes in clinical practice standards, or manufacturer alert) against recent evidence and best practices.

See the Computerized Provider Order Entry with Decision Support Guide for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, Health IT support staff

8

Processes and procedures ensure accurate patient identification at each step in the clinical workflow.

More About This Practice

Rationale:

Wrong patient charting is one of the more common safety problems in EHRs and can result in both data integrity and data confidentiality issues when protected health information is disclosed in the wrong chart and is missing from the right chart. Accurate and consistent patient identification is one of the most important patient safety measures in an EHRenabled healthcare system.

Examples:

  • Information required to facilitate positive patient ID is visible on all screens and printouts and includes: Last name, first name, date of birth (with calculated age in age-appropriate units), gender, medical record number, in-patient location (or home address), recent photograph (recommended), and responsible physician (optional).
  • The master patient index employs a probabilistic matching algorithm that uses patient’s first and last names, date of birth, gender, and zip code or telephone number or social security number.41
  • System generates a pop-up alert when a user attempts to create a record for a new patient or looks up an existing patient with the same first and last name as an existing patient.
  • Before allowing the user to change the current patient (and display data for another patient), the system checks that all entered data have been saved (i.e., signed).42

See the Patient Identification Guide for related recommended practices.

Suggested Sources of Input:

EHR developer, Health IT support staff

9

Information required to accurately identify the patient is clearly displayed on screens and printouts.42,43

More About This Practice

Rationale:

If clinicians cannot clearly identify the patient they are working on, they are at increased risk of making EHR entries in the wrong record or relying on information on the wrong patient, resulting in patient care and treatment errors, which are among the most common types of errors in the modern EHR-enabled healthcare system.

Examples:

  • Information required for patient ID includes:
    • Last name
    • First name
    • Date of birth (with calculated age)
    • Gender
    • Medical record number
    • In-patient location (or home address)
    • Recent photograph (optional)
    • Responsible physician (e.g., attending, PCP, or admitting).
  • The duplicate patient ID rate (number of patient records with the same first name, last name, and date of birth in the EHR database) is monitored.

See the Computerized Provider Order Entry with Decision Support and Patient Identification Guides for related recommended practices.

Suggested Sources of Input:

EHR developer, Health IT support staff

10

The human-computer interface is easy to use and designed to ensure that required information is visible, readable, and understandable.43-46

More About This Practice

Rationale:

Clinicians are constantly under time pressure. User interfaces that are difficult to see, comprehend, and use significantly increase the risk of error and patient harm.

Examples:

  • Visible: columns are wide enough to view critical data.45
  • Readable: appropriate font sizes and contrast are used.
  • Understandable: only standardized abbreviations are used; the most recent orders and results are clearly marked.43
  • Consistent: similar functions have similar labels, different functions have different labels.
  • When possible, items that are related, or have similar functions, are grouped and displayed together rather than alphabetically.
  • System response time is adequate (e.g., mean under 3 seconds; max under 10 seconds).
  • User input data fields are large enough to enter required information, and selection options are clearly defined and easy to select.

See the System Configuration Guide for related recommended practices.

Suggested Sources of Input:

EHR developer, Health IT support staff

11

The status of orders can be tracked in the system.7

More About This Practice

Rationale:

Errors often occur when users assume that orders entered into the computer will be done as specified. To facilitate closed loop communication and tracking of tasks and orders, the EHR should provide users with information regarding their status.

Examples:

  • Users are notified of key actions (or inactions) relating to their orders, such as when ordered medications get discontinued (manually or automatically), antibiotic renewals are not processed, and when orders placed at later times of the day will not be acted upon till the next day.
  • Users are able to track the status of orders (e.g., specimen collected, specimen received, resulted).
  • There is clear distinction (e.g., different font or color) between newly entered and copied data.45

See the Computerized Provider Order Entry with Decision Support and Test Results Reporting and Followup Guides for related recommended practices.

Suggested Sources of Input:

EHR developer, Health IT support staff

12

Clinicians are able to override computer-generated clinical interventions when they deem necessary.47,48

More About This Practice

Rationale:

Computers cannot practice medicine. Disallowing clinician overrides of computer-generated interventions implies that computers have access to more accurate data and greater medical knowledge and expertise than clinicians. This is rarely true.

Examples:

Hard stop alerts (i.e., the user must take an action before proceeding) are used only for the most egregious potential errors. Hard stop alert overrides are closely monitored and reviewed often.47

The alert override rate (i.e., the number of point-of-care alerts that clinicians override divided by the total number of point-of-care alerts generated) is monitored, and alerts with high override rates are reviewed.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff

13

The EHR is used for ordering medications, diagnostic tests, and procedures.7

More About This Practice

Rationale:

Partial EHR use means that clinicians must look in two separate places to find the most recent orders and increases the potential to miss or delay filling critical orders. Hybrid systems, part electronic and part paper, are particularly hazardous.53

Examples:

  • The CPOE rate (i.e., the number of orders electronically entered by clinicians divided by the total number of orders entered) is monitored.
  • The percentage of verbal or paper orders that are entered by ancillary personnel is less than 10 percent.
  • Free text and “miscellaneous” orders are discouraged by providing appropriate supports.
  • Policies and procedures are in place that clearly identify and manage hazards associated with ordering that continues to occur outside of the EHR.

See the Computerized Provider Order Entry with Decision Support and Test Results Reporting and Followup Guides for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, Health IT support staff, Diagnostic services, Pharmacy

14

Knowledgeable people are available to train, test, and provide continuous support for clinical EHR users.49

More About This Practice

Rationale:

Clinicians cannot use EHRs safely if they have not been trained and do not have access to assistance when needed. EHRs are complex tools. In order to maximize patient safety, clinicians must not be expected to "learn the basics on the job."

Examples:

  • All clinicians receive training appropriate to their expected use of the EHR. An assessment is made of the need for such specialized training beyond system-wide, generic training.
  • Trainers have advanced EHR and/or informatics training.
  • Trainers are available before and after go-live, and provide ongoing support for users during EHR optimization.49
  • All clinicians are trained and tested on basic EHR and CPOE operations before being issued login credentials.
  • The clinician training rate (i.e., the number of clinicians trained to use the EHR who have passed a basic competency test divided by the total number of clinicians with EHR user privileges) is monitored.
  • When any category of clinician users of EHRs requests training, especially when they also indicate that they are not adequately trained to safely do their jobs, such training is promptly provided. Organizations have processes to identify training opportunities that would optimize the safe use of EHRs.

See the Organizational Responsibilities Guide for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, Health IT support staff

15

Pre-defined orders have been established for common medications and diagnostic (laboratory/radiology) testing.50

More About This Practice

Rationale:

Unnecessary clinical practice variation should be minimized. Forcing clinicians to enter specific values that are then matched to a list of allowable values or to select from a set of possible values increases variability and can result in errors.

Examples:

  • Complete medication order sentences exist for the most commonly ordered medications, laboratory tests, and radiology studies.51

See the Computerized Provider Order Entry with Decision Support Guide for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, Health IT support staff

16

Key EHR safety metrics related to the practice/organization are monitored.52

More About This Practice

Rationale:

Measurement and monitoring of key performance indicators is essential for improvements in safety.

Examples:

  • EHR uptime rate
    Minutes the EHR was available to clinicians divided by number of minutes in the reporting period.52
  • System response time
    Mean time to display a recent CBC result on a test patient, measured every minute of every day in the reporting period.
  • Serious EHR-related adverse events
    A list of reported EHR-related adverse events (whether they resulted in patient harm or not, including any reported breaches of patient confidentiality).
  • Potential wrong patient error rate
    Requests to “change” orders that result in cancellation of first order and creation of an order for the same item on a different patient by the same user.

See the Organizational Responsibilities and System Configuration Guides for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff

17

EHR-related patient safety hazards are reported to all responsible parties, and steps are taken to address them.

More About This Practice

Rationale:

Ensuring that EHR-related patient safety hazards are systematically identified, reported, and addressed is essential to improving the safety of EHRs.

Examples:

  • The organization clearly identifies through policies and procedures how to address reports of EHR safety hazards.
  • The organization ensures that reports of hazards and adverse events are reported, as appropriate, to EHR developers as well as senior leadership and boards.
  • The organization has a relationship with a patient safety organization experienced in investigating and addressing EHR-related patient safety incidents.
  • The total number of EHR-related software errors (i.e., bugs) reported is monitored.
  • The serious EHR error fix rate (i.e., the number of errors with potential for causing direct patient harm fixed within 3 months divided by the total number of errors  reported) is monitored.

See the Organizational Responsibilities Guide for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff

18

Activities to optimize the safety and safe use of EHRs include clinician engagement.

More About This Practice

Rationale:

Unless clinicians are included in decisions that affect their use of the EHR, they may not understand or accept changes, which increases risks. Clinicians should be engaged in identifying opportunities for the EHR to support safe and effective clinical use.

Examples:

  • Representatives from the following groups are involved in decision making about EHR safety: clinicians, administrators, patients, IT/informatics, board of directors and CEO, and quality and legal staff.

See the Organizational Responsibilities Guide for related recommended practices.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff, Diagnostic services, Pharmacy

{@Wednesday, February 26, 2014@}
{@Tuesday, February 25, 2014@}