Question

Describe the Fault Tolerance in EHR what protection does it provide and and how is it created

Answer 1

Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of (or one or more faults within) some of its components. The ability of maintaining functionality when portions of a system break down is referred to as graceful degradation.

Electronic Health Records (EHRs) and Electronic Medical Records (EMRs) are rapidly becoming common-place in the healthcare industry. Organizations such as the Certification Commission for Healthcare Information Technology (CCHIT) and regulations such as the Healthcare Insurance Portability and Accountability Act (HIPAA) mandate robust, interoperable healthcare information systems. As EHRs and EMRs are widely adopted, the need for robust platforms that ensure continuous availability and data integrity becomes paramount.

Electronic health records (EHRs) have been widely adopted over the past decade in both inpatient and outpatient settings. EHR systems are made up of the electronic patient "chart" and typically include functionality for computerized provider order entry (CPOE), laboratory and imaging reporting, and medical device interfaces. Ideally, the system creates a seamless, legible, comprehensive, and enduring record of a patient's medical history and treatment. However, the transition to this new way of recording and communicating medical information has also introduced new opportunities for error and other unanticipated consequences that can present safety risks.

EHR and EMR systems constitute a major financial investment for health care providers and therefore these applications tend to have a long lifecycle. Indeed, some have evolved from legacy application environments. Given the relatively short lifecycle of computer hardware, virtualization offers a viable and attractive solution that preserves providers’ investments in EHR and EMR software. Virtualization facilitates the extension of EHR and EMR application lifecycles by providing an operating environment which is independent of the underlying hardware platform. This hardware independent characteristic allows for simple hardware and capacity upgrades. Hardware independence, however, does not diminish the importance of the platform itself. To the contrary, virtualization by its nature increases the importance of server availability, reliability and performance, an aspect frequently overlooked in the rush to implement EMR software. Virtualization itself does provide a level of improved availability, which comes at a cost in terms of dollars, complexity and professional skill sets. Alone, virtualization software cannot be relied on for uptime assurance that EMR software commands.

In a review of EHR safety and usability, investigators found that the switch from paper records to EHRs led to decreases in medication errors, improved guideline adherence, and (after initial implementation) enhanced safety attitudes and job satisfaction among physicians. However, the investigators found a number of problems as well. These included usability issues, such as poor information display, complicated screen sequences and navigation, and mismatch between user workflow in the EHR and clinical workflow. The latter problems resulted in interruptions and distraction, which can contribute to medical error. Additional safety hazards included data entry errors created by the use of copy-forward, copy-and-paste, and electronic signatures, lack of clarity in sources and date of information presented, alert fatigue, and other usability problems that can contribute to error. Similar findings were reported in a review of nurses' experiences with EHR use, which highlighted the altered workflow and communication patterns created by the implementation of EHRs.

High availability clusters provide improved availability. Like virtualization HA, clustering adds cost, complexity, and management load. More important, clustering is failure recovery technology. It assumes downtime and is designed to recover as quickly as possible. During server failover and failback, EMR will be down. VMs cannot be migrated off a dead server. Data not committed to memory, i.e. in-flight data, will be lost. Finding issue root cause is difficult and generally not done.

One theme of the literature on EHR implementation is the emergence of unanticipated consequences. For example, a detailed study of types and rates of medication safety events before and after EHR implementation in two ICUs found that, while overall medication safety improved, new vulnerabilities emerged, including increases in wrong patient, wrong medication, or wrongly timed orders. One source of technology-induced error was overspecification of functions within the CPOE module. In the ICU study, the CPOE system required physicians to select the medication schedule, a function that nurses or pharmacists may be better prepared to do (and had historically done) in inpatient settings. Similarly, in a case study of electronic prescribing for patients with diabetes in a safety net clinic, investigators found overspecification to be a source of medication errors in both insulin ordering and insulin use. Specifically, when prescribers were forced by the CPOE system to select brand name insulin from a list of similar-looking brand names, they could inadvertently choose an incorrect type of insulin. The system configuration also presented barriers to pharmacist consultation on insulin selection, reducing opportunities for preventing or correcting prescription errors. Finally, prescribers were unable to use recommended universal medication scheduling practices for instructing patients when to take their diabetes medications, creating further potential for error by patients in self-administering their medications. Universal medication scheduling improves comprehension of prescriptions among patients with low health literacy and low English proficiency, and can thereby reduce mistakes in adherence to prescribed therapy.

A fault-tolerant system architecture utilizes duplicate components running in lockstep, multipath I/O and sophisticated monitoring tools which eliminate system interruptions in the event of hardware failure. There is no failover; the faulty components are automatically isolated in real-time and their redundant partners continue operating with no interruption, thus preserving business continuity. These are significant technological and operational differences from the failover and recovery, along with associated application downtime, which is characteristic of clusters. When integrated into a well-designed HIPAA Security Rule and ePHI compliant network environment with redundant paths, industry-standard fault tolerant systems with VMware, Hyper-V or RedHat Enterprise Linux provide continuous 24/7 access to EHRs and EMRs while protecting against loss and/or corruption of health data due to hardware or software failure. This approach offers the simplicity and reliability to implement a private cloud which ensures maximum uptime, maximum data integrity and maximum data protection for EHRs and EMRs.

Health IT and EHRs are here to stay. While new approaches to EHR and health IT design are likely to emerge, health care organizations need to ensure both the safety of their current technology and the safe use of that technology today. Several resources are available to assist health care organizations in this effort. The Office of the National Coordinator for Health Information Technology has produced the SAFER guides. These nine guides provide assessment checklists and structure for teams to assess and improve their systems in the following domains: high-priority practices, organizational responsibilities, contingency planning, system configuration, system interfaces, patient identification, CPOE with decision support, test results reporting and follow-up, and clinician communication. SAFER guides are designed for use in all types of health care settings.

Fault tolerance refers to the ability of a system (computer, network, cloud cluster, etc.) to continue operating without interruption when one or more of its components fail.

The objective of creating a fault-tolerant system is to prevent disruptions arising from a single point of failure, ensuring the high availability and business continuity of mission-critical applications or systems.
Fault-tolerant systems use backup components that automatically take the place of failed components, ensuring no loss of service. These include:

• Hardware systems that are backed up by identical or equivalent systems. For example, a server can be made fault tolerant by using an identical server running in parallel, with all operations mirrored to the backup server.
• Software systems that are backed up by other software instances. For example, a database with customer information can be continuously replicated to another machine. If the primary database goes down, operations can be automatically redirected to the second database.
• Power sources that are made fault tolerant using alternative sources. For example, many organizations have power generators that can take over in case main line electricity fails.

In similar fashion, any system or component which is a single point of failure can be made fault tolerant using redundancy.

Fault tolerance can play a role in a disaster recovery strategy. For example, fault-tolerant systems with backup components in the cloud can restore mission-critical systems quickly, even if a natural or human-induced disaster destroys on-premise IT infrastructure.