网红头条

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) and its regulations, including the Privacy Rule and the Security Rule, as well as the Health Information Technology for Economic and Clinical Health (HITECH) Act, govern the way certain health information is collected, maintained, used, and disclosed. The Privacy Rule establishes a set of safeguards around certain types of health information known as Protected Health Information (PHI) and sets forth a national minimum level of protection for PHI. It also describes ways in which a Covered Entity can use or disclose PHI for research purposes.

It is the opinion of the US Department of Health and Human Services (HSS) that the protections for Protected Health Information by the Security Rule will encourage participation.
Learn more at the HHS FAQ entries for . 

Protected Health Information (PHI) is individually identifiable health information that is held or transmitted by a Covered Entity, whether verbal or recorded in any form or medium (e.g., narrative notes; X-ray films or CT/MRI scans; EEG / EKG tracings, etc.), that may include demographic information. PHI identifies the individual directly or contains sufficient data so that the identity of the individual can be readily inferred. PHI includes what physicians and other health care professionals typically regard as a patient's personal health information, such as information in a patient's medical chart or a patient's test results, as well as an individual's billing information for medical services rendered, when that information is held or transmitted by a covered entity. PHI also includes identifiable health information about subjects of clinical research gathered by a researcher who is a covered health care provider.

Note: Electronic Protected Health Information (ePHI) is PHI that is produced, saved, transmitted or received in an electronic form.

There are instances where a project can work with health information but is not protected by HIPAA.  Consider the following example.  If your project collects health information via a survey directly from the research subject, then this is considered self-reporting and does not require the researcher to follow the HIPAA Privacy Rule.  Please note, if the information that was self-reported is to be added to the subject鈥檚 medical record at a Covered Entity, then HIPAA compliance is required.

If you want to discuss your project and its data, start a ticket with .

A de-identified data set is PHI from which the following identifiers of the individual or of relatives, employers, or household members of the individual, have been removed:

• Names
• All geographic subdivisions smaller than a State
• All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older
• Telephone numbers
• Fax numbers
• Electronic mail addresses
• Social security numbers
• Medical record numbers
• Health plan beneficiary numbers
• Account numbers
• Certificate/license numbers
• Vehicle identifiers and serial numbers, including license plate numbers
• Device identifiers and serial numbers
• Web Universal Resource Locators (URLs)
• Internet Protocol (IP) address numbers
• Biometric identifiers, including finger and voice prints
• Full face photographic images and any comparable images; and any other unique identifying number, characteristic, or code;

A data set with the above mentioned identifiers removed is termed a "safe harbor" data set and should be used whenever possible.

Please note: A data set may not be considered de-identified by the removal of these fields alone.  Consider whether the remaining information could be used alone or in combination with other information to identify the subject of the information. 

The least information reasonably necessary to accomplish the intended purpose of the use, disclosure, or request of PHI. For both healthcare and for research, HIPAA requires that PHI be communicated on a need to know and minimum necessary basis.

Covered entities are defined in the HIPAA rules as (1) health plans, (2) health care clearinghouses, and (3) health care providers who electronically transmit any health information in connection with transactions for which HHS has adopted standards. Generally, these transactions concern billing and payment for services or insurance coverage. 

A 鈥渂usiness associate鈥� is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.  A member of the covered entity鈥檚 workforce is not a business associate.  A covered health care provider, health plan, or health care clearinghouse can be a business associate of another covered entity.  The Privacy Rule lists some of the functions or activities, as well as the particular services, that make a person or entity a business associate, if the activity or service involves the use or disclosure of protected health information. The types of functions or activities that may make a person or entity a business associate include payment or health care operations activities, as well as other functions or activities regulated by the Administrative Simplification Rules.  

Business associate functions and activities include: claims processing or administration; data analysis, processing or administration; utilization review; quality assurance; billing; benefit management; practice management; and repricing.  Business associate services are: legal; actuarial; accounting; consulting; data aggregation; management; administrative; accreditation; and financial. See the definition of 鈥渂usiness associate鈥� at .

HIPAA (& HITECH) requires that research involving PHI use physical, technical and administrative safeguards to protect confidentiality.  A project may need to implement protections from any or each of the areas

If you have questions about your particular project and HIPAA compliance, please reach out to the  to discuss with members from the Office of Reseach and UITS.  

Physical safeguards include storing of person-identifiable data in locked file cabinets, and restriction of access only to those project staff who have a need to access the files. Paper records must not be kept in public areas where passers-by may inadvertently see their content.

The Physical Safeguards focus on physical access to ePHI irrespective of its location. ePHI could be stored in a remote data center, in the cloud, or on servers which are located within the premises of the HIPAA covered entity. They also stipulate how workstations and mobile devices should be secured against unauthorized access:

• Facility access controls must be implemented (addressable) 鈥� Procedures have to be introduced to record any person who has physical access to the location where ePHI is stored. This includes software engineers, cleaners and even a handyman coming to change a light bulb. The procedures must also include safeguards to prevent unauthorized physical access, tampering, and theft.
• Policies relating to workstation use (required) 鈥� Policies must be devised and implemented to restrict the use of workstations that have access to ePHI, to specify the protective surrounding of a workstation (so that the screen of a workstation cannot be overlooked from an unrestricted area) and govern how functions are to be performed on the workstations.
• Policies and procedures for mobile devices (required) 鈥� If mobile devices are to be allowed access to ePHI, policies must be devised and implemented to govern how ePHI is removed from the device before it is re-used.
• Inventory of hardware (addressable) 鈥� An inventory of all hardware must be maintained, together with a record of the movements of each item. A retrievable exact copy of ePHI must be made before any equipment is moved. 

The difference between the 鈥渞equired鈥� safeguards and the 鈥渁ddressable鈥� safeguards on this HIPAA compliance list is that 鈥渞equired鈥� safeguards must be implemented whereas there is a certain amount of flexibility with 鈥渁ddressable鈥� safeguards. If it is not reasonable to implement an 鈥渁ddressable鈥� safeguard as it appears on the HIPAA compliance checklist, covered entities have the option of introducing an appropriate alternative, or not introducing the safeguard at all.

Technical safeguards apply to computer systems where PHI is stored, and include, for example, use of password-protected access, screensavers that have a timeout such that when a user walks away from the computer, locking access after a period of time, and audit trails that record who has created or changed PHI data in the system. Wherever feasible, personal-identifiable elements of the computerized research records should be stored separately, and if feasible, in an encrypted format.

The Technical Safeguards concern the technology that is used to protect electronic Protected Health Information (ePHI) and provide access to the data. The only stipulation is that ePHI 鈥� whether at rest or in transit 鈥� must be encrypted to NIST standards once it travels beyond an organization麓s internal firewalled servers. This is so that any breach of confidential patient data renders the data unreadable, undecipherable and unusable. Thereafter organizations are free to select whichever mechanisms are most appropriate to:

• Implement a means of access control (required) 鈥� This not only means assigning a centrally-controlled unique username and PIN code for each user, but also establishing procedures to govern the release or disclosure of ePHI during an emergency.
• Implement tools for encryption and decryption (addressable) 鈥� This guideline relates to the devices used by authorized users, which must have the functionality to encrypt messages when they are sent beyond an internal firewalled server, and decrypt those messages when they are received.
• Introduce activity audit controls (required) 鈥� The audit controls required under the technical safeguards are there to register attempted access to ePHI and record what is done with that data once it has been accessed.
• Facilitate automatic logoff (addressable) 鈥� This function 鈥� although only addressable 鈥� logs authorized personnel off of the device they are using to access or communicate ePHI after a pre-defined period of time. This prevents unauthorized access of ePHI should the device be left unattended.

The difference between the 鈥渞equired鈥� safeguards and the 鈥渁ddressable鈥� safeguards on this HIPAA compliance list is that 鈥渞equired鈥� safeguards must be implemented whereas there is a certain amount of flexibility with 鈥渁ddressable鈥� safeguards. If it is not reasonable to implement an 鈥渁ddressable鈥� safeguard as it appears on the HIPAA compliance checklist, covered entities have the option of introducing an appropriate alternative, or not introducing the safeguard at all.

The administrative safeguards include:

• Conducting risk assessments (required) 鈥� Among the Security Officer麓s main tasks is the compilation of a risk assessment to identify every area in which ePHI is being used, and to determine all of the ways in which breaches of ePHI could occur.
• Introducing a risk management policy (required) 鈥� The risk assessment must be repeated at regular intervals with measures introduced to reduce the risks to an appropriate level. A sanctions policy for employees who fail to comply with HIPAA regulations must also be introduced.
• Training employees to be secure (addressable) 鈥� Training schedules must be introduced to raise awareness of the policies and procedures governing access to ePHI and how to identify malicious software attacks and malware. All training must be documented.
• Restricting third-party access (required) 鈥� It is the role of the Security Officer to ensure that ePHI is not accessed by unauthorized parent organizations and subcontractors, and that Business Associate Agreements are signed with business partners who will have access to ePHI.
• Reporting security incidents (addressable) 鈥� The reporting of security incidents is different from the Breach Notification Rule (below) inasmuch as incidents can be contained and data retrieved before the incident develops into a breach. Nonetheless, all employees should be aware of how and when to report an incident in order that action can be taken to prevent a breach whenever possible.
  
  The difference between the 鈥渞equired鈥� safeguards and the 鈥渁ddressable鈥� safeguards on this HIPAA compliance list is that 鈥渞equired鈥� safeguards must be implemented whereas there is a certain amount of flexibility with 鈥渁ddressable鈥� safeguards. If it is not reasonable to implement an 鈥渁ddressable鈥� safeguard as it appears on the HIPAA compliance checklist, covered entities have the option of introducing an appropriate alternative, or not introducing the safeguard at all.

No, the data cannot be shared outside of the project team without a new IRB review , a new data use agreement and a new waiver of authorization if required initially.

The determination of whether an individual researcher must comply with the Privacy Rule is a fact-sensitive, individualized determination. The answer to this question may depend on how the entity with which a researcher has a relationship is organized. If you have questions about the Privacy Rule, please contact the KSU Service Desk and get connected with the regulated research team.

HHS has developed a set of tools to help an entity determine whether it is a health plan, a health care clearinghouse, or a covered health care provider that will be subject to the Privacy Rule.

To discuss your particular project or ask questions concerning HIPAA and research, contact Tom Boyle (Office of Research, HIPAA Compliance Officer) at tboyle@kennesaw.edu.

If you are part of the project associated with a breach or leak, please communicate directly with the Primay Investigator as soon as possible.  If you cannot reach the PI or if you suspect a breach or leak and the PI is unknown, contact the .

Any PI that learns of a breach or leak associated with their project should contact the IRB that reviewed your protocol and the .

• HHS:
• NIH: 
• HHS: 
• KSU: Data Management Plan Examples and Resources
• KSU: