Working with HIT Systems

Working with HIT Systems
Unit 7 Protecting Privacy, Security, and Confidentiality in HIT Systems Unit 7: Protecting Privacy, Security, and Confidentiality in HIT Systems Unit 7 is designed to present an overview of the concepts of privacy, security, and confidentiality of protected health information (PHI) in relation to HIT systems. Threats to PHI frequently encountered in HIT environments such as password sharing, offsite access to EHRS, challenges of staff turn-over and student access, unauthorized access, etc., will be detailed. Students will be exposed to simulated breeches of privacy, security and confidentiality of PHI in lab exercises, asked to identify, and propose strategies to thwart these threats.

Health IT Workforce Curriculum Version 1.0/Fall 2010
Objectives By the end of this unit the student will be able to: Explain and illustrate privacy, security, and confidentiality in HIT settings. Identify common threats encountered when using HIT. Formulate strategies to minimize threats to privacy, security, and confidentiality in HIT systems. By the end of this unit, students should be able to explain what privacy, security and confidentiality mean in general, and how these concepts apply specifically to HIT systems. Students should be able to identify common threats encountered when using HIT systems, and be able to formulate strategies to minimize these threats. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Electronic Health Information Risks and Opportunities
Access to electronic vs. paper records Public apprehension around digitization of health information Success of HIT systems depends on ensuring patient privacy Security can facilitate patient-centered care The potential benefits of electronic health records, such as avoiding dangerous medical mistakes, reducing costs, and improving care, are clear. But the transition from paper records, locked away in providers’ offices, towards electronic records, accessible from any location on the network, presents many new challenging risks to patient privacy. Stop for a minute and consider whether you believe your personal health records are safer sitting on a computer connected to a network (such as a local area network in an office or even accessible over the Internet) or tucked away in a folder on the shelf in a clinician’s office. If you are like many people in this country, you have serious concerns about your health information being digitized, especially if that digital information will be shared outside of your provider’s office, or even potentially stolen by unscrupulous users on the network. Keep in mind that Meaningful Use requirements will dictate that this information be shared over computer networks to facilitate transactions between providers (such as the pharmacy and a physician), so the potential new risks are real. Fortunately, everyone recognizes the importance of assuring the privacy of patient information, and Meaningful Use requirements are very clear that the privacy and security of information in EHR systems must be ensured. As a Health IT professional, you should be as concerned about the confidentiality and integrity of patient health information as you are the functions and capabilities of HIT systems that will facilitate the transformation and modernization of health care in this country. Ensuring security and privacy in HIT systems and the health care processes that they support can admittedly be a difficult, tedious process, but this work is fundamental and critically important, and in fact dictated by law. The success of the growth of HIT will depend on the trust of everyone using these systems, which will be positively influenced to a great extent by a proven record of success protecting patient privacy. The truth is that technology has the potential to greatly improve the confidentiality of health information compared to paper-based systems, if implemented properly. Security controls in such systems can allow for very fine-tuned control of access to such information, and consequently can facilitate meeting specific privacy requests of patients that wouldn’t be possible with paper records. With these capabilities, patients can truly be in control of their own health information, which is a critical component required for transforming the healthcare system into one that is increasingly patient-centered. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Privacy, Confidentiality, Security Defined
Privacy: patient is in control Confidentiality: only authorized individuals are allowed access Security: controls/safeguards that ensure confidentiality Let’s first clarify what we mean by the terms privacy, security and confidentiality. With regard to HIT, when we talk about privacy, we are talking about the right patients have to control who can store, retrieve and share their health information. Confidentiality describes the practices a provider employs to protect the patient’s privacy rights, such as permitting only certain authorized individuals to access a patient’s record. Security refers to the specific safeguards or controls that are put in place to ensure the confidentiality of patient data. For example, security would include a technical safeguard that requires all individuals in the health care setting to log into a system using a unique account using credentials that are not shared with others, thus providing a mechanism through which confidentiality of the information can be enforced. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Security Management System Standards
ISO 27001 NIST HIPAA There are many different approaches that an organization can take to address privacy and security of the health information and systems under their control. Larger organizations likely already have in place information technology teams, IT security professionals, and compliance offices that may already have an established security management program, following guidelines established in formal security standards frameworks. Smaller organizations may rely on outsourced IT services with varying levels of security expertise. Others may rely on in-house IT expertise and a more ad-hoc approach to security management. There are many different standards that an organization can choose to use to help guide security planning. Two of the most commonly used sources are the International Organization for Standardization (or ISO) series of standards, and the National Institute of Standards (or NIST) security standards (particularly publication ). Other standard frameworks that are common apply to particular types of businesses or organizations, and may arise from regulation applicable to a particular business sector. The most important such example to health care organizations is the Health Insurance Portability and Accountability Act (or HIPAA). We will examine in some detail in this unit the guidelines outlined in the HIPAA Security Rule to help build our understanding of how to approach security management and the scope of security and privacy safeguards that should be considered to protect patient health information in HIT systems. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

HIPAA and PHI Health Insurance Portability and Accountability Act of 1996 Privacy Rule (effective 2003) Security Rule (effective 2005) HITECH Act of 2009 The Health Insurance Portability and Accountability Act (or HIPAA) was enacted by the U.S. Congress in Its goal was to protect health insurance coverage for citizens and their families after the loss of a job, and to facilitate the standardization of health care transactions between providers, health insurance plans, and employers (Administrative Simplification). These provisions specified a broad range of individually identifiable health information, or protected health information (PHI), that “covered entities” are obligated to protect. Covered entities include health plans, health care clearinghouses, and most health care providers (depending on the types of transactions that the provider engages in). The Privacy Rule, which became effective in 2003 for most covered entities, established regulations for the use and disclosure of PHI, which includes information stored in paper or electronic format, as well as any type of disclosure of this information, including phone calls, faxes and conversations. The Privacy Rule had a significant impact on the business operations of most health care organizations, but has been in force now for many years. As new HIT systems come into common use, such as EHR systems, these organizations will need to ensure that their privacy policies are updated to accommodate these new systems. This will be particularly true as Meaningful Use criteria encourage sharing of PHI between providers. The Security Rule, which required compliance in 2005 for most covered entities, compliments the Privacy Rule. It details specific security safeguards that are required for compliance, and is intended to provide guidance related to the handling of electronic PHI (ePHI). When the Security Rule became effective, many health care providers had only practice management and billing systems in place that contained ePHI. With the increasing implementations of additional HIT systems, more and more PHI is finding its way into electronic systems, so it is incumbent upon providers that they diligently evaluate the compliance of these systems with the HIPAA Security Rule. The HITECH Act, enacted as part of the American Recovery and Reinvestment Act of 2009, modified some of the HIPAA provisions. With regard to business associates of covered entities, it now compels these associates to adhere to the provisions of the Privacy and Security Rules, and requires that this expectation be included in any business associate agreements. The HITECH Act also includes new rules for the accounting of disclosures of PHI, specifically related to an organization’s use of an EHR. This is a sampling of the major regulations that impact the adoption of HIT systems. There are many other regulations, both federal and state, that govern the security of Health IT systems and IT systems generally. Understanding and meeting the requirements of these regulations is a difficult challenge, but of critical importance to health care organizations and providers. As a HIT professional, you ideally will find yourself in an organization that already has in place a compliance program for HIPAA and other regulations that impact the organization, and it will be important for you to ensure that all new HIT projects become part of the compliance program. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Types of Security Safeguards
Administrative Safeguards Physical Safeguards Technical Safeguards Let us delve into some of the details of the HIPAA Security Rule to learn more about the specific types of security safeguards that should be considered when implementing HIT systems. The HIPAA Security Rule groups its security standards into three categories—administrative safeguards, physical safeguards, and technical safeguards. Administrative safeguards are the administrative functions that should be implemented in order to ensure that security standards are met. These include designating responsibility for security management, adoption of policies and procedures, and privacy and security training for an organization’s staff. Physical safeguards are the controls put in place to protect electronic systems, hardware and the data stored there, from threats such as natural disasters and unauthorized intrusion. Technical safeguards are the automated controls used to protect electronic data and to control access. Examples include using authentication controls to ensure the identity of a person accessing an HIT system containing EPHI, as well as encryption standards for data stored in HIT systems and transferred between them. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Administrative Safeguards
Security Management Process Risk Analysis Risk Management Sanction Policy System Activity Review The HIPAA Security Rule defines administrative safeguards as, “administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information.” The number of safeguards included in this category comprises a majority of the HIPAA security requirements. Clearly effective administration of a security program is fundamental to all security efforts. Let’s look at each of these safeguards more carefully. The first standard, the Security Management Process, requires health care organizations to implement policies and procedures to “prevent, detect, contain and correct security violations.” An effective process of security management will include risk analysis, risk management, a sanction policy, and information system activity review. An organization will not be able to determine what safeguards they should implement if they don’t first carefully evaluate what their risks are. It wouldn’t make sense, for example, to implement a wonderful new expensive technology to prevent access to a system that may not in fact contain any sensitive information. After carefully evaluating what your risks are and how best to address them, you must then put in place a risk management plan to ensure that the adopted safeguards are properly implemented and followed. If members of the staff do not follow the risk management plan, you should have a sanction policy to deal with these violations. Finally, to discover these violations, as well as to detect attempts to circumvent security safeguards, you must actively review system activity (such as audit logs, access reports, network activity logs, and security incident reports). Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Assigned Security Responsibility Security officer The next safeguard is to ensure that an organization has designated someone who has responsibility for the security of all systems containing EPHI. This may seem obvious and unnecessary to include as a formal requirement, but when a security incident occurs (EPHI is breached), there is often finger pointing that occurs in an organization. Determining up-front who ultimately must take responsibility for security will help prevent finger-pointing after something bad happens. Although someone must be ultimately responsible for the organization’s security plan, this does not mean that that individual cannot delegate specific security responsibilities to others. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Workforce Security, Information Access Management Who can and who cannot have access Who determines who can have access and how Employee turnover Contractors User roles The third and fourth administrative safeguards, Workforce Security and Information Access Management, dictate that an organization must have policies and procedures in place that specify who is permitted to have access to EPHI and who isn’t, and to grant permissions or take them away appropriately. These policies and procedures should spell out exactly not only who should have access, but also how it is determined who should have access (for example, based on a detailed job description), as well as who should have the authority to determine who has access or not. An organization should have procedures in place to deal with employee turnover (or any other type of changing roles of staff or contractors), to ensure that access to EPHI is terminated when it is no longer appropriate for an individual to have it. The level of access to EPHI should be appropriate to the role. In other words, it should never be an “all or nothing” access. For example, a clerical position that handles appointment scheduling for patients is unlikely to need access to see a patient’s problem list or diagnoses, particularly for sensitive problems such as mental health issues or a diagnosis for HIV. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Security Awareness and Training Training Security reminders Log-in monitoring Password management The fifth safeguard, Security Awareness and Training, dictates that a health care organization must, “Implement a security awareness and training program for all members of its workforce (including management).” Many safeguards that are implemented to protect the security of systems containing EPHI require cooperation on the part of the organization’s workforce to be effective. For example, the use of authentication controls (in other words, usernames/passwords) is a very common security safeguard that allows for a system to uniquely identify users and to limit access based on that user’s role. This safeguard is completely defeated if users share their passwords with other users. Training of users thus is very important so that it is made clear why certain security safeguards must be followed, how to follow them, and what the sanctions are if they are not followed. Security awareness is also accomplished through safeguards such as security reminders ( s, pop-up messages, memos, etc., related to important security notifications employees should be aware of), log-in monitoring (reporting on failed log in attempts), and password management (policies and procedures to prevent sharing of passwords, how and when to change passwords, etc.). Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Security Incident Procedures Contingency Plan Data backup Disaster recovery Emergency operation plan The sixth administrative standard, Security Incident Procedures, dictates that covered entities must have policies and procedures in place to deal with security incidents. A security incident is an unauthorized attempt (successful or not) to access, use, disclose, modify, or destroy information in an information system, or to interfere with the operations of such a system. When these incidents happen, the organization must have procedures in place to appropriately respond to and report such incidents. A Contingency Plan should be in place for all organizations to proactively prepare for emergencies that might prevent access to EPHI, such as power outages, natural disasters, system failure, or any other disruption of critical business operations. The contingency plan should include policies and procedures for data backup, disaster recovery (how to get systems and data back online after a failure), and plans for emergency operation (how to conduct business while systems are down). These procedures should be tested regularly to ensure they will work if something bad does happen. It is also important to carefully analyze the criticality of all systems in order to prioritize the level of backup, disaster recovery, and emergency operation for each system. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Evaluation Business Associate Agreements The Evaluation standard emphasizes the importance of regularly evaluating the organization’s security program to ensure that EPHI is adequately protected. Finally, the Business Associate Contracts and Other Arrangements standard requires that any individual or organization that enters into an agreement with a covered entity must require that the business associate safeguard EPHI. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Physical Safeguards Facility Access Controls The HIPAA Security Rule defines Physical Safeguards as “physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environment hazards, and unauthorized intrusion.” Let’s take a look at these safeguards in more detail. It is important to limit physical access to systems that contain EPHI, as well as access to the facilities that house these systems. This must be done of course in a way that allows authorized access. Facility Access Controls are methods that could be used to control physical access, and may include controls such as door locks, electronic access control systems, alarms, private security service, video surveillance, and identification badges. The rationale used to determine who has access must be documented. This is an important point worth reiterating, as in fact the HIPAA regulations require that all security decisions be documented. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Physical Safeguards Workstation Use Workstation Security Device and Media Controls (e.g., media disposal, access to backup and storage media) HIPAA defines a workstation as “an electronic computing device, for example a laptop or desktop computer, or any other device that performs similar functions, and electronic media stored in its immediate environment.” Traditionally we think of workstations as computing “boxes” that sit on someone’s desk, but we must be diligent to apply security safeguards to any electronic device that can access or store EPHI, including laptops, desktops, PDAs, smartphones, USB thumb drives, etc. Policies and procedures must be put in place to address what devices can be used with HIT systems, what functions these devices can perform, and in what environment (the physical attributes of the surroundings where the device is used). Because the nature of health care organizations’ business operations vary greatly, every electronic device and location where it is used must be carefully examined and controlled to ensure the privacy and security of EPHI in HIT systems. Consider some examples: Are the desktop computers at a nurses station positioned such that an unauthorized individual walking by cannot easily see EPHI? Are the workstations configured to automatically prevent access when a clinician steps away (e.g., password-protected screen savers)? Are physicians permitted to access HIT systems containing EPHI from home? If so, what are the risks, do the benefits of access justify the risk, and are these being adequately mitigated? Are employees allowed to bring USB thumb drives, phones with cameras (that could be used to take a picture of a workstation screen containing EPHI), and other electronic devices into the clinical setting? The final standard under Physical Safeguards we will cover is Device and Media Controls. A covered entity must have policies and procedures in place to control the acquisition, movement and disposal of hardware and electronic media containing EPHI. Any media that is used to store EPHI, such as backup tapes, must be properly secured to prevent theft. If this media is disposed of, the organization must properly destroy all of the EPHI that it contains. Even if media is reused within the organization, steps must be taken to ensure that EPHI is properly destroyed. For example, a computer moved from a clinical area where EPHI is accessed to an administrative area where EPHI access is not appropriate must have the EPHI “wiped” from its hard drive. It’s important to note that simply deleting a file from a computer may not actually destroy the contents of the file. In fact, reformatting a hard drive does not necessarily rid the media of all EPHI. There are very specific technical procedures which need to be followed to ensure that information stored on media is properly destroyed, so it is important to seek help from a competent IT professional. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Physical Safeguards Device and Media Controls media disposal access to backup and storage media The final standard under Physical Safeguards we will cover is Device and Media Controls. A covered entity must have policies and procedures in place to control the acquisition, movement and disposal of hardware and electronic media containing EPHI. Any media that is used to store EPHI, such as backup tapes, must be properly secured to prevent theft. If this media is disposed of, the organization must properly destroy all of the EPHI that it contains. Even if media is reused within the organization, steps must be taken to ensure that EPHI is properly destroyed. For example, a computer moved from a clinical area where EPHI is accessed to an administrative area where EPHI access is not appropriate must have the EPHI “wiped” from its hard drive. It’s important to note that simply deleting a file from a computer may not actually destroy the contents of the file. In fact, reformatting a hard drive does not necessarily rid the media of all EPHI. There are very specific technical procedures which need to be followed to ensure that information stored on media is properly destroyed, so it is important to seek help from a competent IT professional. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Technical Safeguards Access Control Unique user identification Emergency access Automatic logoff Encryption/decryption The final category of HIPAA security safeguards we will examine is Technical Safeguards. The Security Rule defines technical safeguards as “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.” As we look at the standards in this area, we will include a few examples of types of specific technologies that can be used to help mitigate security risks. It’s important to note, however, that the HIPAA guidelines attempt to be technology neutral, and any security measure that could be used to mitigate a risk can be considered. Factors such as cost and feasibility to implement can and should be factored into the risk analysis and risk management implementation. Access controls provide users with privileges to access functionality and data within an information system (which could include HIT systems, file servers, desktops, etc.). These controls should be configured to provide the minimum level of access necessary for the user to perform job functions. These controls should be configured following the policies and procedures setup under the Administrative Safeguards section of the rule, which we covered earlier. Access controls should include: Unique user identification, with some mechanism (such as a username and password) that uniquely identifies users of an information system, and can be used to track user activity within information systems that contain EPHI. Emergency access procedures, which detail how someone would gain access to EPHI in the event of an emergency. Automatic logoff, which terminates an electronic session after a predetermined time of inactivity. Encryption and decryption of EPHI stored in information systems. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Technical Safeguards Audit Controls Integrity The Audit Controls standard requires a covered entity to implement mechanisms that record activity in information systems that contain or use EPHI. An example of this is a record created in a log file or database whenever EPHI is accessed or changed, that might record information such as the unique identifier of the person who accessed the information, the date of access, and details of any changes made. The Integrity standard requires the protection of EPHI from unauthorized or unintended alteration or destruction. There are many ways that EPHI might be unintentionally altered or destroyed, ranging from an employee accidentally or intentionally deleting data from an HIT system to the failure of an electronic component that leads to database corruption and altered data. There are technical controls that can be implemented to enable detection of alteration of data. For example, hashing algorithms can be used to calculate a “check sum” value for a EPHI document or record. If the document or record is altered, re-running the hashing algorithm against the document or record will detect the alteration because the check sum will change. The change can be assumed to be an integrity violation if there is no record of the change in an audit log. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Technical Safeguards Person or Entity Authentication Password/Passphrase/PIN Smart card/token/key Biometrics Two factor authentication The Person or Entity Authentication standard requires a covered entity to, “implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.” In other words, authentication is the method by which an electronic system is able to confirm that users are who they claim to be. We’re all very familiar with the technical control that is most often used with electronic systems to verify the authenticity of a user, namely requiring someone to provide information that only they know, most commonly in the form of a password, passphrase or PIN. There are other ways that identify can be confirmed, including requiring something that an individual possess (like a smart card, a token, or a key), or requiring something unique to the individual, namely the use of biometric authentication. Biometrics refers to devices that can scan features of an individual that are likely to be unique, such as fingerprints, voice patterns, facial patterns or iris patterns, and using the scan of these features to grant access to information systems. Risk analysis will help determine which type of authentication mechanism is most appropriate to use. Password authentication is the easiest to implement, but may not be the most secure, given the ease with which users can share password information. If password complexity requirements are lax, passwords into critical systems could potentially be guessed. To improve the security of password authentication, complexity requirements should be enforced (for example, requiring that passwords be 8 or more characters long, contain a variety of alphabetic and numeric characters, etc.), automatically lock an account if a password is typed incorrectly after so many attempts (to prevent brute force guessing of passwords), and to require users to change passwords regularly. These measures unfortunately have the side affect of making password authentication less convenient for the end user, which often results in the end user writing down their password, on a sticky note or some other insecure location that could be stolen. Administrative policies and procedures that prohibit writing down passwords could help prevent this, especially if there are serious sanctions that are enforced for violating the policies. However, most organizations will not rely exclusively on password authentication for access to systems containing sensitive EPHI. Using one of the other authentication techniques may be a better option, or combining the use of multiple mechanisms is an even better option. Using password authentication along with a smart card is an example of two-factor authentication, meaning that two authentication mechanisms are used to verify the identity of the user. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Technical Safeguards Transmission Security Integrity controls Encryption The final technical safeguard we will examine is Transmission Security. Transmission security controls prevent unauthorized access to EPHI that is transmitted over computer networks, such as a local area network (LAN) or the Internet. Some methods that are commonly used to transfer electronic information from place to place include , over the Internet, or over private networks. An example of this is an EHR system that has a client program running on a workstation that communicates with a server and transmits EPHI over the local area network. Transmission of EPHI over any network is permitted as long as appropriate controls are in place to protect EPHI from unauthorized access. There are two important methods that help ensure that EPHI is transferred securely, integrity controls and encryption. Integrity controls are measures that ensure that data transmitted electronically are not inappropriately modified, either intentionally or accidentally (such as problems with the network). This is similar to the requirement to ensure the integrity of data stored on electronic media, and the same mechanisms, such a hashing algorithms and check sums, can be used to detect unauthorized or accidental alterations for EPHI transferred over a network. Encryption is also an important safeguard to use when transferring data over a network. Data is encoded before being sent over a network (converted from a format like plain text that is understandable into a format that is scrambled and undecipherable). If the data is inappropriately accessed during the transmission, it won’t be decipherable. The data can only be converted back into an understandable format once it reaches its intended destination. Encryption can also be used as a method of ensuring the integrity of EPHI during transmission, since altered encrypted data will not be able to be decoded back to its original state (thus indicating inappropriate or accidental tampering of the data). An example of transmission security that you may be familiar with is the use of SSL to encrypt the transmission of information over the web. A web site address that contains is using this standard protocol to encrypt the transfer of information from a web server to a web browser located on a workstation computer. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Risk Analysis and Management
Gather data on potential threats and vulnerabilities Assess current security measures Determine likelihood, impact and level of risk Identify needed security measures Management Develop a plan for implementation Evaluate and maintain security measures We have covered a wide array of security safeguards that can and should be implemented to protect EPHI in HIT systems. Although we did not cover in great detail specific technologies, there is a large and diverse set of tools that could be used. Deciding what security safeguards and which specific technologies to use must be done as part of a careful risk analysis process. We are revisiting the risk analysis and management process here because it is critically important to any privacy and security program, regardless of the security management system standard that you may choose or be required to use. The HIPAA regulation does not dictate a single approach to conduct risk analysis of systems containing EPHI. Many of the resources discussed at the beginning of this unit, such as the NITS 800 series of publications (specifically ), provide a framework to conduct risk analysis and to create a risk management strategy. The basic framework for this and other risk management strategies are similar, and include elements such as gathering data on potential threats and vulnerabilities (like viruses and known exploits of IT systems), assessing current security measures (like anti-virus, policies and procedures to apply security patches to IT systems), determining the likelihood of security exploits, the impact of such exploits to the business and the corresponding level of risk that the organization can tolerate, and finally identifying security measures that are needed to mitigate unacceptable risk. All risk management plans include development of a plan to develop and implement security safeguards that are identified as needed based on the risk analysis process, and procedures for ongoing evaluation and maintenance of security measures. The importance of a formal risk analysis and management plan for healthcare organizations that accommodates the HIT systems that support the operations of these organizations cannot be overemphasized. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Meaningful Use Criteria for meaningful use of EHRs related to privacy, security and confidentiality meant to align with HIPAA Emphasizes need to conduct a risk analysis Some specific requirements for EHR vendors For the sake of meeting incentive standards, the meaningful use requirements emphasize specific areas of privacy and security that should be addressed by HIT systems, specifically EHR systems. These requirements are congruent with the larger HIPAA standards as outlined in the Privacy and Security rules. These include: Encryption and decryption of electronic health information Auditing Integrity (verification that electronic health information has not been altered while stored or in transit—this is particularly important with the meaningful use emphasis on HIE, or health information exchange) Record treatment, payment, and health care operations disclosures Access control (unique user identification, only authorized access) Emergency access (“break-glass”) Automatic log-off Audit log: ability for users to report based on the audit log Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Summary Privacy, security, and confidentiality in HIT settings Common threats encountered when using HIT Strategies to minimize threats to privacy, security, and confidentiality in HIT systems. This concludes unit 7. To summarize, in this unit we have explored what privacy, security and confidentiality mean in relation to HIT systems. As we have explored the range of security safeguards that can be employed to protect the confidentiality of health information in HIT systems, we have learned about some of the common threats to data in these systems. Hopefully you have learned some of the strategies that can be used to minimize threats to privacy, security, and confidentiality in HIT systems, such as a formal risk analysis and management process for your organization that is facilitated by regulations (such as HIPAA) and/or security management system standards (such as the ISO series or the NIST 800 series). Such effort will ensure that the fundamental security of health information is assured, leading to trust on the part of providers and patients that will be necessary for HIT to realize its potential for health care transformation. Component 7/Unit 7 Health IT Workforce Curriculum Version 1.0/Fall 2010

Working with HIT Systems

Similar presentations

Presentation on theme: "Working with HIT Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Working with HIT Systems

Similar presentations

Presentation on theme: "Working with HIT Systems"— Presentation transcript:

Similar presentations

About project

Feedback