Healthcare Software

EMR Usability at the Root of Many Medical Errors

The FDA has called out to healthcare providers to report problems with EMR software in response to concerns over patient safety. It is reported that there are 260 examples of “malfunction” in healthcare IT software in the past 2 years, but what is at the root of these problems? Is it really the software at fault or is it something else? The FDA letter refers to 3 examples of failure in software that put human lives at risk.

These examples are:

1. Emergency room software returned the lab test results of the wrong patient. The software was being used to prescribe medications.
2. Operating room software locking up during surgery leading to incomplete surgical procedure data and necessitating manual data entry from memory after the procedure.
3. Radiology workstations suffering application performance problems (because of a misprocessing of long input strings) leading to patients having to retake X-rays.

While these examples given are genuine software implementation errors, many of the others entered into the FDA’s MAUDE Adverse Effects database are not. In fact, after examination, a lot of them are software usability problems as reported in this article. It is interesting to read some of these issues in their raw form and see how usability issues affect the performance of healthcare providers.

Some of the more succinct examples (with report numbers in parentheses) are:

1. CERNER MILLENIUM CPOE, POWERCHART (MW5014371). The displays, formats, layouts, and interfaces of the cpoe tools at this institution contain elevated degrees of user unfriendliness. This toxic effect on the user is manifested by, to mention a few, more than 20 electronic silos in which orders are stored and extensive wordiness using descriptors that are highly irrelevant to the task of the care of pts with critical illness. This manifests itself in several ways, one of which is the ordering of duplicate medications and treatments, some of which get to the pt. These should be reported to pharmacopoeia data bases but often are not. This pt was being infused both total parenteral nutrition and a concentrated dextrose solution, the combined rate of which and cumulative dose caused pulmonary edema.
2. CERNER MILLENIUM CPOE (MW5014300). Electronic order entered in to the cpoe contrivance ordering the holding of sliding scale insulin at night time. The order was delivered to an electronic file on the nurse's module. This order was not seen by the nurse. Insulin was given. Hypoglycemia with severe symptoms ensued. Orders are delivered without notification to electronic files of the nurse's module. There is a design flaw consisting of failures of the contrivance to link free text orders to specific treatments and medications and to notify health care professionals of new or stat orders. User error is invariably extended as cause to cover-up the design defect facilitating such error.
3. SIEMENS MEDICAL SOLUTIONS, SIEMENS PHARMACY SOFTWARE (1691454). The pharmacy medication alert system was updated and the alerts were inadvertently turned off. The alerts were down for approximately 7 days.
4. GE HEALTHCARE, PACS SERVER (3004526608-2010-00006). The customer reported that the technician entered the date of birth (b) (6) instead of the study date of (b) (6), making the report appear older than what it was. The radiologist was viewing the images for pic line placement and the comparison film did not have the line present. When the film did not have the line present, the radiologist assumed the line had been removed, not verifying proper placement. The baby, who was pre-mature, died. The risk manager stated that the line was inserted too far, which contributed to the death, though not certain it caused the death. The risk manager also stated that they consider the incident a "work process error" and not a malfunction of pacs.
5. PHILIPS STENTOR PACS (MW5015614). Pt with chief complaint of shortness of breath. Cta of chest, abdomen, pelvis was ordered. Report sent was that of a mri of the spine, despite the ordered test being listed on the report as "cta chest abdomen pelvis". Misidentification is the general category of defect though there is commingling of data divergent with the listed test. It is unk by this reporter if this was part of a recursive process affecting innumerable pts.

It is relatively simple to get access to the rest of the entries. This page details how to best use the MAUDE database for online search.

Hospital Processes are Highly Collaborative and Asynchronous

The Problem. Hospitals and clinics contain a large number of autonomous individuals all working to deliver healthcare. There is opportunity for collaboration, but work almost always takes place between caregiver and patient. When a difficult case presents itself, multiple staff members may participate to gain experience, but for common, routine cases work can normally be done without discussion.

For routine cases such as diagnostic tests, communication between team members is normally not necessary. Each member can be given a list of the patients scheduled for that day and each can work through his or her workflow in the most efficient manner.

If there is no way for a team member to check on the progress of another, however, the caregiver will need to physically ask his colleague if he is done his part of the workflow. If not, he will need to keep checking until the case is ready.

For Example. Consider the example of the workflow of a cardiac exercise test:

• Patients are scheduled by a clerk who creates the appointments
• Patients present themselves to the front desk and are directed to an examination room
• A technician finds the patient record associated with the patient who is in the room and completes the test
• A doctor pulls the cases for which the test is complete, interprets the results and completes a report for each
• An assistant forwards the results of the test to the patient’s family doctor and anyone else involved in the case

Here, each team member is working through his or her own work log. When an employee is finished a case, it then becomes someone else’s work, which then gets passed onto someone else until the case is complete. If the system is not able to identify the progress of the case for each of the interested participants, participants will not know when to contribute.

Solution. Traditionally, a piece of paper has been used to synchronize team members. If you had the piece of paper, it meant you were the one who had to work. However, since it would take a while before the paper arrived on your desk, getting the paper implied that you had to do a lot of work, and as soon as possible. It is much more efficient to let people work when they want and do as much work as they want.

For this reason, healthcare software should support a workflow process in which each member is empowered to have autonomy over tasks, but is able to get a sense of how many tasks need to be completed.

Each user may have drastically different work patterns. In the example above, clerks and technicians work on a daily schedule whereas the physicians may work on a weekly or an “every couple of days” schedule. Physicians are always getting interrupted and distracted, and so their schedules are usually more erratic.

An employee who is not able to do all of her work at once, for example, can do as much as she has time for and leave the rest for later. Even if doctors can only interpret results twice a week, for example, this does not block an assistant from forwarding the test results for the cases that are already interpreted. The assistant can do other work and then receive a notification from the system when the doctor has completed more cases.

Communication between healthcare professionals is largely asynchronous. This asynchronous user behavior needs be understood by developers so that the resulting application maps to the existing workflow process.

Are EMRs Medical Devices? A brief ITAC / MEDEC Conference Summary

I attended a 1-day ITAC / MEDEC conference in Toronto yesterday on Patient Management Software being classified by Health Canada as a medical device and the implications of it.

The core of the conference dealt with the notice from Health Canada: Classification of Medical Devices Class I or Class II patient management software

ITAC before the meeting released this interpretation of it which they extracted following a teleconference with Health Canada.

The conference itself mainly surrounded the implications of the notice and some of the things to expect from it, namely the challenges of:

• Knowing if your software needs to get approved
• What classification does it belong to
• The process of getting software certified
• Having your organization be audited
• What to do after your certificate expires

The notice mainly had the same implications of an FDA audit, which makes sense, since the regulation incorporates the post-market approval process of the USFDA.

One of the more interesting portions was the consumer panel where the 3 speakers gave their opinion on the notice. Paraphrasing, they said:

• The doctors (given by the CTO of the CMA, Bill Pascal)
  • We want more consistent standards and more support for patient management systems.
• The government (given by the Executive Director, Corporate Information and Technology Branch of Saskatchewan Health, Neil Gardner)
  • We want to approach the problem from a risk management perspective.
• The hospital (given by the CIO of the UHN, Lydia Lee)
  • We need to work with the vendor community to create better software and adopt their processes to improve the quality of our own in-house development.

They all spoke in favour of the notice saying that it will help make health software better and improve patient safety, but whether or not this is true, is debatable.

Database Designs Must be Flexible as Workplace Requirements are Likely to Change

The Problem. In a clinical setting such as a hospital, workplace processes and requirements are continually changing. New information may need to be collected from patients for legal or medical reasons, new treatment rules may be implemented and discharge policies could change without notice. IT resources, however, are scarce and healthcare organizations may not have the resources to purchase new software or systems to accommodate these changes. When developing and deploying software, you need to keep these constraints in mind and architect systems that are able to handle changing requirements.

With the right data model, you can ease these challenges and allow for continual updates as requirements are refined and features are added.

For Example. If you are asked to create a data model that provides for the storage of patient risk factors, you would naturally create a table to store these values. If additional risk factors were added, the table would be extended or new tables would be created to accommodate them.

Let’s say you need to store the following hypothetical risk factors:

• current smoker (true/false)
• date of bypass surgery (date)
• number of family members with diabetes (number)

With the approach discussed above, the resulting structure would be something similar to the figure below:

If you were asked to add a fourth risk factor, you might create an additional column in the table, and so forth. This approach, however, requires that all programmed models be updated to reflect the newly updated table. This can require significant development re-work, and often these changes end up being undone at a later stage, resulting in even more re-work.

Clearly risk factors, and any other set of data fields that may need to be modified frequently, require a more adaptable data model.

Solution. As an alternative to the simple data model listed above, create a set of tables to hold a more generic structure of key/value data. Such a structure would look like the model shown below.

This data model stores data as:

• QuestionField: the question text
• AnswerType: the type of answer expected
• QuestionAnswer: all possible answers to the questions
• AnswerValue: a mapping from the patient record to the actual answer values

With this model, it now becomes programmatically possible to add fields to an interface of risk factors without having to modify the database schema. With the right data model in place, you will be better positioned to refine the software and handle new requirements as they arise.