The Challenges of Improving EHR Designs for Patient Safety

by Jerome Carter on June 8, 2015 · 0 comments

Patient safety is one of the main driving forces behind calls for better EHR systems and, as a result, EHR design quirks and flaws are receiving more attention.   Thomas Payne has provided a very insightful analysis of EHR safety issues in a recent BMJ Quality & Safety commentary (1). As part of the commentary he states:

The difficult question is how to make these improvements. In part, the answer is that we get better by gathering data and learning from them.

The national conversation concerning the need for improvements in EHR systems at some point has to get down to the brass tacks – the programming code and algorithms that make up an EHR system. Determining the code and algorithms required to answer safety concerns is a hard problem.   Yes, more data about the types of problems that exist is absolutely essential; however, identifying problems and creating solutions are vastly different things. Clinical software design is a complex endeavor, and this notion is not given sufficient attention in the conversation on EHR improvements.

The impetus for Payne’s commentary is an article by Schiff and colleagues (2) in which they study CPOE errors.   The authors report the following objectives and results of their study.

Objectives
The objectives of this study are to (a) analyse medication error reports where CPOE was reported as a ‘contributing cause’ and (b) develop ‘use cases’ based on these reports to test vulnerability of current CPOE systems to these errors.

Results
Between 2003 and 2010, 1.04 million medication errors were reported to MEDMARX, of which 63?040 were reported as CPOE related. A review of 10060 CPOE-related cases was used to derive 101 codes describing what went wrong, 67 codes describing reasons why errors occurred, 73 codes describing potential prevention strategies and 21 codes describing recurring error scenarios. Ability to enter these erroneous order scenarios was tested on 13 CPOE systems at 16 sites. Overall, 298 (79.5%) of the erroneous orders were able to be entered including 100 (28.0%) being ‘easily’ placed, another 101 (28.3%) with only minor workarounds and no warnings.

The study period ran from 2003 until 2010, mostly prior to MU and its certification requirements. Why so little progress in CPOE design?   Some would say that the cause is callous vendors interested more in money than product quality while others might cite poor development practices. I disagree with both groups. I think no one really knows how to write sophisticated clinical software because it is, and always has been, more difficult than it has seemed.

Lack of process thinking during product specification
Clinical software designs traditionally overemphasize data capture and data storage—user interfaces, usability, patient safety, and clinical algorithms are add-ons modeled after data are specified.   And, like most add-ons, they are not as robust as they might be if they were part of the initial design thinking.

Consider the differences in two software products.   The first begins as a data model, with tables assigned in an RDBMS.   Next, queries are formulated to add, sort, update and retrieve data. Finally, a user interface is added.   When the product hits the market, clinicians begin demanding that a standard feature such as the problem list have the ability to link to specific information sources or to be able to notify one or more clinicians when any test results pertinent to a problem are returned.

These “smart” functions would be add-ons to the software’s original design and might require changes from the interface all the way to the database schema.   Now, imagine a second system where the initial design is based on the tasks performed by clinicians. Using the task profile, an information model identifying data elements and semantic constraints is created. Finally, a data store suited to the tasks identified set up.   Which system is more likely to have an underlying architecture and data model that permits new task-related features to be added after the product is in the hands of users?

Just-in-time information for tasks
Another finding from the Schiff article that Payne mentions speaks to a second reason that clinical software design is not keeping up with user needs—information is not sufficiently mapped to tasks. Payne states:

For example, one could prescribe pioglitazone, a member of a class of medications for diabetes known to cause fluid retention and thus potentially exacerbate heart failure, for patients with heart failure, though one would hope such an order would at least be flagged for review.

How might one fix the pioglitazone ordering problem?   One approach would be to create a complex ontology that relates diseases, medications and labs in a computable form—not an easy job. However, even if such a robust ontology existed, there would still be a need for a workflow support that acted as an infrastructure for matching control-flow of steps to information requirements and data accesses. In the same way that databases organize data and ontologies organize knowledge, workflow technology organizes tasks and the information required to support those tasks.

Tasks are algorithms
Clinical work is fundamentally algorithmic (no, I am not talking about practice guidelines). Diagnostic workups, treatment plans, medication selection, and other aspects of clinical work are algorithms that exist primarily in the heads of clinicians. Every clinical activity is a series of steps with a specific, intended objective.   The essential conflict between EHR systems and users is that users are performing algorithms and EHR systems clumsily interrupt them with either requests for data or by providing barely-in-context information.

Algorithms are mathematical and can be studied mathematically. No, not with calculus or biostatistics, but certainly with sets, graphs, functions and relations. Workflow technology allows clinical work to be portrayed in algorithmic form.   Clinical work models and workflow technology must gain a seat at the table in the national discussion on improving EHR systems.

Every call for improved EHR systems insists that more research is needed, but none seem to include the mathematical aspects of clinical work in the list of research to be done. Clinical process models are needed, not just for user interactions with computers, but also as a means of helping to design algorithms that test for complex task dependencies such as the pioglitazone example.

Lets get software engineers out of the basement and to the table
Enrico Coiera provides a fitting introduction to the third action item required for EHR improvement. On his blog he writes (3):

Our proposal is a simple one. We suggest you set aside 10% of the E-health budget to train the next generation of e-health designers, builders, and users. Use the funds to resource training programs at the Masters level for future e-health policy leaders, as well as system designers, builders and implementers. Let us provide incentives to include e-health in health profession training both at primary degree and for continuing education.

EHR wishes are made into products by software engineers. This means that all desired usability, safety, and CDS features must be implemented by software engineers. Until there are software engineers who are knowledgeable about deep aspects of clinical care, clinical work models, clinical algorithms, workflow technology, and information models, EHR systems will not improve.   So where does one find such engineers?

When the goal of EHR design was replication of the paper chart in electronic form, training engineers to create electronic charts was hard, but doable in a reasonable period of time—given access to a few clinicians and paper chart examples. However, we are now beyond the point where electronic charts are deemed okay as every national report on EHR issues has made abundantly clear. The problem, as Payne acknowledges, is rendering into code the features being demanded.   We need better training and deeper interactions between software engineers, clinicians, workflow specialists, human factors specialists, and others if requirements and feature lists are going to become real world products.   Let’s give software engineers (those who are actively involved in designing and writing code and not their upper-level managers) direct representation at all meetings discussing clinical software improvement. Nothing can happen without them.

Creating safer EHR systems requires a rethinking of not only what clinical software is and does, but also a willingness to rethink how we train and interact with those designated to turn software dreams into reality.

  1. Payne TH. Electronic health records and patient safety: should we be discouraged? BMJ Qual Saf. 2015 Apr;24(4):239-40.
  2. Schiff GD, Amato MG, Eguale T, et al. Computerised physician order entry-related medication errors: analysis of reported errors and vulnerability testing of current systems. BMJ Qual Saf 2015;24:4 264-271.
  3. Coiera E. A modest e-health proposal to government. com/blog/. 2015. Available at: http://coiera.com/2015/05/12/a-modest-e-health-proposal-to-government/. Accessed June 5, 2015.
Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: