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 activities where data is involved but are primarily focused on data sharing that is defined as 1) NACHC receiving data from an external organization, or 2) NACHC sharing data with an external organization. Shared data may be aggregated at the health center level, patient level, or event level (e.g., a lab result).
What Does Data Governance Mean to NACHC?
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 includes 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's Clinical Affairs Division operates a Data Governance Council ('GC') to advise on data sharing including projects 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. 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.
Project Structure
NACHC organizes and tracks data sharing within projects. 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.
Project Roles and Terminology
NACHC conducts data sharing with data partners and project partners.
A data partner is the organization sharing data with NACHC which can include 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 UDS data to NACHC on behalf of FQHCs (example: UDS data).
A project partner is an organization who participates in or supports projects with data sharing by providing subject matter expertise, funding, vendor services, or other technical assistance. The CDC and HRSA are to common project partners. Project partners may perform project-related analyses or create project related data products (i.e., manuscripts, abstracts, or reports) which can require direct access to project data. Every project is different. Depending on the scope of the project, a project may have one or multiple datasets from one or more data partners.
For each project, the project data is defined as the data that will be shared by data partners with NACHC. Based on the project data, the analytic results that will be derived from project data and data products are also defined. Generally, analytic results and data products are either generated by NACHC or project partners.
An example figure illustrating the flow of data in a project with two data partners is shown below.
Services
Projects involving data sharing can also include 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 membership or other health center 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.
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.
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.
Informed Consent
For research projects where data is collected directly from individuals, NACHC uses a consent form to inform participants of the benefits and risks of research participation and documents participant consent. Consent is required before data collection can begin.
Research Data and Products
Research data are stored securely in a project specific location (i.e., SharePoint) and transmitted using secure methods (e.g., SFTP, Dropbox). Only the research team has access to the research data for a given project. Transmission methods are determined based on the preferences of the PI and the project partners. Research project produce data products which are de-identified and shared with project team and relevant stakeholders outside of NACHC through Confluence.