This page houses the data governance policies and procedures developed by the NACHC Clinical Affairs team in partnership with other NACHC teams and external partners. These policies and procedures can be applied to any activities where data is received, collected, or generated, referred to as 'data sharing work' hereinafter.
What Does Data Governance Mean to NACHC?
Data governance is central to effective data sharing work. NACHC defines data governance as a framework to guide the usability, integrity and security of data and to instill trust in the use of data and data-related sources across systems. At NACHC, the data governance infrastructure encompasses a decision-making body, rules (policies and procedures), decision rights (how we “decide how to decide”), accountabilities, and enforcement methods for people and information systems as they perform information-related processes.
There are four domains of governance that are relevant to NACHC's informatics work: data governance, information governance, software governance, and partnership governance. While these policies and procedures are focused on data governance, some aspects of information governance, software governance, and partnership governance may be relevant.
Within those domains, NACHC adheres to eight governance principles: accountability, transparency, integrity, protection, compliance, availability, retention, and disposition as identified by the American Health Information and Management Association (AHIMA). Definitions of each are available on a related site. Relevant topics within each governance domain are addressed below.
Section 1: Governance Approach
Data Governance Decision-Making
NACHC's organization-wide data management, privacy, and security practices and infrastructure is directed and managed by the information technology (IT) department. Within that context, NACHC operates a Data Governance Council ('GC') to advise on data-sharing work which may be housed within the Clinical Affairs Division (CAD) or led by other divisions. The GC does not provide direct project oversight, but does make recommendations and decisions about project participation, implementation, and the technical architecture used to carry out data sharing work. A description of the NACHC technical architecture is available here.
The GC meets monthly and includes members who represent 1) NACHC leadership, regulatory, and analytic staff, and 2) external data partners and project partners who represent a range of perspectives and collective expertise in clinical care, informatics, data science, and population health. Details of the GC membership, scope, and operations are defined in a charter.
Roles
NACHC conducts data sharing work in partnership with data partners and project partners.
A data partner is an organization owning and/or sharing data with NACHC which can include organizations providing direct health services such as federally qualified health centers (FQHCs), primary care associations (PCAs), or health center controlled networks (HCCNs). FQHCs are data owners in that they own the data collected by their organization. PCAs and HCCNs do not collect clinical data but serve as a data steward for clinical data provided by their members and contribute data on behalf of their member organizations. Federal agencies such as the Health Resources and Services Administration may also be data partners, providing data to NACHC on behalf of FQHCs (example: UDS data).
A project partner is an organization who participates in or supports data sharing work by providing subject matter expertise, funding, vendor services, or other technical assistance. Vendor services may include analysis which can require direct access to project data.
Project Structure
NACHC organizes and tracks data sharing work in projects. Depending on the scope of the project, a project may have one or multiple datasets from one or more data partners that is housed by NACHC. Most projects use Confluence to manage information and safely share data through a Confluence website which defines the project team, provides links to relevant project documentation and agreements, location of project data, and tracks project progress. Projects have regular status meetings. Minutes and meeting materials from status meetings are made available on Confluence. At the start of each project, a project team is identified and includes members of the data contributor and NACHC staff and documented on the project Confluence page. Additionally, members of the project team who will have access to project data are identified at the project inception. As the project team evolves through the project lifecycle, the project team is updated on Confluence and in project-related documentation, as appropriate.
Services
NACHC's data sharing work includes the following services: subject matter expertise, technical assistance, data management, and analysis services, which are defined in the table below. Most informatics projects involve multiple informatics services.
...
- Providing guidance materials and sharing knowledge with data partners on how best to collect, store, and use their data
- Sharing best practices from the field
- Creating and sharing tools for a specific use case
- Identifying translatable resources
...
- Coaching and assisting data partners to improve the quality of their data collection and use
- Providing educational programming to cultivate knowledge and build capacity with partners
- Coaching external and internal requestors in refining analytic requests to be more actionable and purpose driven
- Improving the use and quality of analytic planning and documentation
...
- Receiving, normalizing, and transforming data from partners into a format and structure aligned with analytic goals
- Mapping and normalizing disparate data structures and formats into a common data model
- Conducting data quality activities and identifying data quality issues
- Performing analysis on one or multiple datasets to assess a prescribed outcome or outcomes (e.g., the percent of women who received contraception counseling)
- Calculate a quality measure (e.g., the percent of screening-eligible patients who were screened)
*Technical Assistance and Analysis can involve the support of contractors or other project partners. AT Still University is frequently used for advanced statistical methods.
Section 2: Data
Data is either collected by NACHC or owned by another organization and shared with NACHC, where NACHC acts as a data steward.
Data Collected by NACHC
For some projects, NACHC collects its own data, usually in the form of surveys that are completed by health centers or member information. These surveys will be anonymous and do not collect patient identifiers if received or held directly by NACHC. Need to expand this.
Data Shared with NACHC
There are many types of data that may be shared with NACHC including UDS data, clinical data, and financial data.
UDS Data
NACHC receives UDS data from HRSA that includes health-center level information on a variety of topics including services, staff, capacity, and financial data so that NACHC can perform analyses on behalf of HRSA and FQHCs to describe the health center landscape and services. The UDS data that NACHC receives includes some data that is available publicly and some sensitive data that only NACHC holds. UDS data does not contain PHI but is sensitive and requires physical, technical, and administrative safeguards.
Sharing UDS data with NACHC occurs under a cooperative agreement with HRSA which is overseen by the Director of Knowledge Management and Learning (Currently Margaret Davis). The parameters of UDS data sharing and use are defined in two HRSA agreements (Authorization letter, NACHC DUA). Included in these documents are explicit directions about how findings from the UDS data should be communicated in a way that protects the identity of health centers and their patients.
The UDS data is stored securely at NACHC (currently in Amazon cloud). Only NACHC staff who have signed a UDS specific DUA are permitted to access and use the UDS data. Once a DUA has been executed with an individual and access granted to the UDS datasets, all uses of UDS data must be approved by the UDS Program Director.
Clinical Data
NACHC receives clinical data primarily extracted from EHRs at the patient level. These clinical data are bound by HIPAA and can fall into the below categories.
De-identified data is data that has been “stripped of all HIPAA defined identifiers” which includes Personally Identifiable Information (PII) and Protected Health Information (PHI). PII is a subset of PHI and the list of 18 data elements that are considered PHI are documented in the HIPAA Safe Harbor definition. To be considered de-identified under HIPAA, all 18 identifiers must be removed. Some data partners participate in date-shifting to remove real encounter and birth dates Julia Skapik (Deactivated) remove this?
A limited data set (LDS) includes data that has been stripped of all 18 HIPAA identifiers, except age, full dates, and five digit zip code, as identified by HIPAA Safe Harbor guidelines.
Identified data sets which include PHI identified beyond that which would qualify as an LDS and are not accepted by NACHC at this time.
Financial Data
Others?
Requests for Data
NACHC receives many requests for data that has already been shared with them for an existing project or a request for data related to a new project. Additionally, NACHC receives requests for information partnership meaning a desire from one organization to partner and share data with a health center through support from NACHC.
Requests for data or information partnerships are evaluated by the GC which meets monthly. Requests can be submitted here. Requests must include a detailed description of what data is desired, how the data will be used, the type of use (e.g., research, surveillance, quality improvement or other) and how the request aligns with the NACHC vision. Incomplete requests cannot be evaluated and will be returned to the requester. Requesters will be notified of an approval or denial within one week of the GC meeting.
Section 3: Statutes, Contracts, and Regulatory
Contracts
At NACHC, Contracts and DUAs are separate....
HIPAA
According to HIPAA, NACHC is not a covered entity. However, NACHC receives limited and de-identified datasets from HIPAA covered entities. Though the amount of PHI received by NACHC is minimal, NACHC treats all of its data from covered entities as PHI and as such, complies with the relevant security and privacy expectations outlined by HIPAA.
TEFCA
Launched in January 2022, TEFCA provides a framework for networks to collaborate and share data interoperable. Network to network collaboration has many similarities to NACHC's informatics work. Thus, NACHC seeks to align with TEFCA when applicable and feasible.
Data Use Agreements (DUAs)
NACHC requires the execution of a data use agreement (DUA) whenever data is being shared with NACHC. For projects where a LDS is being shared, a DUA is required by HIPAA. For projects where deidentified data is being shared, a DUA is executed based on NACHC policy.
NACHC observes the HIPAA Privacy Rule standards for a DUA. The purposes of a DUA are to:
- establish the permitted uses and disclosures of the limited data set;
- identify who may use or receive the information;
- prohibit the recipient from using or further disclosing the information, except as permitted by the agreement or as permitted by law;
- require the recipient to use appropriate safeguards to prevent a use or disclosure that is not permitted by the agreement;
- require the recipient to report to the covered entity any unauthorized use or disclosure of which it becomes aware;
- require the recipient to ensure that any agents (including a subcontractor) to whom it provides the information will agree to the same restrictions as provided in the agreement; and
- prohibit the recipient from identifying the information or contacting the individuals.
Because DUA's require a high level of specificity, each DUA is project-specific. DUAs can be two party, meaning between NACHC and a data contributor, or multi-party, meaning between NACHC and multiple parties. The structure and contents of a DUA are customized based on project structure and needs.
- When NACHC is the provider of data to an outside organization: NACHC has created a DUA template for use with to recipients. This template may be accessed from the NACHC contracts office. When NACHC is providing a LDS, if any material change is to be made to the NACHC template, or if another party’s version of a DUA is to be used, the NACHC legal council must review and approve the terms of the agreement.
- When NACHC is the recipient of the data: If NACHC is the recipient of a LDS of PHI from a non-NACHC source, the NACHC project lead with either use the NACHC DUA template or modify the other party’s Data Use Agreement. When using another party's DUA, the NACHC project lead is responsible for reviewing the Data Use Agreement and determining if it complies in material terms with the NACHC DUA template. If the other party’s DUA differs materially from the NACHC DUA template, or if there is any uncertainty, the NACHC legal council must be consulted.
NACHC has a DUA template that has been approved by NACHC legal council. Alternatively, data partners are welcome to request the use of their institutional DUA template that can be customized for the project by NACHC staff. A process to initiate a DUA is documented below.
- NACHC project lead completes the NACHC DUA Checklist to determine if a DUA is needed. This should occur as part of the project's initiation.
- The checklist is reviewed with data partner at an early project meeting to confirm the need for a DUA and level of identification of a dataset.
- Once completed, the DUA checklist is stored in the project Confluence page.
- If the DUA checklist identified a need for a DUA, the checklist is shared with the NACHC contract officer to begin the creation of a project-specific DUA.
- NACHC populate the DUA with project specific information and share with other parties for comment
- NACHC receives and integrates comments and recirculates to other parties and NACHC legal until DUA is ready for signature
- DUA is signed by other party(ies) and returned to NACHC for counter signature and execution
- DUA is executed by NACHC legal and executed agreement is shared with all parties
Section 4: Work Products
Work Products and Attribution
Informatics work generates the following work products: data quality results, analytic results, value sets, measure definitions, and recommendations. Work products are owned by all members of the project team and can be disseminated in manuscripts, abstracts, reports, presentations, and guidance documents. How and to whom work products are attributed is discussed with all project partners at the outset and as the project evolves to ensure that attribution of work projects is accurate and equitable.
DEI in Work Products
TBD. Need some guidance here.
Identification of Health Centers in Work Products
TBD. Need some guidance here.
Section 5: Data Security, Privacy, and Confidentiality
Patient data has become increasingly valuable to potential attackers. The rapid and continuous evolution of both healthcare information technology and attacker tools makes data security a constantly moving target, with methods of protection struggling to stay in front of attack efforts. NACHC believes that the security, privacy, and confidentiality of patient and health center data is of paramount importance. As such, NACHC takes a number of steps to ensure data security, protect their environment from security threats, and address security incidents when they occur. A summary of NACHC's data security and privacy policies are available here.
NACHC adheres to data security standards defined in the HIPAA security rule (45 CFR Part 160), the National Institute of Standards and Technology (NIST) Cybersecurity Framework, and the Common Agreement (Section 12), Not every part of these three resources apply directly to NACHC's informatics work, thus NACHC complies and aligns with them to the degree that they apply.
Section 6: Research
The following topics apply specifically to NACHCs use of data for human subjects research. The federal regulations define both "research" and "human subject." Studies must be reviewed by an Institutional Review Board (IRB) only if both definitions apply. A project may involve data from human subjects, but not meet the definition of research and would, therefore, not require an IRB review. Research is defined by federal regulations at 45 CFR 46.102 (Protection of Human Subjects 2009), as "a systematic investigation including research development, testing, and evaluation, designed to develop or contribute to generalizable knowledge."
Primary Investigator
NACHC projects which are research in nature have a defined primary investigator (PI) who is responsible for ensuring the project adheres to research policies. The PI leads and manages the research team engaged in any part of the research project. NACHC PIs complete a battery of research related training with the CITI program.This page houses the data governance policies and procedures developed by the NACHC Clinical Affairs team in partnership with other NACHC teams and external partners. These policies and procedures can be applied to any activities where data is received, collected, or generated, referred to as 'data sharing work' hereinafter.
What Does Data Governance Mean to NACHC?
Data governance is central to effective data sharing work. NACHC defines data governance as a framework to guide the usability, integrity and security of data and to instill trust in the use of data and data-related sources across systems. At NACHC, the data governance infrastructure encompasses a decision-making body, rules (policies and procedures), decision rights (how we “decide how to decide”), accountabilities, and enforcement methods for people and information systems as they perform information-related processes.
There are four domains of governance that are relevant to NACHC's informatics work: data governance, information governance, software governance, and partnership governance. While these policies and procedures are focused on data governance, some aspects of information governance, software governance, and partnership governance may be relevant.
Within those domains, NACHC adheres to eight governance principles: accountability, transparency, integrity, protection, compliance, availability, retention, and disposition as identified by the American Health Information and Management Association (AHIMA). Definitions of each are available on a related site. Relevant topics within each governance domain are addressed below.
Section 1: Governance Approach
Data Governance Decision-Making
NACHC's organization-wide data management, privacy, and security practices and infrastructure is directed and managed by the information technology (IT) department. Within that context, NACHC operates a Data Governance Council ('GC') to advise on data-sharing work which may be housed within the Clinical Affairs Division (CAD) or led by other divisions. The GC does not provide direct project oversight, but does make recommendations and decisions about project participation, implementation, and the technical architecture used to carry out data sharing work. A description of the NACHC technical architecture is available here.
The GC meets monthly and includes members who represent 1) NACHC leadership, regulatory, and analytic staff, and 2) external data partners and project partners who represent a range of perspectives and collective expertise in clinical care, informatics, data science, and population health. Details of the GC membership, scope, and operations are defined in a charter.
Roles
NACHC conducts data sharing work in partnership with data partners and project partners.
A data partner is an organization owning and/or sharing data with NACHC which can include organizations providing direct health services such as federally qualified health centers (FQHCs), primary care associations (PCAs), or health center controlled networks (HCCNs). FQHCs are data owners in that they own the data collected by their organization. PCAs and HCCNs do not collect clinical data but serve as a data steward for clinical data provided by their members and contribute data on behalf of their member organizations. Federal agencies such as the Health Resources and Services Administration may also be data partners, providing data to NACHC on behalf of FQHCs (example: UDS data).
A project partner is an organization who participates in or supports data sharing work by providing subject matter expertise, funding, vendor services, or other technical assistance. Vendor services may include analysis which can require direct access to project data.
Project Structure
NACHC organizes and tracks data sharing work in projects. Depending on the scope of the project, a project may have one or multiple datasets from one or more data partners that is housed by NACHC. Most projects use Confluence to manage information and safely share data through a Confluence website which defines the project team, provides links to relevant project documentation and agreements, location of project data, and tracks project progress. Projects have regular status meetings. Minutes and meeting materials from status meetings are made available on Confluence. At the start of each project, a project team is identified and includes members of the data contributor and NACHC staff and documented on the project Confluence page. Additionally, members of the project team who will have access to project data are identified at the project inception. As the project team evolves through the project lifecycle, the project team is updated on Confluence and in project-related documentation, as appropriate.
Services
NACHC's data sharing work includes the following services: subject matter expertise, technical assistance, data management, and analysis services, which are defined in the table below. Most informatics projects involve multiple informatics services.
| Subject matter expertise | Technical assistance* | Data management | Analysis services* |
|---|---|---|---|
|
|
|
|
*Technical Assistance and Analysis can involve the support of contractors or other project partners. AT Still University is frequently used for advanced statistical methods.
Section 2: Data
NACHC uses data either shared with NACHC by another organization or collected by NACHC. When NACHC has received data from an outside organization, NACHC acts as a data steward. Data stewardship is the collection of practices that ensure an organization’s data is accessible, usable, safe, and trusted.
Data Shared with NACHC
There are many types of data that may be shared with NACHC including UDS data, clinical data, and financial data.
UDS Data
NACHC receives UDS data from HRSA that includes health-center level information on a variety of topics including services, staff, capacity, and financial data so that NACHC can perform analyses on behalf of HRSA and FQHCs to describe the health center landscape and services. The UDS data that NACHC receives includes some data that is available publicly and some sensitive data that only NACHC holds. UDS data does not contain PHI but is sensitive. Sharing UDS data with NACHC occurs under a cooperative agreement with HRSA which is overseen by the Director of Knowledge Management and Learning (Currently Margaret Davis). The parameters of UDS data sharing and use are defined in two HRSA agreements (Authorization letter, NACHC DUA). Included in these documents are explicit directions about how findings from the UDS data should be communicated in a way that protects the identity of health centers and their patients.
The UDS data is stored securely at NACHC. Only NACHC staff who have signed the NACHC DUA are permitted to access and use the UDS data. Once a DUA has been executed with an individual and access granted to the UDS datasets, all uses of UDS data must be approved by the UDS Program Director.
Clinical Data
NACHC receives clinical data primarily extracted from EHRs at the patient level. These clinical data are subject to HIPAA privacy and security regulations and can fall into the below categories.
De-identified data is data that has been “stripped of all HIPAA defined identifiers” which includes Personally Identifiable Information (PII) and Protected Health Information (PHI). PII is a subset of PHI and the list of 18 data elements that are considered PHI are documented in the HIPAA Safe Harbor definition. To be considered de-identified under HIPAA, all 18 identifiers must be removed. Any dataset with a zip code or full dates is not de-identified.
A limited data set (LDS) includes data that has been stripped of all 18 HIPAA identifiers, except age, full dates, and five digit zip code, as identified by HIPAA Safe Harbor guidelines.
Identified data sets which include PHI beyond that which would qualify as an LDS and are not accepted by NACHC at this time.
Financial Data
NACHC receives financial data from health centers for the purpose of providing support to health centers. Get info from Gervean.
Membership and Other Health Center Data
Outside of UDS, clinical and financial data, NACHC receives other data from health centers and their partners for specific purposes. Say something about Prepare data?
Data Collected by NACHC
For some projects, NACHC collects its own data, usually in the form of surveys that are completed by health centers or member information. These surveys will be anonymous and do not collect patient identifiers if received or held directly by NACHC. Need to expand this. Talk to Meg.
Requests for Data
NACHC receives requests for data that are either apart of a new or existing project.
NACHC uses a central request process where requests are received, reviewed by the GC, approved/denied, and then delegated to the appropriate project lead. Requests can be submitted here. Request submission requires a detailed description of what data is desired, how the data will be used, the type of use (e.g., research, surveillance, quality improvement or other) and how the request aligns with the NACHC vision. Incomplete requests cannot be evaluated and will be returned to the requester.
Requests for data are evaluated by the GC. Requesters will be notified of an approval or denial within one week of the GC meeting.
Section 3: Statutes, Contracts, and Regulatory
Data Use Agreements (DUAs)
NACHC requires the execution of a data use agreement (DUA) whenever data is being shared with NACHC. For projects where a LDS is being shared, a DUA is required by HIPAA. For projects where deidentified data is being shared, a DUA is executed based on NACHC policy.
NACHC observes the HIPAA Privacy Rule standards for a DUA. The purposes of a DUA are to:
- establish the permitted uses and disclosures of the limited data set;
- identify who may use or receive the information;
- prohibit the recipient from using or further disclosing the information, except as permitted by the agreement or as permitted by law;
- require the recipient to use appropriate safeguards to prevent a use or disclosure that is not permitted by the agreement;
- require the recipient to report to the covered entity any unauthorized use or disclosure of which it becomes aware;
- require the recipient to ensure that any agents (including a subcontractor) to whom it provides the information will agree to the same restrictions as provided in the agreement; and
- prohibit the recipient from identifying the information or contacting the individuals.
Because DUA's require a high level of specificity, each DUA is project-specific. DUAs can be two party, meaning between NACHC and a data contributor, or multi-party, meaning between NACHC and multiple parties. The structure and contents of a DUA are customized based on project structure and needs.
- When NACHC is the provider of data to an outside organization: NACHC has created a DUA template for use with to recipients. This template may be accessed from the NACHC contracts office. When NACHC is providing a LDS, if any material change is to be made to the NACHC template, or if another party’s version of a DUA is to be used, the NACHC legal council must review and approve the terms of the agreement.
- When NACHC is the recipient of the data: If NACHC is the recipient of a LDS of PHI from a non-NACHC source, the NACHC project lead with either use the NACHC DUA template or modify the other party’s Data Use Agreement. When using another party's DUA, the NACHC project lead is responsible for reviewing the Data Use Agreement and determining if it complies in material terms with the NACHC DUA template. If the other party’s DUA differs materially from the NACHC DUA template, or if there is any uncertainty, the NACHC legal council must be consulted.
NACHC has a DUA template that has been approved by NACHC legal council. Alternatively, data partners are welcome to request the use of their institutional DUA template that can be customized for the project by NACHC staff. A process to initiate a DUA is documented below.
- NACHC project lead completes the NACHC DUA Checklist to determine if a DUA is needed. This should occur as part of the project's initiation.
- The checklist is reviewed with data partner at an early project meeting to confirm the need for a DUA and level of identification of a dataset.
- Once completed, the DUA checklist is stored in the project Confluence page.
- If the DUA checklist identified a need for a DUA, the checklist is shared with the NACHC contract officer to begin the creation of a project-specific DUA.
- NACHC populate the DUA with project specific information and share with other parties for comment
- NACHC receives and integrates comments and recirculates to other parties and NACHC legal until DUA is ready for signature
- DUA is signed by other party(ies) and returned to NACHC for counter signature and execution
- DUA is executed by NACHC legal and executed agreement is shared with all parties
HIPAA
When NACHC receives clinical data, those data are covered by HIPAA and NACHC, by receipt of that data, is bound by the HIPAA statutory obligations. NACHC is not a covered entity but does receive limited datasets and operate as a business associate. Though the amount of PHI received by NACHC is minimal, NACHC treats all of its data from covered entities as PHI and as such, complies with the relevant security and privacy expectations outlined by HIPAA.
TEFCA
Launched in January 2022, TEFCA provides a framework for networks to collaborate and share data interoperable. Network to network collaboration has many similarities to NACHC's informatics work. Thus, NACHC seeks to align with TEFCA when applicable and feasible.
Section 4: Work Products
Work Products and Attribution
Data results in work products which may include data quality results, analytic results, value sets, measure definitions, and recommendations. Work products are owned by all members of the project team and can be disseminated in manuscripts, abstracts, reports, presentations, and guidance documents. How and to whom work products are attributed is discussed with all project partners at the outset and as the project evolves to ensure that attribution of work projects is accurate and equitable.
DEI in Work Products
TBD. Need some guidance here.
Identification of Health Centers in Work Products
TBD. Need some guidance here.
Section 5: Data Security, Privacy, and Confidentiality
Patient data has become increasingly valuable to potential attackers. The rapid and continuous evolution of both healthcare information technology and attacker tools makes data security a constantly moving target, with methods of protection struggling to stay in front of attack efforts. NACHC believes that the security, privacy, and confidentiality of patient and health center data is of paramount importance. As such, NACHC takes a number of steps to ensure data security, protect their environment from security threats, and address security incidents when they occur. A summary of NACHC's data security and privacy policies are available here.
NACHC adheres to data security standards defined in the HIPAA security rule (45 CFR Part 160), the National Institute of Standards and Technology (NIST) Cybersecurity Framework, and the Common Agreement (Section 12), Not every part of these three resources apply directly to NACHC's work with data, thus NACHC complies and aligns with them to the degree that they apply.
Section 6: Research
The following topics apply specifically to NACHCs use of data for human subjects research.
Federal regulations require that research projects involving human subjects be reviewed by an Institutional Review Board (IRB). According to the FDA, an IRB is an appropriately constituted group that has been formally designated to review and monitor biomedical research involving human subjects. The IRB must approve or determine the project to be exempt or approved prior to the start of any research activities. The IRB cannot provide approval or determinations for research that has already been concluded.
IRB review and approval is required for projects that:
- Meet the definition of research
- Involve human subjects and
- Include any interaction or intervention with human subjects or involve access to identifiable private information
The federal regulations define both "research" and "human subject." Research is defined as a systematic investigation, including research development, testing, and evaluation, designed to develop or contribute to generalizable knowledge.Studies must be reviewed by an Institutional Review Board (IRB) only if both definitions apply. A project may involve data from human subjects, but not meet the definition of research and would, therefore, not require an IRB review. Research is defined by federal regulations at 45 CFR 46.102 (Protection of Human Subjects 2009), as "a systematic investigation including research development, testing, and evaluation, designed to develop or contribute to generalizable knowledge."
Helpful IRB and Research Guidance:
- Institutional Review Boards Frequently Asked Questions (FDA)
- Institutional Review Boards and the HIPAA Privacy Rule (NIH)
- How to Determine if a Project is Human Subjects Research, a Quality Improvement Project, or Both
NACHC projects that include research are reviewed by an IRB to ensure that the human subjects’ research is ethical. In some cases, an exemption determination is required for publication of results from non-research projects. IRB approvals are not retroactive meaning the data collection or analysis cannot begin until the IRB approval has been granted.
Acknowledging that some projects are clearly research while others are not clearly research or non-research, NACHC delegates the responsibility of determining if the project is research and which (if any) of the NACHC research data governance policies apply to the project lead.
The Common Rule
Federal Regulation 45 CFR 46 “Protection of Human Subjects”, referred to as the Common Rule, is an anchor regulatory text on which investigators and institutional review boards (IRBs) rely and must comply to protect human subjects in research. NACHC research projects comply with this Common Rules guidance on the types of research and required use of an IRB.
Institutional Review Board
NACHC projects that include research are reviewed by an IRB to ensure that the human subjects’ research is ethical. At times, projects involving human subjects’ data are exempt from non-human subjects’ research as they are determined by an IRB to be quality improvement or public health surveillance. In some cases, an exemption determination is required for publication of results from non-research projects. IRB approvals are not retroactive meaning the data collection or analysis cannot begin until the IRB approval has been granted..
Primary Investigator
NACHC projects which are research in nature have a defined primary investigator (PI) who is responsible for ensuring the project adheres to research policies. The PI leads and manages the research team engaged in any part of the research project. NACHC PIs complete a battery of research related training with the CITI program.
Institutional Review Board
NACHC does not operate their own IRB. Instead NACHC partners with external IRBs such as AT Still Research Institute for their IRB needs. Any changes in the research dataset, data use, or data products are considered a change to the research project and require an amendment to the IRB protocol is submitted.
...