This section covers data privacy and security as the topics relate to research registries.
Any research registry wishing to incorporate data from the electronic health record (or paper health record, if you’re going back that far!) will need to consider the substantial protections around the use of such data. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) established the need for a set of standards for the protection of individuals’ health information. Those protections are addressed in the “Standards for Privacy of Individually Identifiable Health Information,” or the “Privacy Rule” for short. We will not attempt to cover the entirety of the Privacy Rule here, but will instead summarize the portions relevant for a researcher wishing to keep research registry data safe and compliant. Those looking for more detailed information can find it at https://www.hhs.gov/sites/default/files/privacysummary.pdf
The Privacy Rule defines protected health information, or PHI, as “information, including demographic data, that relates to:
The purpose of the Privacy Rule is to define when it is and is not acceptable to use or disclose PHI. With proper approvals in place, research can be one of these acceptable uses.
SUMMARY OF THE HIPAA PRIVACY RULE. Available at: https://www.hhs.gov/hipaa/index.html. Accessed April 27, 2018;
HIPAA applies to identified datasets, but does not apply when a dataset is completely deidentified. A common point of confusion, however, is what it means to be deidentified by HIPAA’s standards. (Moreover, by definition, a research registry is very unlikely to be deidentified.)
Under HIPAA, a dataset is considered deidentified only if that dataset does not contain any of the following identifiers:
The inclusion of even one of these 18 identifiers effectively makes a dataset sourced from the electronic health record identifiable and subject to HIPAA.
This might be true, but only if all other HIPAA identifiers are also removed. A common point of confusion is dates of service, such as admission date or diagnosis date. Even if there are no other identifiers in the dataset, having a date of service present in the dataset means that it cannot be considered deidentified.
There are many ways to use PHI for research purposes in a compliant way. If your registry includes an informed consent process before any participant data is collected, then (depending on the language in your consent form) participants may be able to give you permission to use their medical records for research purposes. On the other hand, if your registry incorporates patients who have not given specific consent for use of their PHI, the Privacy Rule permits use of PHI for research purposes under the following circumstances:
So much focus on HIPAA may lead one to believe that any identifiable fact about a person that relates to their health or treatment and is collected as part of a research study is PHI. However, this is not the case. Remember that HIPAA applies to covered entities (e.g. health care providers) that conduct specified transactions electronically (such as billing your insurance for your visit). PHI (data subject to HIPAA) is created in the course of providing health care services when those services involve such transactions. When a researcher is not also functioning as a health care provider and creates individually identifiable health information (IIHI) in connection with pure research activities (no patient care involved), the information is not PHI. But, if a researcher is also a health care provider and IIHI is created in connection with the researcher’s health care provider activities, then the IIHI is PHI, and is subject to HIPAA.
Once you’re dealing with PHI, then it may only be used or disclosed for research purposes (including to the clinical investigator who provided the services) under a valid HIPAA permission, such as the patient’s individual authorization or an IRB waiver of HIPAA authorization. This applies to all data that is sourced from the electronic health record.
So (for example), if the data captured in your research registry is composed solely of consented, identified participants’ answers to survey questions that you collect from the subject directly and that have nothing to do with the delivery of health care services, then your data is IIHI research data, but not PHI. With that said, any identifiable data should be treated with the utmost care, consistent with IRB requirements and University policy, whether or not it is subject to HIPAA.
Whether your registry contains protected health information governed by HIPAA or contains other types of identifiable research data, ensuring the physical security of that data is of paramount importance. Most studies no longer rely on the “locked filing cabinet” as a sole means of data security; rather, most registries now involve some kind of electronic data capture and/or storage. It’s not necessary to be an IT security guru in order to ensure compliance,however, IT security is an area where relying as much as is feasible on the infrastructure and services already provided by your institution is nearly always advisable.
Most of us have heard our IT colleagues reacting with horror upon discovering that a researcher or staffer is operating their own server (under their desk or otherwise!). Ever wonder why? The reason is simple: your organization’s IT professionals have many processes and procedures in place to make sure all the servers they control are up-to-date with patches, free from vulnerabilities, monitored for suspicious activity, and protected from unauthorized access. In order to implement these protections, however, servers need to be managed by an institution’s IT group—not by an individual investigator or research team.
By going with a managed solution like REDCap, most of the remaining IT security considerations that fall under the study team’s responsibility are appropriate access to and use of data. After all, even the best IT security setup won’t prevent a user from misusing data they can access, whether accidentally or intentionally.
Keep the following tips in mind to ensure that everyone on the study team is accessing and using data appropriately:
**Find more information on UNC- Chapel Hill’s approved methods of PHI transfer at: https://unc.policystat.com/policy/4619518/latest/. If you need help interpreting these guidelines, ask your departmental IT staff, or request a consult from NC TraCS Informatics.
REDCap is managed by the NC TraCS Institute in collaboration with UNC-Chapel Hill’s Information Technology Services (ITS). So, if you opt to use REDCap to create and store your registry (which we recommend!), you won’t need to worry about some of the stickier IT security concerns; TraCS and ITS are on it! If you choose not to use REDCap for your registry, talk with your department’s IT representative about any available options for a “managed” database solution for your registry, or request a consult from NC TraCS Informatics.
Questions? Contact us at nctracs@unc.edu or 919-966-6022.
© 2019-2022. The NC TraCS Institute is the integrated hub of the NIH Clinical and Translational Science Awards (CTSA) Program at the University of North Carolina at Chapel Hill. The Registry Toolkit website is supported by the National Center for Advancing Translational Sciences (NCATS), National Institutes of Health, through Grant Award Number UL1TR002489. The content is solely the responsibility of the authors and does not necessarily represent the official views of the NIH. | accessibility