Comp8 unit9c lecture_slides

Editor's Notes

• #2: Welcome to Installation and Maintenance of Health IT Systems, Creating Fault Tolerant Systems, Backups, and Decommissioning, This is lecture c. This component, Installation and Maintenance of Health IT Systems covers fundamentals of selection, installation, and maintenance of typical Electronic Health Records (EHR) systems. This unit, Creating Fault Tolerant Systems, Backups, and Decommissioning, will discuss ensuring availability and resiliency through fault tolerance, data reliability through backup, and secure decommissioning of EHR systems
• #3: The objectives for this unit, Creating Fault-Tolerant Systems, Backups, and Decommissioning are to: Define availability, reliability, redundancy, and fault tolerance Explain areas and outline rules for implementing fault tolerant systems Perform risk assessment Follow best practice guidelines for common implementations Develop strategies for backup and restore of operating systems, applications, configuration settings, and databases and Decommission systems and data As healthcare organizations adopt new technology to improve their efficiency, their dependence on that technology increases exponentially. However, what happens to all of these critical applications if a failure were to occur? What about the integrity of the caregiver’s data in the event of a disaster? In lecture c, we will finalize our discussion and outline some backup strategies. And since we are on the subject of backing up, we will finish with some tips on archiving and decommissioning data and hardware.
• #4: Healthcare institutions must now cope with the need to retain vast and ever-increasing quantities of medical data for protracted periods of time to safeguard themselves and their patients. The average 100-bed hospital generates anywhere between 40,000 to 45,000 radiological examinations yearly, equating to approximately 12 Terabytes of space needed for storage of these documents alone. This figure doesn’t even count the vast amounts of data generated yearly from billing, staffing and administration, and other typical needs of a healthcare setting. The HIPAA , or Health Information Portability & Accountability Act, Security Rule establishes the requirement to keep exact backup copies of all healthcare data that can be retrieved in a timely manner to restore documentation, should data be corrupted or lost. Think of a backup as a first step – the real reason to make a backup is not the backup, but the restoration of what was lost.
• #5: Besides federal regulation such as HIPAA, state laws often describe retention requirements for health information. They may look at a fixed amount of time, or the age of the patient (especially for minors) or of the health record, time since discharge or death, or malpractice suit statute of limitations regulations. Let’s take a look at best practices for general backups. The copy of the information should be verified to ensure its correctness. A backup that cannot be restored is not a backup at all. Additionally, multiple copies, with a copy of the data at a location off-site geographically to protect it from natural disasters, fires, flooding, and such. The data must be easily retrievable so data can be restored in a timely fashion. The data must be encrypted for security, especially if stored off-site or transported. Note that RAID or other fault-tolerant systems (as discussed in lecture b) are NOT a substitute for backup. RAID does not protect against file deletion, or help in recovering older versions of the data. Backups can.
• #6: Another issue you need to consider when developing your backup strategy is how often and when you will complete your backups. Backups, which can sap network bandwidth and hinder access to resources should be conducted, whenever possible, in a manner that reduces performance issues during peak cycles. A ‘backup window’ is “… the time it takes to complete a given backup. This backup window is determined by both the amount of data that must be backed up and by the speed of the network infrastructure that handles the data.” In a small organization, backups can complete in a small window, outside of production hours. An off-hours backup is advantageous because you may assume no changes to the data will be made during the backup. Any change to a backup mid-stream may lead to an inconsistent (and therefore flawed and possibly useless) backup. However, as the amount of data increases, backups may extend into production hours, introducing that possibility and impacting system speed as well. Finally, many systems are expected to run 24/7, and have only production time in which to backup.
• #7: There are different types of backups which can be run, depending on your specific needs. Each has its advantages and disadvantages: Full backups save all files, and provide a convenient restore because all of the programs and data needed are in the same backup. The largest drawback to a full backup is the size of the backup and the time required. Retaining multiple versions of backup data can make the size requirements grow quickly. Incremental backup is faster because it saves only the copies of files which have changed since the last backup. For systems where a relatively few number of files change each day, this can save tremendously on storage. The drawback is that restoration requires access to multiple backups, increasing the time and effort for a restoration. Well-tended data libraries are recommended for incremental backups to allow easy identification of the proper backup from which to restore.
• #8: Differential backups reduce the restoration problems from the incremental backup. Now only two backups are needed: the last full backup, and the last differential. This works by copying all data that has changed since the last full backup. It does mean, however, that the size of a differential backup will grow over time, eventually nearly reaching the size of the full backup. Synthetic full backups are generated by merging a full backup with an incremental to allow for on-stop restoration. While it combines the speed of an incremental with the easy restore of a full, it does take some post-processing to merge the data. This increases the complexity of the backup, and the potential for error. If the majority of your data files change frequently, then full backups are likely the best option
• #9: Snapshots are a recommended backup method for systems that have no downtime or off-hours. This feature, often implemented in a platform specific environment, allows the data to be “frozen” so a backup is taken of guaranteed consistent data, no matter how long the backup takes. It does this by writing all changes to data in a temporary area during the snapshot, which is used transparently for all other system access. Then once the backup is complete, the data in the temporary area is merged back with the primary system. The biggest benefit of file system snapshots is that they allow backups on live data without disabling application access.
• #10: The most straightforward backup is to copy the data to an attached tape drive, optical drive, or other file storage system directly connected to the server. This is fine for small environments, but for multiple servers, tracking the storage media may be difficult. Having a single backup server that connects to other networked servers is the next step up. This allows for extensive configured tracking of backed-up data in the backup server, and scales well. Also, it allows flexibility in restoration – anything that is on the network may be given a copy of freshly restored data. At still larger scales, the Storage Area Network (or SAN) is a separate system of interfaces and connections between data servers. A SAN will provide bulk data storage for the network, and have provision for backup of that data on the same network, usually integrated by the storage vendor.
• #11: Backups will start on-site, but any media that are created should periodically be stored off-site. The media to use for a backup are available in several types. Tapes are historically the most robust, but also relatively slow and the media is expensive. Storing large amount of data on tapes can create a physical inventory problem. For several years, the capacity and cost of hard drives have greatly outdistanced that of tapes. Optical media is familiar and relatively inexpensive, and is readable for easy restoration without specialized equipment, as optical drives are standard equipment on most computers. They hold relatively little data though, and can be fragile. Their small space is attractive when considering physical size requirements of storage. Flash media is mentioned because of its ubiquity. USB memory sticks are available in fairly large capacity at increasingly attractive prices, and the media is robust. Their maximum capacity can mean difficulty scaling to very large data sizes. Backup to hard disk may sound oxymoronic, but because of advances in hard drive technology, huge amounts of data can be stored inexpensively and quickly. Because of their bulk and relative fragility, hard disks need careful physical storage. Finally, backup to network or cloud locations, while not technically media, depend on the network throughput to the backup site. Processes that continually run in the background, updating any changes to an off-site backup, are an ideal solution as long as the cost and network bandwidth are available to support it.
• #12: Database backup requires extra considerations. Before embarking on a backup strategy for your EHR databases, consult with your EHR vendor to ensure your backup strategy is compatible with your database infrastructure. They should have outlined best practices for your system. Often the database or application vendor will provide specialized tools or additional applications to backup.
• #13: Legacy systems are often maintained simply to reference historical data, sometimes at great cost to the organization. At some point, systems or applications past their prime, or datasets which must be retired, must be evaluated and dealt with in a manner that ensures that active data is properly retained and inactive data is archived or disposed of securely, consistent with the organizational needs. Here are some tips for identifying and decommissioning legacy systems: Complete a full data audit and identify the data you are collecting and retaining and note redundancies. Complete a full inventory of EHR systems and determine what kinds of data you collect and retain, and require. This is a complex task, since managing the many overlaps and redundancies will make it confusing as to which application is being used for which purpose. Determine who owns the data so you can work with them to resolve any compliance or archiving requirements. Identify which data is inactive and which data is still active. This is done through both using logs and conferring with data owners and stakeholders. Remember, archiving and retrieval of data, particularly in the healthcare arena, is a lifelong commitment. Be sure to plan adequately for archiving and tracking the data for compliance even once it’s off the servers.
• #14: Be sure your retention policies are well documented and are consistent with federal and state guidelines. Be sure to standardize on a single, well-navigable archival system. This makes locating archived data easier and faster. Develop a plan and a schedule for decommissioning. Be sure to notify your data owners and stakeholders of the event, what will happen to their data once the application is decommissioned, and any potential impacts or replacement applications brought online. Once the server or applications are decommissioned, ensure the integrity of any archived data. Remember, simply erasing data from decommissioned hardware using conventional means is not enough. Data erased in this fashion can be retrieved using simple utilities. Be sure to render storage media useless or ensure it has been erased according to industry standards.
• #15: This concludes Creating Fault-Tolerant Systems, Backups, and Decommissioning. Let’s take a quick moment to summarize the important points presented in this unit: Regulations require healthcare institutions to keep exact backup copies of all healthcare data. That data should be protected, encrypted and stored in multiple locations to protect it from foreseeable harm for the duration of its retention period. Backups often will occur during a limited timeframe, or backup window. As the amount of the data needing to be backed up increases, generally, so does the backup window. It is important to develop a backup strategy that minimizes the backup window while ensuring data integrity. Consider on versus off-site and full versus partial backups, as well as the type of media to use. However, always remember that any backup without a restore is useless – verification of stored data is critical to ensure availability. Lastly, decommissioning obsolete data or data storage devices require extra considerations to ensure that active data is properly retained, that inactive data is properly and safely discarded or archived and that regulatory compliance is maintained.
• #16: This concludes Creating Fault-Tolerant Systems, Backups, and Decommissioning. Let’s take a quick moment to summarize the important points presented in this unit: Regulations require healthcare institutions to keep exact backup copies of all healthcare data. That data should be protected, encrypted and stored in multiple locations to protect it from foreseeable harm for the duration of its retention period. Backups often will occur during a limited timeframe, or backup window. As the amount of the data needing to be backed up increases, generally, so does the backup window. It is important to develop a backup strategy that minimizes the backup window while ensuring data integrity. Consider on versus off-site and full versus partial backups, as well as the type of media to use. However, always remember that any backup without a restore is useless – verification of stored data is critical to ensure availability. Lastly, decommissioning obsolete data or data storage devices require extra considerations to ensure that active data is properly retained, that inactive data is properly and safely discarded or archived and that regulatory compliance is maintained.
• #17: No Audio. Ten seconds of silence.
• #18: No Audio.