MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis

The HIPAA–HITECH
Privacy and Security Rule Overview
&
Meaningful Use Core Requirements
for Risk Analysis
“Technology Made Easy”

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.
Presentation Outline
HIPAA
The Privacy Rule
The Security Rule
HITECH
Meaningful Use
The Final Security Rule
Risk Analysis
Q&A
Helpful Information

HIPAA
The Health Insurance Portability
and Accountability Act of 1996 (HIPAA)
• 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 …

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 ”

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”.

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”.

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.

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

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.

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.

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

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

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

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

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

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”

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

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)

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

"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.
.

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

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

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

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

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

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

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

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….

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
Documents and other information

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

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.

Contact Information
Toll: 800-236-2498
Local: 678.648.1255
Fax: 678.264.2197
email: info@mbmehs.com
Website: www.mbmehs.com

MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Destaque

Destaque (13)

Semelhante a MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis

Semelhante a MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis (20)

Mais de Charles McNeil

Mais de Charles McNeil (14)

Último

Último (20)

MBM eHealthCare Solutions HIPAA-HITECH & Meaningful Use Risk Analysis