HHS HIPAA Compliance

Overview

HIPAA compliance is, of course, a must for healthcare providers. HIPAA guidelines protect patients’ health information, guaranteeing it is stored securely, accessed only by those with need, and applied correctly. Data that can reveal a patient’s identity, called Patient Heath Information (PHI), must be kept confidential. HIPAA compliance is adherence to the physical, administrative, and technical safeguards outlined in HIPAA, which covered entities and business associates must uphold to protect the integrity of Patient Health Information (PHI).

 

The Five Main Directives of HIPAA

• HIPAA Title I focuses on the new insurance reform that was introduced in HIPAA, specifying rules about the access, portability, and renewability of health insurance. Making it possible to maintain coverage when your employment changes and making it unlawful for group insurance plans to turn down health coverage.

• HIPAA Title II  concentrates on the required steps of the Privacy Rule, Security Rule, and the Enforcement Rule. It also defines national standards on how electronic healthcare transactions are processed by the U.S. Dept of Health and Human Services (HHS)

• HIPAA Title III  introduces new tax rules related to healthcare treatment including the provisioning of certain deductions for medical insurance.

• HIPAA Title IV  provides details on the reform of insurance law, with protections for those who have pre-existing conditions and individuals who want to maintain their insurance.

• HIPAA Title V  gives guidelines for life insurance policies that are owned by businesses and how to handle income tax specifics when someone has their US citizenship revoked.

 

HIPAA and Information Technology/Cloud

Not surprisingly, a HIPAA compliant IT service provider will be most concerned with HIPAA Title II.    Title II establishes and describes these five elements;

• National Provider Identifier Standard – 10-digit NPI (national provider identifier) numbers must be assigned to all healthcare entities.

• Transactions and Code Set Privacy Standard – this objectively approved protocol must be used in electronic data interchange (EDI).

• HIPAA Privacy Rule – Ensuring that Patient Health Information (PHI) is protected. The Privacy Rule is actually short-hand for the “Standards for Privacy of Individually Identifiable Health Information.”

• HIPAA Security Rule – This rule delineates expectations for the safeguarding of patient data. The Security Rule is short-hand for the “Security Standards for the Protection of Electronic Protected Health Information.”

• HIPAA Enforcement Rule – This subsection of the law provides parameters with which companies should be investigated for potential or alleged violations.

The HIPAA Privacy Rule, and HIPAA Security Rule will be reviewed next.  The Security Rule includes three safeguards components;

• Technical safeguards 
• Physical safeguards   
• Administrative safeguards

 

HIPAA Privacy Rule

HIPAA’s Privacy Rule is in place to ensure that Patient Health Information (PHI) is protected. The Privacy Rule is actually called “Standards for Privacy of Individually Identifiable Health Information.”

• Prompt response – HIPAA legislation allows for a maximum of just 30 days to get back with responses to patient access requests. (Required)

• Notice of privacy practices – An NPP is required to officially inform patients and subscribers of data sharing policies. (Required)

• Privacy training – Medical personnel must be trained to recognize what data can and cannot be shared internally and externally. (Required)

• Ensure data is valid – “Ensure appropriate steps are taken to maintain the integrity of ePHI and the individual personal identifiers of patients,” instructs HIPAA Journal. (Required)

• Get authorization – Obtain permission from any and all patients to use redacted ePHI for research, fundraising, or marketing. (Required)

• Update documentation – All authorization forms should now include a reference to changes in the treatment of school immunizations, ePHI restriction in disclosure to health plans, and the right of patients to access their electronic records. (Required)

 

HIPAA Security Rule

The HIPAA Security Rule defines the requirements for the protection of electronic patient health information.    The Security Rule refers to “Security Standards for the Protection of Electronic Protected Health Information.”      These are ‘safeguards’, and there are three of them;

• Technical       
• Physical       
• Administrative

 

Technical safeguards;

• Network encryption – All ePHI must be encrypted so as to meet NIST cryptographic standards any time it is transmitted over an external network. (Required)
• Control access – Each user is assigned a centrally-controlled unique username and PIN code/password to access the systems. Procedures must also be in place to govern when to release or disclose ePHI if during an emergency. (Required)
• Authenticate ePHI – You must identify and authenticate ePHI and protect it from corruption, unauthorized changes, and accidental destruction. (Recommended)
• Encrypt devices –  All end-point devices that access the system should be able to encrypt and decrypt data.  Critical for mobile and laptop devices. (Recommended)
• Control activity audits – Detailed logging is needed to track all ePHI access attempts and to monitor how ePHI data is manipulated. (Recommended)
• Enable automatic logoff – Users must be auto logged out after a certain set time-frame, usually between 30 seconds and 3 minutes, based on the application or system. (Recommended)

 

Physical safeguards;

• Control facility access – Must carefully track the specific individuals who have physical access to data storage.   This does apply to just health care workers or engineers, but also repair people and even custodians.   A plan of action to block unauthorized entry must be developed. (Required)
• Manage workstations – A policy must be drafted that limits which computer workstations (and other devices) have access to health data, describes how a screen should be guarded from being viewed at a distance, and specifies appropriate workstation use. (Required)
• Remove mobile device ePHI– Define a mobile device policy that deletes ePHI before a device is transferred to another user. (Required)
• Track computer servers – Create an inventory of your server and device infrastructure, including current physical location. Before moving a server or device, data should be copied.  (Recommended)

 

Administrative safeguards;

• Risk assessment – Identify, analyze and define risk elements and probabilistic outcomes.  Complete a comprehensive risk assessment for all health data.   Create and put into place action plans to resolve outcomes in line with the defined risk assessments. (Required)
• Systematic ongoing risk management – Risk assessment is an ongoing process that must be reviewed at regular intervals with recalibrated measures put in place to reduce the risks to an appropriate level. A sanctions policy must be introduced for employees who fail to comply with HIPAA regulations. (Required)
• Train staff – Employees need to be trained on all ePHI access protocols and on  how to recognize potential cybersecurity risks such as phishing, hacking, and deception. A record of these sessions must be kept. (Recommended)
• Build contingencies – Implement ongoing business continuity, responding to potential disasters with a preparation process that keeps data safe. (Required)
• Test contingencies – Test contingency plan(s) on a regular basis, with relation to all key software. A backup system and restoration policy should be adopted. (Recommended)
• Block unauthorized access – Be certain that parties that haven’t been granted access, such as subcontractors or parent companies, cannot view ePHI. Sign business associate agreements with all partners. (Required)
• Document all security incidents – Note that this step is separate from the Breach Notification Rule, which has to do with actual successful hacks. A security incident can be stopped internally before data is breached. Staff should recognize and report these occurrences. (Recommended)

 

Major Changes to HIPAA Since Passage in 1996

There have been four major amendments since 1996:

• The Security Rule Amendment of 2003
  • Technical Safeguards
  • Physical Safeguards
  • Administrative Safeguards
• The Privacy Rule Amendment of 2003
• The Breach Notification Rule of 2009
• The Final Omnibus Rule of 2013

We will focus on the Breach Notification Rule of 2009 next.

 

HIPAA Breach Notification Rule

HIPAA’s Breach Notification rule sets out requirements for notification contact and timing, in the event of a protected health data breach.

• Notification process;   If a breach of ePHI occurs, both patients and the HHS Department must be alerted. If more than 500 patient records are involved, notification of local media is required. If less than 500 patients, execution/submission of a small-scale hack form through the OCR website if required. Smaller breach reports can be delayed, because OCR directives require that small scale breach reports only be made annually.(within sixty days of the close of the calendar year).  Large scale breaches, trigger an immediate notifications including immediate contact of the HHS Secretary by the resident HIPAA CE.  (Required)

• Four breach notification components;  Each breach notification message contains four components; 

• • A description of the ePHI and personal identifiers involved in the breach
  • Name of the party which gained unauthorized access to PHI or related information
  • Distinction of whether ePHI details were visually seen vs removed – viewing vs. acquisition (if known)
  • The degree to which risk mitigation has succeeded. (Required)

 

Consequences of Violating  HIPAA Regulations

There are four levels of violations described by the HIPAA Enforcement Rule, with the fine range is in parenthesis;

1. “Unaware based on reasonable measure” – The entity was unaware and would have   remained unaware based on reasonable measures.     ($100 to $50,000)

2. “Reasonable cause” – in which the violation was caused by an element that would prompt action in an ordinary person.        ($1000 to $50,000)

3. “Willful neglect” – in which the violation was caused by intentional avoidance but rectified within 30 days.   ( $10,000 to $50,000)

4. “Willfull neglect not mitigated” – Willful neglect but not mitigated within 30 days.           ($50,000)

 

What Does HITECH Have to Do With HIPAA Healthcare?

HITECH is the acronym associated with the Health Information Technology for Economic and Clinical Health Act of 2009.  The legislation, signed into law by President Obama on February 17, was intended to accelerate the transition to electronic health records (EHR). It was actually included within the American Recovery and Reinvestment Act of 2009 (ARRA), which was geared toward stimulating the economy during the Great Recession.

The Office of the National Coordinator for Health Information Technology (ONC), part of the HHS Department since 2004, is responsible for the administration and creation of standards related to HITECH.   Of course,  HIPAA hosting providers deploying electronic health records must satisfy the  EHR requirements defined by ONC, while simultaneously complying with the HIPAA Privacy and Security Rules.    Effectively, HITECH is an addendum to HIPAA.

 

HHS HITECH Compliance

Overview

Healthcare organizations across the US understand the importance of the Health Insurance Portability and Accountability Act (HIPAA).  HIPAA, and related legislation, however, has been a ‘moving target’.   HIPAA has had a very positive impact, including prescribing and enforcing the protection and security of patient health records.  Despite this, HIPAA has created  a ‘mountain of work’ for health care providers to deliver on the requirements, and protect themselves from financial sanctions because of an ePHI breach.

 

HIPAA wasn’t always a complex piece of legislation. When introduced and signed by President Clinton in 1996, it was only 337 words.    By 2002, however, HIPAA legislation had grown to over 100,000 words and 500 pages, and healthcare providers were buried.    Many healthcare organizations needed to employ multiple individuals, at each site, just to keep track of new and changing requirements.  

Before we move to a discussion of HITECH, which is the technology related legislation serving as an addendum to HIPAA,  let’s review HIPAA Title II.    

HIPAA and Information Technology/Cloud

Not surprisingly, a HIPAA compliant IT service provider will be most concerned with HIPAA Title II.    Title II establishes and describes these five elements;

• National Provider Identifier Standard – 10-digit NPI (national provider identifier) numbers must be assigned to all healthcare entities.

• Transactions and Code Set Privacy Standard – this objectively approved protocol must be used in electronic data interchange (EDI).

• HIPAA Privacy Rule – Ensuring that Patient Health Information (PHI) is protected. The Privacy Rule is actually short-hand for the “Standards for Privacy of Individually Identifiable Health Information.”

• HIPAA Security Rule – This rule delineates expectations for the safeguarding of patient data. The Security Rule is short-hand for the “Security Standards for the Protection of Electronic Protected Health Information.”

• HIPAA Enforcement Rule – This subsection of the law provides parameters with which companies should be investigated for potential or alleged violations.

The HIPAA Security Rule will be reviewed below.  (For a review of the Privacy Rule and the Enforcement Rule, and penalties for violating HIPAA, please go here;   HHS HIPAA Compliance

The Security Rule includes three safeguards components;

• Technical safeguards 
• Physical safeguards   
• Administrative safeguards

 

HIPAA Security Rule

The HIPAA Security Rule defines the requirements for the protection of electronic patient health information.    The Security Rule refers to “Security Standards for the Protection of Electronic Protected Health Information.”      These are ‘safeguards’, and there are three of them;

• Technical       
• Physical       
• Administrative

 

Technical safeguards;

• Network encryption – All ePHI must be encrypted so as to meet NIST cryptographic standards any time it is transmitted over an external network. (Required)
• Control access – Each user is assigned a centrally-controlled unique username and PIN code/password to access the systems. Procedures must also be in place to govern when to release or disclose ePHI if during an emergency. (Required)
• Authenticate ePHI – You must identify and authenticate ePHI and protect it from corruption, unauthorized changes, and accidental destruction. (Recommended)
• Encrypt devices –  All end-point devices that access the system should be able to encrypt and decrypt data.  Critical for mobile and laptop devices. (Recommended)
• Control activity audits – Detailed logging is needed to track all ePHI access attempts and to monitor how ePHI data is manipulated. (Recommended)
• Enable automatic logoff – Users must be auto logged out after a certain set time-frame, usually between 30 seconds and 3 minutes, based on the application or system. (Recommended)

 

Physical safeguards;

• Control facility access – Must carefully track the specific individuals who have physical access to data storage.   This does apply to just health care workers or engineers, but also repair people and even custodians.   A plan of action to block unauthorized entry must be developed. (Required)
• Manage workstations – A policy must be drafted that limits which computer workstations (and other devices) have access to health data, describes how a screen should be guarded from being viewed at a distance, and specifies appropriate workstation use. (Required)
• Remove mobile device ePHI– Define a mobile device policy that deletes ePHI before a device is transferred to another user. (Required)
• Track computer servers – Create an inventory of your server and device infrastructure, including current physical location. Before moving a server or device, data should be copied.  (Recommended)

 

Administrative safeguards;

• Risk assessment – Identify, analyze and define risk elements and probabilistic outcomes.  Complete a comprehensive risk assessment for all health data.   Create and put into place action plans to resolve outcomes in line with the defined risk assessments. (Required)
• Systematic ongoing risk management – Risk assessment is an ongoing process that must be reviewed at regular intervals with recalibrated measures put in place to reduce the risks to an appropriate level. A sanctions policy must be introduced for employees who fail to comply with HIPAA regulations. (Required)
• Train staff – Employees need to be trained on all ePHI access protocols andon  how to recognize potential cybersecurity risks such as phishing, hacking, and deception. A record of these sessions must be kept. (Recommended)
• Build contingencies – Implement ongoing business continuity, responding to potential disasters with a preparation process that keeps data safe. (Required)
• Test contingencies – Test contingency plan(s) on a regular basis, with relation to all key software. A backup system and restoration policy should be adopted. (Recommended)
• Block unauthorized access – Be certain that parties that haven’t been granted access, such as subcontractors or parent companies, cannot view ePHI. Sign business associate agreements with all partners. (Required)
• Document all security incidents – Note that this step is separate from the Breach Notification Rule, which has to do with actual successful hacks. A security incident can be stopped internally before data is breached. Staff should recognize and report these occurrences. (Recommended)

Please note – these elements were all defined before the creation of HITECH.

 

HITECH As An Addendum to HIPAA

HITECH is the acronym associated with the Health Information Technology for Economic and Clinical Health Act of 2009.  The legislation, signed into law by President Obama on February 17, 2009, was intended to accelerate the transition to electronic health records (EHR). It was actually included within the American Recovery and Reinvestment Act of 2009 (ARRA), which was geared toward stimulating the economy during the Great Recession.

The Office of the National Coordinator for Health Information Technology (ONC), part of the HHS Department since 2004, is responsible for the administration and creation of standards related to HITECH.   Of course,  HIPAA hosting providers deploying electronic health records (EHR) must satisfy the requirements defined by ONC, while simultaneously complying with the HIPAA Privacy and Security Rules.    Effectively, HITECH  is an addendum to HIPAA.

 

Electronic Health Record & Meaningful Use

The HITECH Act included the concept of electronic health records – meaningful use [EHR-MU], an effort led by Centers for Medicare & Medicaid Services(CMS) and the Office of the National Coordinator for Health IT (ONC). HITECH proposed the meaningful use of interoperable electronic health records throughout the United States health care delivery system as a critical national goal.

Meaningful Use(MU) was defined by the following two components;

• use of certified EHR  technology in a meaningful manner (for example electronic prescribing) 
• ensuring that certified EHR technology connects in a fashion that provides for the electronic exchange of health information to improve the quality of care.

By using certified EHR technology(CEHRT), the provider has agreed to submit to the Secretary of Health & Human Services (HHS) information on the quality of care and other measures. The concept of Meaningful Use(MU) rested on the five(5) key components of health outcomes policy priorities, namely:

1.  Improving quality, safety, efficiency, and reducing health disparities
2.  Engage patients and families in their health
3.  Improve care coordination
4.  Improve population and public health
5.  Ensure adequate privacy and security protection for personal health information

Historically, the Meaningful Use directive has consisted of three stages:

• Stage 1 established the basis by establishing requirements for the electronic capture of clinical data, including providing patients with electronic copies of health information.
• Stage 2 expanded upon the Stage 1 criteria with a focus on advancing clinical processes and ensuring that the meaningful use of EHRs supported the aims and priorities of the National Quality Strategy. Stage 2 criteria encouraged the use of Certified Electronic Health Record Technology (CEHRT) for continuous quality improvement at the point of care and the exchange of information in the most structured format possible.
• In October 2015, CMS released a final rule that established Stage 3 in 2017 and beyond, which focused on using CEHRT to improve health outcomes.

Quality Payment Program (QPP) Precursor – Sustainable Growth Rate (SGR)

Prior to the Quality Payment Program (QPP), payment increases for Medicare services were set by the Sustainable Growth Rate (SGR) law. This capped spending increases according to the growth in the Medicare population, and a modest allowance for inflation.  However, as clinicians increased their utilization of services, the reimbursement for each unit of service had to be adjusted downward to hold costs constant. As a result, the SGR  would have resulted in large decreases in the Physician Fee Schedule, which was not sustainable. To avoid these decreases in reimbursement,  Congress had to pass a new law every year authorizing the current fee schedule and a small increase for inflation. 

The Quality Payment Program (QPP) Became Operational January 1, 2017.

In 2015, Congress passed the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA).  This law eliminated SGR, and replaced it with the Quality Payment Program.   The new focus is to reward high-value, high-quality Medicare providers with payment increases, while at the same time reducing payments to those providers who aren’t meeting performance standards. 

Of course, without the implementation of Certified Electronic Health Record Technology (CEHRT), the QPP would have been impossible, given the missing electronic health records which server as the basis for QPP metrics. 

Clinical providers now have two tracks to choose from, as defined in the Quality Payment Program based on their practice size, specialty, location, or patient population:

• Merit-based Incentive Payment System (MIPS) or
• Advanced Alternative Payment Models

MIPS goes into effect based on minimum threshold volumes (patients and dollars charged to CMS).    The advanced APM  is a track of the Quality Payment Program that offers a 5 percent incentive for achieving threshold levels of payments or patients.

 

 

 

 

 

 

 

What are the PCI DSS  Requirements (Control Objectives) ?

Control Objectives  –  PCI DSS Requirements

PCI compliance requirements are built around  six “control objectives,” and each of these objectives has sub-requirements  that organizations must follow. A total of 12 compliance sub-requirements complement the six control objectives.  The summary may be found below:

1. Build and Maintain a Secure Network

• a. Install and maintain a firewall configuration to protect cardholder data.
• b. Do not use vendor-supplied defaults for system passwords and other security parameters.

2. Protect Cardholder Data

• a. Protect stored data.  
• b. Encrypt transmission of cardholder data across open, public networks.

3. Maintain a Risk/Vulnerability Management Program

• a. Use and regularly update anti-virus software.  
• b. Develop and maintain secure systems and applications.

4. Implement Strong Access Control Measures

• a. Restrict access to cardholder data by business need-to-know.  
• b. Assign a unique ID to each person with computer access.  
• c. Restrict physical access to cardholder data.

5.  Establish a Comprehensive Monitoring Solution

• a. Track and monitor all access to network resources and cardholder data.
• b. Regularly test security systems and processes.

6. Maintain an Information Security Policy

• a. Maintain a policy that addresses information security.

Expanded Review of Requirements (Prescriptive)

 

 

How Does the Transaction Volume Impact PCI-DSS Compliance?

PCI compliance requirements applicable to a merchant/organization are highly dependent on how many credit, debit and pre-paid card transactions are processed by them each year. The greater the number of transactions, the higher the level of required compliance and compliance validation.   Two use cases next;

• More than 6 million transactions per year;    merchant must hire a specially trained assessor (PCI QSA) to conduct an audit every year.   
• Less than 6 million transactions per year;    merchants may not required to perform an audit, but must perform quarterly network scans to look for signs of trouble.

 As we will see below, there are exceptions triggering an audit requirement, for transactions less than six   million (see  Four PCI-DSS Compliance Levels, Based on Transaction Volume, & Source Vendor  ).  Both American Express and  JCB (Japan Credit Bank) trigger Site Audits at lower transaction levels, than Visa, Mastercard, or Discover. 

 

 

What are the Four PCI Transaction Levels?

• Level 1:     > 6 milion transactions/year   
• Level 2:     1 million to 6 million transactions/year   
• Level 3:     20,000 to 1 million transactions/year  
• Level 4:     < 20,000 transactions/year

 

What are the Major Possible Components of PCI DSS Compliance, and the Deliverable Form?

• Self-Assessment Questionnaire  (SAQ)
• Attestation of Compliance  
• Quarterly Network Scans  
• Report on Compliance  
• Annual Audit  
• Special Situations & Elevated Compliance Requirements

 

When Do I Need to Select a PCI QSA  Firm ?

When an annual audit is required for PCI DSS compliance, it must be performed by a Payment Card Industry Qualified Security Assessor (PCI QSA) company.    A PCI QSA is certified by the PCI Security Standards Council to audit merchants for PCI DSS compliance.

The PCI Security Standards Council maintains a list of all the individuals and companies that have successfully completed training and certification as a PCI QSA.

A PCI compliance audit automatically applies to PCI level 1 compliance entities  –  those with more than 6 million transactions/year.  

Organizations that must complete a self-assessment questionnaire (SAQ) can voluntarily request the assistance of a PCI QSA  firm.   Voluntary interaction with a competent PCI QSA company can assist a  merchant  in becoming more cognizant of compliance requirements in the light of business/operational goals.   The PCI Security Standards Council website provides a list of certified PCI QSAs.

 

What is a SAQ?   How Many Different Types of SAQ’s are There ?

A SAQ is a self-assessment questionnaire.   There are eight of them, below.

• A:    Card-not-present merchants (mail/telephone-order or e-commerce) who have completely  outsourced all cardholder data processing to a third-party vendor and do not store, process or  transmit any cardholder data on their systems or premises 

• A-EP:   E-commerce merchants who partially outsource all payment processing to a PCI DSS compliant firm.

•  B:    Merchants who do not store any electronic cardholder data and process payments either via standalone terminals. 

•  B-IP:  Merchants who process online payments using only standalone , PTS-approved payment terminals.

•  C:     Merchants with payment application systems connected to the Internet and no electronic cardholder data storage.

• C-VT:   Merchants who externally host a web payment application hosted by a PCI DSS validated  third-party service provider. These types of merchants use a virtual payment terminal solution   with no electronic cardholder data storage.

• D:    Merchants not included in descriptions for the above SAQ types.   Applicable to all service  providers defined by a payment brand as eligible to complete an SAQ.

•  P2PE:   Merchants who process card data only via payment terminals included in a validated and  PCI SSC-listed Point-to-Point Encryption (P2PE) solution. No electronic cardholder data storage.

 

For each of the eight(8) Self-Assessment Questionnaires(SAQ’s), the number of questions to be answered may be found below;        { Note that D has been divided into two categories below }