Presentation is loading. Please wait.

Presentation is loading. Please wait.

No audio. Recording preparation.

Similar presentations


Presentation on theme: "No audio. Recording preparation."— Presentation transcript:

1 No audio. Recording preparation.
Health IT Workforce Curriculum Version 4.0

2 The Culture of Health Care
Privacy, Confidentiality, and Security Welcome to The Culture of Health Care: Privacy, Confidentiality, and Security. This is Lecture d. The component, The Culture of Health Care, addresses job expectations in health care settings. It discusses how care is organized within a practice setting, privacy laws, and professional and ethical issues encountered in the workplace. Lecture d This material (Comp 2 Unit 9) was developed by Oregon Health & Science University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by Bellevue College under Award Number 90WT0002. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

3 Privacy, Confidentiality, and Security Learning Objectives
Define and discern the differences between privacy, confidentiality, and security (Lecture a). Discuss methods for using information technology to protect privacy and confidentiality(Lecture b). Describe and apply privacy, confidentiality, and security under the tenets of HIPAA Privacy and Security rules (Lectures c and d). Discuss the intersection of a patient’s right to privacy with the need to share and exchange patient information (Lecture d). The objectives for Privacy, Confidentiality, and Security are to: Define and discern the differences between privacy, confidentiality, and security Discuss methods for using information technology to protect privacy and confidentiality Describe and apply privacy, confidentiality, and security under the tenets of the HIPAA Privacy and Security rules Discuss the intersection of a patient’s right to privacy with the need to share and exchange patient information.

4 HIPAA Security Rule Readable overview in Security 101 for Covered Entities (CMS, 2007) Aligned with terminology of Privacy Rule Aims to minimize specificity to allow scalability, flexibility, and changes in technology For covered entities, business associates, and subcontractors, rules are either Required: Must be implemented Addressable: If reasonable and appropriate to implement As with HIPAA Privacy Rule, modifications under HITECH and other legislative actions State laws are instrumental This lecture discusses the Health Insurance Portability and Accountability Act (HIPAA) [hip-uh] Security Rule. There’s a very readable overview of the HIPAA Security Rule on the Centers for Medicare and Medicaid Services, or CMS, website called Security 101 for Covered Entities. A number of other documents that go into detail on the specifics of the Security Rule are publicly available through such sources as the Department of Health and Human Services (HHS) website. The Health Information and Management Systems Society, HIMSS, offers the Privacy and Security Toolkit, which contains analysis of the HIPAA law as well as tools and resources for understanding and implementing various elements of the law. This toolkit, like many other industry resources, provides HIPAA information on specific aspects of the rule, such as with mobile devices, health information exchange organizations, public health, and cloud computing. Many industry resources focus on a specific health care professional, such as physicians, nurses, business associates, and human resources. The terminology of the HIPAA Security Rule is aligned with the Privacy Rule, so that presumably we could identify areas of the Security Rule that map back to the Privacy Rule. The HIPAA Security Rule aims to minimize specificity and to be technology-neutral to allow covered entities scalability, flexibility, and adaptability as technologies change. As such, there are only thirteen required implementation specifics. The remainder of the rules are addressable; that is, they concern approaches that may or may not be reasonable for a particular covered entity. As with the HIPAA Privacy Rule, the Security Rule has been enhanced and modified under the Health Information Technology for Economic and Clinical Health Act (HITECH [high-tech]) and other legislative updates. Also, various state security laws must be addressed in conjunction with HIPAA requirements.

5 General Provisions Covered entities, business associates, and their subcontractors must Ensure confidentiality, integrity, and availability of electronic PHI that they create, receive, transmit, and maintain Protect against reasonably anticipated threats and hazards to such information Protect against reasonably anticipated uses or disclosures not permitted or required by Privacy Rule Ensure compliance by workforce HHS (2010) provides guidance on conducting risk assessments and helps determine whether an issue that’s addressable should be addressed by the provider The general provisions of the Security Rule are that covered entities, their business associates, and subcontractors must ensure confidentiality, integrity, and availability of electronic protected health information (PHI) that is created, received, transmitted, and maintained by the entity. Entities must protect against reasonably anticipated threats and hazards to such information by having a secure data center and using encryption where appropriate. They also must protect against reasonably anticipated uses or disclosures that are not permitted or that are required by the Privacy Rule. Entities must also ensure compliance by their workforce in implementing the security and privacy rules. HHS provides guidance on conducting risk assessments. One important feature of this reference is that it helps determine whether something that is addressable should be addressed by the provider. If the provider chooses not to address it, the decision should be documented in the risk analysis. There are many other publicly available risk assessment resources as well.

6 Required Safeguards Grouped into three categories
Administrative: Policies and procedures designed to prevent, detect, contain, and correct security violations Physical: Protecting facilities, equipment, and media Technical: Implementing technological policies and procedures Following slides from Security 101 What are the required safeguards? They are grouped into three categories: administrative, physical, and technical. Administrative safeguards are policies and procedures that are designed to prevent, detect, and contain security violations. Physical safeguards include protecting facilities, equipment, and media where medical information is stored. Technical safeguards are various technical policies and procedures governing use of and access to PHI. The following slides show some features from each category, though these aren’t exhaustive. The overview article referenced earlier further enumerates all of these safeguards, as do many other sources of information. Security risk assessment is very similar to the risk analysis presented in Lecture c on the HIPAA Privacy Rule. Oversight and management of both the security and privacy risk assessment ideally should tie into the organization’s overall governance and risk management program.

7 Administrative Safeguards
Security management process Risk analysis (R) Risk management (R) Sanction policy (R) Information system activity review (R) Assigned security responsibility (R) Workforce security Authorization and/or supervision (A) Workforce clearance procedure (A) Termination procedures (A) Information access management Isolating healthcare clearinghouse functions (R) Access authorization (A) Access establishment and modification (A) R = required A = addressable This slide shows the first part of the list of administrative safeguards from the Security 101 document. Perhaps the most important of the required standards is a security management process that includes an analysis of risk, how risk is managed, and any sanction policy. Procedures for addressing security violations as well as an overall information system activity review are also needed. Additionally, security responsibility must be assigned, usually to the chief security officer. The role of the chief security officer includes providing administrative management within the organization as well as providing technical expertise. The security for the rest of the workforce is addressable, as are aspects of information access management with the exception of the requirement that health care clearinghouse functions must be isolated for analysis with regard to security issues.

8 Administrative Safeguards Continued
Security awareness and training Security reminders (A) Protection from malicious software (A) Log-in monitoring (A) Password management (A) Security incident procedures—response & reporting (R) Contingency plan Data back-up plan (R) Disaster recovery plan (R) Emergency mode operation plan (R) Testing and revision procedures (A) Application and data criticality analysis (A) Evaluation (R) Business association contracts, subcontractors, and other arrangements (R) Continuing with the administrative safeguards, security awareness and workforce training cover concerns such as security reminders, protection from malicious software like viruses and spyware, login monitoring, audit trails, and password management. All of these issues must be addressed, and a process must be in place for security incident procedures. Organizations also need a contingency plan, which includes data backup, disaster recovery, and emergency response procedures. There also needs to be evaluation of the security process as it pertains to the explicit agreements with an organization’s business associates and their subcontractors. A disaster recovery plan for the information technology department and the organization should be developed and tested annually.

9 Physical Safeguards Facility access controls Workstation use (R)
Contingency operations (A) Facility security plan (A) Access control and validation procedures (A) Maintenance records (A) Workstation use (R) Workstation security (R) Device and media controls Disposal (R) Media re-use (R) Accountability (A) Data backup and storage (A) The second category of safeguards is physical safeguards. Access to the facility is addressable, so the facility must have a security plan with contingency operations, maintenance records, and other controls. The facility includes the data center location and associated data center hardware, software, and network access points as well as physical access controls to the area. There are requirements for workstation use, physical security of the workstation, and dealing with devices and media. There are explicit regulations for how media containing PHI is disposed of or reused. There are also addressable issues on accountability for media and its backup and storage. Also, the secure use of various types of mobile devices must be addressed.

10 Technical Safeguards Access control Audit controls (R)
Unique user identification (R) Emergency access procedure (R) Automatic logoff (A) Encryption and decryption (A) Audit controls (R) Integrity—mechanism to authenticate electronic PHI (A) Person or entity authentication (R) Transmission security Integrity controls (A) Encryption (A) The third and final category is technical safeguards. This includes issues such as access control. According to the specifications, every user of a system containing PHI is required to have a unique, personal user identification, and there needs to be emergency access to information when appropriate. One addressable specification is automatic logoff. Institutions must decide how quickly they want a system to automatically log off a user; in operational settings, different groups have different ideas on the length of time before automatic logoff should occur. Encryption and decryption are listed as addressable specifications because the developers of the HIPAA security regulations realized that the technology would be changing and that people within organizations would be able to make the best decisions on specific encryption and decryption needs. Audit controls are required under the technical safeguards, while integrity mechanisms that authenticate PHI are addressable. Authentication of the individual and/or the institution is a required specification; transmission security is addressable.

11 Other Regulations Business associates and subcontractors are required to Implement safeguards to protect covered entity’s PHI Ensure its agents meet same standards Report to covered entity any security incident Documentation of covered entity must be Maintained for six years Available to those responsible for implementing Reviewed and updated periodically HITECH meaningful use criteria specify use of various encryption standards (e.g., AES, TLS, IPsec, SHA-2) Business associates and all related subcontractors are required to implement safeguards to protect a covered entity’s PHI and report back to the covered entity any security incident. Business associates and subcontractors are subject to all breach notification rules when the number of patient records breached exceeds five hundred—that is, the breach must be reported to the local media and to the HHS Office for Civil Rights. There are also regulations regarding the documentation of entity security practices and procedures that must be maintained for six years. The documentation must be made available to those responsible for implementing security, and it must be reviewed and updated periodically. The meaningful use criteria of the HITECH Act also specify various government encryption standards, discussed in a previous lecture, such as advanced encryption standard (AES), the standard for encryption and decryption; transport layer security (TLS) and Internet Protocol Security (IPsec) [eye-pee-sehk], which cover how information moves across networks; and the latest secure hash algorithms (SHA-2) [S-H-A-two], which verify that information is transmitted intact from one point to another.

12 In the End… Ongoing breaches of data are worsening, but
Complete security of all health information is impossible Security is a trade-off with ease of use; a happy medium must be found Will concerns be tempered when society sees more benefits of health IT? Would other societal changes lessen the impact of this problem (changes in legal system, health care financing, etc.)? In bringing this discussion of privacy and confidentiality and security together, what can we conclude? Clearly, the ongoing breaches of data are getting worse, as discussed in previous lectures, so serious attention needs to be paid to privacy and security issues—they’re not to be taken lightly. However, it’s also probable that complete security of all health information is impossible. Too many people access information, too many of the applications are not as robust as they could be, and as discussed in a previous lecture, security is a trade-off with ease of use. As such, there needs to be a happy medium where the desired level of security can be attained without compromising the benefits of health IT, such as error prevention and improved quality. Another question that comes up is, Will the theoretical (and some real) concerns about privacy and security be tempered somewhat when society sees more of the benefits of health IT? A final question might be, would other societal changes lessen the impact of the problem? That is, would security risks be reduced if the legal system more rigorously prosecuted discrimination, if the health care finance system were more equitable, or if the health insurance system had a safety net to prevent people from losing their health coverage when, for example, they change jobs?

13 Privacy, Confidentiality, and Security Summary – Lecture d
HIPAA Security Rule aims to be actionable but flexible Rules are either required or addressable Rules fall into three categories: Administrative Physical Technical This concludes Lecture d of Privacy, Confidentiality and Security. In summary, the HIPAA Security Rule aims to be actionable but flexible. Its rules are either required or addressable, and they fall into three categories: administrative, physical, and technical.

14 Privacy, Confidentiality, and Security Summary
Privacy is the right to keep information to yourself Confidentiality is the right to keep information about yourself from being disclosed to others Security in this context is the protection of sensitive health information There are many technologies to maintain security, but human vigilance is also required The HIPAA Privacy and Security Rules spell out the requirements for the United States This also concludes Privacy, Confidentiality, and Security. In summary, the major aspects of privacy, confidentiality, and security of health information were reviewed, and the HIPAA Privacy and Security Rules were explored. Privacy is the right to keep information to ourselves, whereas confidentiality is the right to keep information about ourselves from being disclosed to others. Security in this context is the protection of sensitive health information. There are many technologies to maintain security, but human vigilance is also required. Finally, the HIPAA Privacy and Security Rules spell out the requirements for health care organizations and those with whom they do business in the United States.

15 Privacy, Confidentiality, and Security References – Lecture d
CMS (Centers for Medicare and Medicaid Services). (2007). Security 101 for covered entities. Baltimore, MD: Centers for Medicare and Medicaid Services. Retrieved from HealthIT.gov. (2014). Security risk assessment. Retrieved from HHS (U.S. Department of Health and Human Services). (n.d.). Summary of the HIPAA security rule. Retrieved from HHS. (2010). Guidance on risk analysis requirements under the HIPAA security rule. Washington, DC: Department of Health and Human Services. Retrieved from HHS Press Office. (2014, March 28). HHS releases security risk assessment tool to help providers with HIPAA compliance. Retrieved from HIMSS (Health Information and Management Systems Society). (2013). Introduction to the risk assessment toolkit and security risk assessment basics. Retrieved from No audio.

16 The Culture of Health Care Privacy, Confidentiality, and Security Lecture d
This material was developed by Oregon Health & Science University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by Bellevue College under Award Number 90WT0002. No audio. Health IT Workforce Curriculum Version 4.0


Download ppt "No audio. Recording preparation."

Similar presentations


Ads by Google