Sunday, February 21, 2010

EHR Safety

Now is a good time to discuss EMR/EHR safety. The HIT Policy Committee Certification/Adoption Workgroup will be holding a public meeting on HIT Safety on February 25. An impressive group of experts has been assembled to present testimony on this important issue. Much of the literature on EHR safety to date suggests that electronic record systems are safer than a paper-based approach. Yet a few dissenting articles point to the potential for new types of errors and unintended consequences caused by EHRs. One article out of the University of Pennsylvania that stimulated a lot of conversation on the topic was published in JAMA in 2005. I will discuss some of the potential reasons that EHRs could cause errors below.

Software Design: This is probably the most apparent cause of errors. Many of us have had the experience of working with software that was released before all bugs were corrected. For many applications, this can be an annoyance, can delay work, and make us angry, but usually the result is not life-threatening. On the other hand, patient care software must be perfect out of the box. Even a single incidence of imperfect programming can be fatal. Software engineers for EHR applications have to be perfect.

Adults vs. Children. An area in health IT where system design is a recognized safety issue is pediatric care. This belies the truism that kids are not just small adults. Medication administration, blood product transfusion, and lab result interpretation are areas where the treatment of children and infants is different from that of adults. Medication doses are often quite different for pediatric patients compared to adults and need to be adjusted for body weight and organ function (dose adjusted based on lab results.) A criticism of many EHRs is that they don't account for these differences or at least make it difficult to address the pediatric requirements (drug alerts needs to be set up differently, a correct body weight must be available to the pharmacy system, the correct units of measure must be used.) Some pediatric hospitals have designed or contracted for pediatric-specific software.

Regression errors. We all know that EHR software is updated periodically (often an 18-24 month cycle.) When updates are installed, they are usually tested in a non-production environment to make sure they work as designed. Occasionally the updates can cause changes in function that result in errors that were not present in the earlier version of the software. This is more likely when disparate component systems are interfaced to create an enterprise EHR. Special attention must be given to such interfaces when upgrades in software are made. Regression testing to test for this type of error adds to the administrative overhead for system operators.

User Interface: I realize that the graphic user interface is really part of the system design but the emphasis here is on human factors engineering rather than computer science. Usability is the feature we are concerned with here. Consideration of human perception, workplace environment, and human-machine interactions are essential to the design of computer systems that will be used in the health care space. I addressed some common usability issues in a previous post (Nov. 22, 2009.) Critics of electronic medical record systems often cite poor usability as a factor that has contributed to the slow adoption of EHRs by clinicians. Representative examples are: some systems make it easy to click the wrong radio buttons; the need to scroll excessively; having to click through multiple pages to complete a task; inappropriate use of color; alert fatigue; and difficulty to easily undo unintended actions. A good case could also be made that inadequate attention paid to software usability explains some of the safety risks inherent in the use of EHRs. The aircraft/airline industry, on the other hand, has devoted extensive resources to human factors engineering in its successful effort to improve the safety of flight.

Standards: Standards are important to enable interoperability. Further, interoperability is necessary for the electronic transfer of patient specific health information from one provider to another. Information transfer is especially important to the safe care of patients during transitions of care. Many of the extant proprietary systems were not designed with information exchange in mind.

The ultimate goal is semantic interoperability-the ability to exchange information in a format that preserves its original meaning. This has been and will continue to be a problem in health IT. Often standards are written without published implementation guides to explain how to use them. Standards harmonization is not an easy task, is labor intensive, and it is often difficult to achieve solutions that are easy to implement.

Congress recognized the importance of the use of standards in health care IT in the composition of the ARRA legislation of 2009. The recent Interim Final Rule (IFR) on Certification and Standards is the most recent guide to the federal effort to influence standards in health IT. Whether the IFR fulfills the needs of the U.S. health care IT industry is a current topic of hot debate among the various stakeholders.

Clinical Decision Support: Decision support capabilities directly relate to patient safety. Alerts and warnings must be configured properly and implemented appropriately. Expert clinician input is essential. More complex decision support systems, especially those based on evidence-based guidelines are potentially problematic. The challenges become apparent when converting written guidelines to their electronic equivalents. Also, experience has shown that some clinical decision support systems may be sensitive to different geographic environments. Clinical outcomes when these systems are used are not totally predictable across different regions or cultures. Furthermore, many clinical decision support systems are necessarily customized to local policies, procedures, and clinical expertise of the clinicians so each implementation becomes unique.

Security, Privacy, and Infrastructure: These categories also have a significant impact on patient safety. A few examples will be discussed here.

First, let's start with patient identity. Positively identifying patients is essential to the provision of appropriate clinical care. Patient identification in the U.S. is hampered by lack of a nationwide patient identity system. This will become a more critical issue in the near future when cross-community exchange of patient information becomes a reality. Making sure the right records are associated with the right patients will become increasingly difficult as the number of patients included on master patient indices grows. Complicating this issue is the growing threat of medical identity theft.

Clinical IT systems, like other computer systems, are vulnerable to malware, malicious employees, and even cyber-terrorism. Risk assessment and risk mitigation will need to become more robust in the health care IT industry. Larger organizations with specialized IT teams are generally more capable of dealing with these threats than small clinician practices that function without such sophistication.

A final area that has not received adequate attention is data integrity. We need to be sure that data entered into systems is not inadvertently or intentionally changed inappropriately. More widespread use of technical safeguards to assure data integrity will be needed to protect critical clinical information systems. I expect that future iterations of the IFR will include requirements for digital signatures or similar technologies and non-repudiation of origin for producers of clinical data.

Above, I have discussed some topics that I think are important for the safe use of IT in health care environments. It will be interesting to listen to the testimony before the policy committee workgroup on Thursday to learn what their take is on EHR/EMR safety.

Tuesday, February 16, 2010

Some thoughts on the IFR and NPRM published in January by ONC

Now that I have time to review the NPRM for Meaningful Use and the IFR for Standards and Certifications, I have developed several personal comments that are listed below.

1. One of the objectives of the ARRA sections on health care was to encourage clinician adoption of electronic medical records. Congress decided not to provide up-front funds to assist clinicians purchase and install systems. Rather, a method was developed to provide rewards for adoption and meaningful use of systems once they are being used. In my opinion, this was a flawed approach. The cost just to purchase an EMR is $40,000-$50,000 per clinician. The costs for annual maintenance and upgrades are not included. Most small practices are not staffed to handle maintenance of the software and infrastructure needed for the critical availability service needed in medical practice. The level of funding set aside for even the earliest adopters is not as large an incentive as it might seem at first glance.

2. The requirements for meaningful use are also problematic at multiple levels. My opinion is that those most likely to meet the demands of meaningful use are the clinicians and hospitals that have already adopted EMRs/EHRs rather than new adopters. The amount of time it takes to make a system selection, develop an implementation plan, change processes, perform the actual installation, and complete training aligns poorly for new adopters with the tight time schedules required by ARRA to realize the maximal incentives. Even those who are already using electronic records are going to be challenged to make the changes to their systems that will assure compliance with meaningful use requirements and achieve maximum incentive payment.

The certification program requirements have not even been released yet although some hospitals would need to start meaningful use of certified systems in the U.S. fiscal year starting in October 2010, only eight months from now. The infrastructure for the new requirements for certification of systems does not exist. This is extremely worrisome considering that the whole foundation of meaningful use is based on the use of certified systems. I do not think that it will be easy to develop criteria for certification of modules and self-developed systems used at many sites that represent some of the currently most advanced users.

Meaningful use reporting requirements are bloated measures, many of which do not have current electronic versions. I have great difficulty finding value to patients or the general public engendered in many of the types of reports required. I think administrators have gone way overboard in developing this area of meaningful use. As a clinician, I would be interested in utilizing measures that actually resulted in improved health care outcomes. Over emphasis on process measures just adds to the ever-increasing administrative overhead clinicians face. I must ask, why would a clinician spend the large amount of money need to install an EMR and then not use it? Failure to use an installed system would assume that clinicians were not convinced of the benefits of EMRs, especially increased patient safety and improved quality of care. Most current systems are hard pressed to provide the numerators and denominators required even for the stage 1 reporting requirements. The challenge is even larger for clinicians who practice in a number of facilities that may use different systems. Furthermore, the infrastructure needed for electronic reporting for the most part does not exist. Moreover, CMS is not prepared to receive electronically many of the measures now being proposed. I think there will have to be a whole new department at the federal level just devoted to collecting reports and making sure each system is meeting all the requirements to qualify for federal incentive payments.

The plan for the three phase implementation of meaningful use requirements is another major barrier to EMR adoption. This effectively guarantees at least every two year upgrades in software, needs for new training, and perhaps needs for new hardware that will not be welcomed by clinicians struggling falling revenues, increasing costs, and nearly impossible demands on time available in their daily lives.

3. There have been many industry-wide comments on the lack of specificity of published selected standards. One area of hot contention is the requirement to be able to process both CCD and CCR documents. Others have commented extensively on lack of clarity regarding the important information transmission standards. Finally, there have been many comments indicating that the selected privacy and security standards do not meet the needs of the health care industry.

Final Thoughts
I would have hoped for a plan that would have been more effective at encouraging new adoptions of EMRs. I would have wished for a concentration on standards that encourage true interoperability, especially of summary information, for a start. My final wish would have been for a very substantial commitment to development of the infrastructure for health information exchange. The state grants for health information exchange announced last week by ONC are barely a start for this important new resource.