MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis


Published on

An overview of MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis

  1. 1. The HIPAA–HITECH Privacy and Security Rule Overview & Meaningful Use Core Requirements for Risk Analysis “Technology Made Easy”
  2. 2. Disclaimer This guide was prepared to help small health care practices learn about the information security considerations that they may need to take into account as they become more reliant on health information technology. Use of this guide is voluntary and while it includes many important concepts, it alone will not enable, nor was it designed to ensure, that a health care practice complies with all applicable Federal and State laws. “Technology Made Easy” Presentation Outline HIPAA The Privacy Rule The Security Rule HITECH Meaningful Use The Final Security Rule Risk Analysis Q&A Helpful Information
  3. 3. HIPAA The Health Insurance Portability and Accountability Act of 1996 (HIPAA) “Technology Made Easy” • Law that regulates an employee’s ability to qualify for health coverage with a change in their employment situation • Rules regulating the structure and format for Data Interchange between health care entities • Regulations protecting the privacy and security of Protected Health Information (PHI) HIPAA is …
  4. 4. HIPAA Verbiage “Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information ” “Technology Made Easy”
  5. 5. Vulnerability NIST SP 800-30 – defines a vulnerability similarly: A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy. Vulnerability, the least contentious of the Information Security definitions has only a single dictionary definition – exposure to attack. In Information Security, then, vulnerability could be defined as “a flaw or weakness in hardware, software or process that exposes a system to compromise”. “Technology Made Easy”
  6. 6. Threat NIST SP800-30 “threat-source” as the interaction of an actor and motivation, and “threat” as the interaction between a “threat- source” and a vulnerability. The potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability. A threat then, is either intention/motivation, an actor, a possibility of danger or a combination of a subset of those. My preferred definition is that threat is the “interaction of actor, motivation and vulnerability”. “Technology Made Easy”
  7. 7. Risk NIST SP 800-30 – Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. Risk assessment is the process of identifying, estimating, and prioritizing information security risks. Assessing risk requires the careful analysis of threat and vulnerability information to determine the extent to which circumstances or events could adversely impact an organization and the likelihood that such circumstances or events will occur. The potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization. So “risk” contains elements of a threatening circumstance (actor, motivation and vulnerability), probability and business impact. It is important consider semantics here – we are not considering the risk of a threat, we are considering the risk associated with a business suffering an outcome as a result of a threat. “Technology Made Easy”
  8. 8. Risk Governance National Institute of Standards and Technology (NIST) SP800 – 30 Risk Management Risk assessment is the first process in the risk management methodology. Risk Assessment methodology has nine core components: 1. Understanding your environment (System characterization) 2. Vulnerability identification 3. Threat identification 4. Assessment of how you safeguard your systems now (Control analysis) 5. Likelihood analysis (what is the likelihood of a threat happening?) 6. Impact analysis (are there any systems that are "mission critical?) 7. Risk determination (ranking these risks) 8. Control Recommendations (what are the answers or solutions for your risks) 9. Results Documentation (Documenting or reporting your results) SP800-53A Security Control SP800-66 HIPAA Guide “Technology Made Easy”
  9. 9. Privacy Rule The Privacy Rule standards address the use and disclosure of individuals’ health information—called “protected health information” by organizations subject to the Privacy Rule — called “covered entities,” as well as standards for individuals' privacy rights to understand and control how their health information is used. Privacy Rule Goal A major goal of the Privacy Rule is to assure that individuals’ health information is properly protected while allowing the flow of health information needed to provide and promote high quality health care and to protect the public's health and well being. The Rule strikes a balance that permits important uses of information, while protecting the privacy of people who seek care and healing. “Technology Made Easy”
  10. 10. Security Rule The HIPAA Security Rule establishes national standards to protect individuals’ electronic personal health information that is created, received, used, or maintained by a covered entity. Security Rule Requires The Security Rule requires appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity, and security of electronic protected health information. “Technology Made Easy”
  11. 11. The HIPAA Security Final Security RuleFebruary 20, 2003 §164.306(a) General requirement Covered entities must do the following: (1)Ensure the confidentiality, integrity and availability of all electronic protected health information the covered entity creates, receives, maintains, or transmits. (2)Protect against any reasonably anticipated threats or hazards to the security or integrity of such information. (3)Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part; and (4) Ensure compliance with this subpart by its workforce A Rule by the Modified by Health and Human Services Department on 01/25/2013 “Technology Made Easy”
  12. 12. Risk Analysis under the Security Rule HIPAA requires that each covered entity conduct a formal risk analysis. Specifically, this means: • Analyze the risks and vulnerabilities to the ePHI each covered entity creates, maintains, stores or transmits • Understand the probability of these risks and vulnerabilities • Assess measures already in place to reduce these risks • Analyze its information and applications to find what is critical and what is not • Conduct a formal risk analysis that balances the cost of security against the expected value of losses • As a result of the analysis each entity must have a formal risk management process that reduces risk to an acceptable level “Technology Made Easy”
  13. 13. Risk Analysis Requirements under the Security Rule The Security Management Process standard in the Security Rule requires organizations to: “[i]mplement policies and procedures to prevent, detect, contain, and correct security violations.” (45 C.F.R. § 164.308(a)(1).) Risk analysis is one of four required implementation specifications that provide instructions to implement the Security Management Process standard. Section 164.308(a)(1)(ii)(A) states: • RISK ANALYSIS (Required). • Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the [organization]. • The following questions adapted from NIST Special Publication (SP) 800-665 are examples organizations could consider as part of a risk analysis. These sample questions are not prescriptive and merely identify issues an organization may wish to consider in implementing the Security Rule: • Have you identified the e-PHI within your organization? This includes e-PHI that you create, receive, maintain or transmit. • What are the external sources of e-PHI? • For example, do vendors or consultants create, receive, maintain or transmit e-PHI? • What are the human, natural, and environmental threats to information systems that contain e-PHI? • In addition to an express requirement to conduct a risk analysis, the Rule indicates that risk analysis is a necessary tool in reaching substantial compliance with many other standards and implementation specifications. For example, the Rule contains several implementation specifications that are labeled “addressable” rather than “required.” (68 FR 8334, 8336 (Feb. 20, 2003).) An addressable implementation specification is not optional; rather, if an organization determines that the implementation specification is not reasonable and appropriate, the organization must document why it is not reasonable and appropriate and adopt an equivalent measure if it is reasonable and appropriate to do so. (See 68 FR 8334, 8336 (Feb. 20, 2003); 45 C.F.R. § 164.306(d)(3).) • The outcome of the risk analysis process is a critical factor in assessing whether an implementation specification or an equivalent measure is reasonable and appropriate. • 5 See NIST SP 800-66, Section #4 "Considerations When Applying the HIPAA Security Rule." Available at http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/nist80066.pdf
  14. 14. Who Should Conduct Security Risk Analysis? • Your EMR Vendor will NOT meet this requirement for you • IT Vendor – may lack HIPAA and non-technical expertise • Practice Does It– usually lack resources and expertise • Third party independent auditor “Technology Made Easy”
  15. 15. HIPAA Security Rule Requirements  Administrative Safeguards Standards  Security Management Process  Risk Analysis  Risk management  Information Access Management  Security Awareness & Training  Physical Safeguards  Workstation security & device/media controls  Technical Safeguards  Access controls to ePHI  Audit & transmission security  Organizational Requirements  BA Contracts addressing security of ePHI  Policy & procedures documentation “Technology Made Easy”
  16. 16. Structure of the Security Rule • Standards – the broad security requirements – The standards are “required” • Implementation Specifications – The more detailed instructions contained within each Standard – Some are required (R) – Some are addressable (A) – flexibility and latitude in meeting – Based on what’s “reasonable and appropriate” “Technology Made Easy”
  17. 17. Defining Reasonable and Appropriate • The size, complexity and technical capabilities of the covered entity • The nature of the patient population (celebrities, athletes) and the sensitivity of the data • The costs of security measures • From the risk analysis - The likelihood and criticality of potential risks to ePHI “Technology Made Easy”
  18. 18. HITECH Act The term, HITECH stands for Health Information Technology for Economic and Clinical Health which is part of the American Recovery and Reinvestment Act as stated by the U.S Congress in 2009. This act requires medical establishments to adopt make use of the Electronic Health Records where their deadline falls in the year 2019. HITECH Offers The government offers incentive programs for medical establishments who will be following the HITECH Act. Turning their records into EHR systems is highly recommended for better security while getting easy access to their files when needed. Those who are not able to comply with the HITECH Act will be penalized as stated in the act which medical practices are not too keen on experiencing hence the move to the use of EHR. Medicare = $44,000 (5yrs) Medicaid = $63,750 (6yrs) “Technology Made Easy”
  19. 19. Penalties Increased Penalties Before HITECH Noncompliance $100 per violation up to $25000 per person for the same violation For example, not having a risk analysis would be such a violation Penalties After HITECH Due to Reasonable Cause $1000 per violation due to reasonable cause - $100K max Due to Willful Neglect $10,000 per violation if corrected - $250K max $50,000 per violation if uncorrected - $1.5M max “Technology Made Easy”
  20. 20. "Meaningful Use" The American Recovery and Reinvestment Act of 2009 specifies three main components of Meaningful Use: • The use of a certified EHR in a meaningful manner, such as e- prescribing. • The use of certified EHR technology for electronic exchange of health information to improve quality of health care. • The use of certified EHR technology to submit clinical quality and other measures. Simply put, "meaningful use" means providers need to show they're using certified EHR technology in ways that can be measured significantly in quality and in quantity. . “Technology Made Easy”
  21. 21. Meaningful Use and Risk Analysis #12 Provide patients with electronic copy of their health information upon request #13 Provide clinical summaries for patients for each office # 14 Perform at least one test of certified EHR technical #15 Conduct or review a Security Risk Analysis per 45 CFR per 45 CFR 164.308 (a)(1) Conduct or review a Security Risk Analysis and implement security updates as necessary. MEANINGFUL USE Stage 1 Core CRITERIA “Technology Made Easy”
  22. 22. per 45 CFR 164.308 (a)(1) Conduct or review a Security Risk Analysis and implement security updates as necessary. MEANINGFUL USE Stage 2 Core CRITERIA Meaningful Use Core Measures Measure 9 of 17 Date issued: October, 2012 Protect Electronic Health Information Protect electronic health information created or maintained by the certified EHR technology (CEHRT) through the implementation of appropriate technical capabilities. Measure Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a) (1), including addressing the encryption/security of data stored in CEHRT in accordance with requirements under 45 CFR 164.312 (a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider's risk management process for EPs. Exclusion No exclusion. Meaningful Use and Risk Analysis “Technology Made Easy”
  23. 23. Why Security Risk Analysis? • Justification for “Reasonable and Appropriate” for Addressable Implementation Specifications • Identify assets, vulnerabilities and controls • Improved basis for decision making • Justify Expenditures for Security • Helps determine personnel access levels • It is required for compliance • Reduce your IT cost of ownership
  24. 24. 1. Final modifications to the HIPAA Privacy, Security, and Enforcement Rules mandated by the Health Information Technology for Economic and Clinical Health (HITECH) Act, and certain other modifications to improve the Rules, which were issued as a proposed rule on July 14, 2010. These modifications: A) Make Business Associates of Covered Entities directly liable for compliance with certain of the HIPAA Privacy and Security Rules' requirements. B) Strengthen the limitations on the use and disclosure of protected health information for marketing and fundraising purposes, and prohibit the sale of protected health information without individual authorization. C) Expand individuals' rights to receive electronic copies of their health information and to restrict disclosures to a health plan concerning treatment for which the individual has paid out of pocket in full. D) Require modifications to, and redistribution of, a Covered Entity's notice of privacy practices. F) Modify the individual authorization and other requirements to facilitate research and disclosure of child immunization proof to schools, and to enable access to decedent information by family members or others. G) Adopt the additional HITECH Act enhancements to the Enforcement Rule not previously adopted in the October 30, 2009, interim final rule, such as the provisions addressing enforcement of noncompliance with the HIPAA Rules due to willful neglect. HHS's Summary of the HIPAA Omnibus Rule
  25. 25. 2. Final rule adopting changes to the HIPAA Enforcement Rule to incorporate the increased and tiered civil money penalty structure provided by the HITECH Act, originally published as an interim final rule on October 30, 2009. 3. Final rule on Breach Notification for Unsecured Protected Health Information under the HITECH Act, which replaces the breach notification rule's "harm" threshold with a more objective standard and supplants an interim final rule published on August 24, 2009. 4. Final rule modifying the HIPAA Privacy Rule as required by the Genetic Information Nondiscrimination Act (GINA) to prohibit most health plans from using or disclosing genetic information for underwriting purposes, which was published as a proposed rule on October 7, 2009." HHS's Summary of the HIPAA Omnibus Rule continued
  26. 26. HIPAA Security Considerations The HIPAA Security Rule addresses electronic patient health information or ePHI. 19 standards, 42 specifications The documentation requirement is daunting No guidance is provided to address requirements Limited availability of resources Security expertise is expensive “Technology Made Easy”
  27. 27. Our Consulting Features • Endorsed by NIST, Homeland Defense and leading medical organization and societies • Over 55 specific HIPAA requirements addressed • Cost-effective • Differentiation between Required and Addressable items • Reporting and progress reports – Network Mapping and Vulnerability Scanning – Management and Technical Detailed Summary – Remediation Reporting – Priority and status tracking – GAP Analysis – SAL Diagrams • Tips, definitions, and example compliance efforts • Recording of comments and compliance documentation • Blueprint necessary for HIPAA Security Risk Management compliance • We work with your IT group and organization • Our Policies and Procedures Templates cover all 55 HIPAA-HITECH requirements “Technology Made Easy”
  28. 28. HIPAA Security Onsite Investigations and Compliance Reviews Personnel that may be interviewed • President, CEO or Director • HIPAA Compliance Officer • Lead Systems Manager or Director • Systems Security Officer • Lead Network Engineer and/or individuals responsible for: • administration of systems which store, transmit, or access Electronic Protected Health Information (EPHI) • administration systems networks (wired and wireless) • monitoring of systems which store, transmit, or access EPHI • monitoring systems networks (if different from above) • Computer Hardware Specialist • Disaster Recovery Specialist or person in charge of data backup • Facility Access Control Coordinator (physical security) • Human Resources Representative • Director of Training • Incident Response Team Leader • Others as identified….
  29. 29. Policies and Procedures and other Evidence that Address the Following: • Prevention, detection, containment, and correction of security violations • Employee background checks and confidentiality agreements • Establishing user access for new and existing employees • List of authentication methods used to identify users authorized to access EPHI • List of individuals and contractors with access to EPHI to include copies pertinent business associate agreements • List of software used to manage and control access to the Internet • Detecting, reporting, and responding to security incidents (if not in the security plan) • Physical security • Encryption and decryption of EPHI • Mechanisms to ensure integrity of data during transmission -including portable media transmission (i.e. laptops, cell phones, blackberries, thumb drives) • Monitoring systems use -authorized and unauthorized • Use of wireless networks • Granting, approving, and monitoring systems access (for example, by level, role, and job function) • Sanctions for workforce members in violation of policies and procedures governing EPHI access or use • Termination of systems access • Session termination policies and procedures for inactive computer systems • Policies and procedures for emergency access to electronic information systems • Password management policies and procedures • Secure workstation use (documentation of specific guidelines for each class of workstation (i.e., on site, laptop, and home system usage) • Disposal of media and devices containing EPHI HIPAA Security Onsite Investigations and Compliance Reviews Documents and other information
  30. 30. HIPAA Security Onsite Investigations and Compliance Reviews Documents and other information cont. Other Documents: • Entity-wide Security Plan • Risk Analysis (most recent) • Risk Management Plan (addressing risks identified in the Risk Analysis) • Security violation monitoring reports • Vulnerability scanning plans • Results from most recent vulnerability scan • Network penetration testing policy and procedure • Results from most recent network penetration test • List of all user accounts with access to systems which store, transmit, or access EPHI (for active and terminated employees) • Configuration standards to include patch management for systems which store, transmit, or access EPHI (including workstations) • Encryption or equivalent measures implemented on systems that store, transmit, or access EPHI • Organization chart to include staff members responsible for general HIPAA compliance to include the protection of EPHI • Examples of training courses or communications delivered to staff members to ensure awareness and understanding of EPHI policies and procedures (security awareness training) • Policies and procedures governing the use of virus protection software • Data backup procedures • Disaster recovery plan • Disaster recovery test plans and results • Analysis of information systems, applications, and data groups according to their criticality and sensitivity • Inventory of all information systems to include network diagrams listing hardware and software used to store, transmit or maintain EPHI • List of all Primary Domain Controllers (PDC) and servers • Inventory log recording the owner and movement media and devices that contain EPHI
  31. 31. Myth Fact The security risk analysis is optional for small providers False. All providers who are “covered entities” under HIPAA are required to perform a risk analysis. In addition, all providers who want to receive EHR incentive payments must conduct a risk analysis. Simply installing a certified EHR fulfills the security risk analysis MU requirement. False. Even with a certified EHR, you must perform a full security risk analysis. Security requirements address all electronic protected health information you maintain, not just what is in your EHR. My EHR vendor took care of everything I need to do about privacy and security. False. Your EHR vendor may be able to provide information, assistance, and training on the privacy and security aspects of the EHR product. However, EHR vendors are not responsible for making their products compliant with HIPAA Privacy and Security Rules. It is solely your responsibility to have a complete risk analysis conducted. I have to outsource the security risk analysis. False. It is possible for small practices to do risk analysis. However, doing a thorough and professional risk analysis that will stand up to a compliance review will require expert knowledge that could be obtained through services of an experienced outside professional. A checklist will suffice for the risk analysis requirement. False. Checklists can be useful tools, especially when starting a risk analysis, but they fall short of performing a systematic security risk analysis or documenting that one has been performed. There is a specific risk analysis method that I must follow. False. A risk analysis can be performed in countless ways. However, expert HIPAA knowledge and guidance assists organizations in identifying and implementing the most effective and appropriate safeguards to secure e-PHI. My security risk analysis only needs to look at my EHR. False. Review all electronic devices that store, capture, or modify electronic protected health information. Include your EHR hardware and software and devices that can access your EHR data (e.g., your tablet computer, your practice manager’s mobile phone). Remember that copiers also store data. Please see U.S. Department of Health and Human Services (HHS) guidance on remote use. I only need to do a risk analysis once. False. To comply with HIPAA, you must continue to review, correct or modify, and update security protections. Before I attest for an EHR incentive program, I must fully mitigate all risks. False. The EHR incentive program requires addressing any deficiencies identified during the risk analysis during the reporting period. Each year, I’ll have to completely redo my security risk analysis. False. Perform the full security risk analysis as you adopt an EHR. Each year or when changes to your practice or electronic systems occur, review and update the prior analysis for changes in risks.
  32. 32. Contact Information Toll: 800-236-2498 Local: 678.648.1255 Fax: 678.264.2197 email: info@mbmehs.com Website: www.mbmehs.com “Technology Made Easy”