PlaybookWhat this is

This is a ready to adapt playbook for advocacy groups and registry teams who want to publish a professional, public-facing portal describing their data, governance, and access procedures, even with limited technical resources. It collects sample language and templates for data dictionaries, use agreements, IRB and ethics documentation, a data sharing readiness assessment, and guidance for working with industry and external repositories.

AccessInformation for researchers

This page explains how to request access to data from the patient registry and outlines key steps in the data use process.

🧾 Data Use Agreement & Ethics

Before data access can be granted, all investigators must:

• Review and agree to the Data Use Agreement
• Provide proof of IRB or ethics board approval
• Submit a complete data access application

⚠️ Registries are encouraged to work with their IRB and legal teams to ensure that their Data Use Agreement reflects their governance model, privacy protections, and any regulatory requirements (e.g., HIPAA, GDPR).

🔄 Data Access Process

📊 Data Access Process Overview

🧩 Step	👤 Who	⚙️ What Happens	🔄 Outcome / Next Step
1️⃣	🧑‍🔬 Investigator	Submits data access request	➡️ Sent to Registry Staff
2️⃣	🗂️ Registry Staff	Reviews request	🔁 Requests info 🔸or🔸 forwards to DAC
3️⃣	🧑‍⚖️ DAC	Reviews application	✅ Approve 🔸 ❌ Reject 🔸 🔁 Request Revisions
4️⃣ (a)	🧑‍⚖️ DAC	Approves request	✅ IRB confirmed & DUA sent by Registry
4️⃣ (b)	🧑‍⚖️ DAC / Investigator	Requests revisions	📝 Investigator revises & resubmits to DAC
4️⃣ (c)	🧑‍⚖️ DAC	Rejects request	📭 Investigator notified
5️⃣	🗂️ Registry Staff	Confirms IRB + Receives DUA signature	📦 Prepares data
6️⃣	🗂️ Registry Staff	Prepares & sends data	📤 Data delivered to Investigator
7️⃣	🧑‍🔬 Investigator	Performs analysis & drafts manuscript	📨 Sends manuscript to registry
8️⃣	🗂️ Registry Staff	Reviews manuscript (within 2 weeks)	✅ Approve or ✏️ Request changes
9️⃣	🧑‍🔬 Investigator	Revises publication if needed	📚 Final publication with citation

📋 What to Submit

A complete data access request typically includes:

• A brief research proposal or study aims
• A list of requested data elements or cohorts
• IRB/ethics approval letter
• Signed Data Use Agreement
• Timeline and any expected funding source
• Named collaborators and data security plans

💡 Registries may include a downloadable submission template or link to an online data access portal.

🛡️ Oversight and Review

All data requests are evaluated by the Data Access Committee (DAC) to ensure:

• Scientific merit and feasibility
• Compliance with ethical standards
• Appropriate use of sensitive or identifiable fields
• Data use aligns with the registry's goals and participant consent

We have created a sample Data Access Committee (DAC) Standard Operating Procedure (SOP) here and DAC evaluation rubric, here.

🧨 After Approval

Once your application is approved:

• You’ll receive a copy of the finalized DUA
• The registry team will coordinate access or data delivery
• You may be asked to provide periodic updates or reports
• Destruction of data may be required after study completion

For guidance, contact: datarequests@yourdomain.org

GovernanceData use agreement (DUA)

This page outlines the procedures and terms for requesting access to data from the [Registry Name], maintained by [Registry Organization]. These policies are designed to ensure secure and ethical use of participant level registry data.

🔑 How to Request Data

All data requests must include:

• A completed data request form (linked or attached by your registry)
• Proof of IRB submission or approval
• A signed Confidentiality Agreement (template available upon request)
• A detailed list of requested variables or data domains

To initiate a request, contact [datarequests@yourorganization.org] or visit our Data Request Portal.

🕐 Standard review time is 3 to 6 months depending on complexity.

💡 Note: Industry or commercial requests may follow a separate process. Contact [industryrequests@yourorganization.org] for more information.

🔒 Terms and Conditions

Access is contingent upon full compliance with these data use requirements:

• Only non-identifiable data will be shared unless approved under a Limited Data Set with additional agreements.
• The dataset may only be used for the specific project outlined in your application.
• No attempts to reidentify participants are permitted.
• Data must be stored securely and may not be redistributed.
• Investigators must submit abstracts 7 days and manuscripts 30 days prior to submission for registry review.
• Projects must be completed within 3 years of data access; extensions may be requested.
• Upon study completion, all data files must be destroyed and written confirmation sent to the registry.

📝 Suggested Acknowledgment Language:

“The authors thank [Registry Organization] for providing access to [Registry Name] data for this study. We extend our gratitude to the individuals who contributed data and the participating sites.”

📢 Suggested Data Availability Statement:

“Data are available upon reasonable request through the [Registry Organization]'s Research Oversight Committee. Contact [datarequests@yourorg.org] for details. Access restrictions apply to protect participant privacy.”

📄 Signature Requirements

The following must be signed and submitted:

• Confidentiality Agreement
• (If applicable) Information Use Agreement (IUA) for Limited Data Sets
• IRB approval letter

The Principal Investigator (PI) must be affiliated with the institution responsible for data analysis. Changes in personnel or institution must be reported to [Registry Organization].

Citation

Adapted with permission from the Cystic Fibrosis Foundation: CFFPR Data Application and Confidentiality Agreement.

1. Introduction

The Data Access Committee (DAC) is established to review, assess, and decide on third party requests for access to data held within a registry or data repository (“the Registry”). The DAC ensures that access to Registry data is granted in accordance with established policies, ethical principles, and applicable data protection regulations.

Different levels of data access authorization, based on the type of data requested, the nature of the requestor, and the intended purpose of use, are defined in the Registry’s Data Access Policy (DAP).

This document describes the operating procedures of the DAC to promote transparency, consistency, accountability, and compliance.

2.1 DAC Cochairs

• The DAC is led by two Cochairs appointed by the Registry’s governing or steering body.
• The Cochairs provide strategic oversight and ensure that DAC decisions align with the mission and objectives of the Registry.
• Cochairs may represent complementary perspectives (e.g. scientific, clinical, or participant/community representation).

2.2 DAC Members

The DAC is composed of members with expertise relevant to the Registry, which may include:

• A representative of Registry data contributors or participating sites
• A subject-matter or domain expert relevant to the data access request
• A participant, public, or community representative, where applicable

Membership may be adapted depending on the scope and nature of individual requests.

2.3 DAC Secretariat

• The DAC is supported by a Secretariat responsible for coordinating DAC activities, managing communications, and maintaining records.
• The Secretariat serves as the primary point of contact for data requestors.

2.4 Rotation and Review

• DAC membership may follow a rotation system to ensure continuity, availability, and appropriate representation.
• The composition and leadership of the DAC are reviewed at least every three years, or earlier if required.

2.5 Ad Hoc Expertise

• The DAC may seek additional expertise on an ad hoc basis to support the evaluation of specific requests.
• This may include scientific, technical, ethical, legal, or data protection expertise.

3. Responsibilities of the DAC

The DAC is responsible for:

• Reviewing and evaluating all data access requests submitted to the Registry (see sample DAC evaluation rubric here.
• Ensuring that requests align with the Registry’s objectives and Data Access Policy
• Determining appropriate access levels (e.g. aggregate, pseudonymized, or limited datasets)
• Verifying that requestors are appropriately qualified and authorized
• Confirming that required ethical, institutional, or regulatory approvals are in place
• Reviewing and validating proposed data queries or access mechanisms, where applicable
• Identifying overlaps with existing projects and encouraging collaboration
• Communicating decisions and conditions clearly and in a timely manner
• Reporting DAC activities and decisions to the Registry’s governing body

4. Data Access Request Process

1. Submission
   Data requestors submit a completed Data Access Request Form for each proposed project.

2. Administrative Review
   The DAC Secretariat performs an initial review to confirm completeness and eligibility. Clarifications or additional information may be requested.

3. DAC Review
   Complete requests are submitted to the DAC for evaluation. The DAC may request further clarification from the applicant.

4. Decision and Feedback
   The DAC approves, conditionally approves, or rejects the request and provides written feedback outlining any conditions or recommendations.

5. Data Use Agreement
   Prior to any data transfer or access, approved requestors must sign a Data Transfer Agreement (DTA) or Data Use Agreement specifying permitted uses, restrictions, and data protection obligations.

5. Meetings and Decision making

• The DAC meets at regular or ad hoc intervals depending on the volume and urgency of requests.
• The Secretariat circulates relevant documentation in advance of meetings.
• The DAC Cochairs chair meetings and facilitate discussions.
• In the absence of one Cochair, the other assumes full responsibility.
• Decisions are made by consensus where possible; otherwise, voting procedures defined by the DAC apply.
• Each DAC member typically has one vote.
• All decisions, including declared conflicts of interest, are documented by the Secretariat.

6. Conflicts of Interest

• DAC members must declare any actual or perceived conflicts of interest related to a specific data access request.
• Non-conflicted members determine whether recusal is required.
• Recused members do not participate in discussions or decisions and do not access related confidential materials.

7. Confidentiality and Data Security

• DAC members must maintain confidentiality regarding data access requests and deliberations.
• All documents are stored and managed using secure systems.
• Data access is restricted to authorized parties in accordance with approved procedures and agreements.

8. Review and Revision

• These SOPs are reviewed periodically to ensure continued relevance and effectiveness.
• Revisions are approved by the Registry’s governing or steering body.

9. Contact Information

For inquiries regarding data access requests or DAC operations, contact the DAC Secretariat:

[Insert contact information]

10. Approval

These Standard Operating Procedures are approved by the Registry’s governing body and take effect as of [Insert date].

References and Further Learning

The following resources provide additional background and guidance on data access governance and responsible data sharing. They are provided for informational purposes and are not required to adopt or implement this SOP.

Reference SOPs

• ERN EURO-NMD. Standard Operating Procedures, Data Access Committee (DAC), Version 1.0
  https://ern-euro-nmd.eu/wp-content/uploads/2024/06/SOP-DAC-v1.0-vf.pdf The template SOP above was adapted from this source.

Further Learning

• Global Alliance for Genomics and Health (GA4GH)
  Data access governance, data use conditions, and responsible sharing frameworks
  https://www.ga4gh.org

• ELIXIR
  Governance models, data stewardship, and access policies for life science data
  https://elixir-europe.org

Purpose

This rubric supports consistent, transparent, and proportionate evaluation of data access requests. It is intended for use by DAC members when reviewing applications for access to registry or repository data.

The rubric may be adapted to local legal, ethical, and operational requirements.

How to Use This Rubric

• Each criterion should be assessed independently.
• Criteria may be scored qualitatively or numerically, depending on DAC practice.
• Not all criteria carry equal weight; higher scrutiny should be applied to requests involving more sensitive data or higher risk.
• The DAC may approve, conditionally approve, or reject a request based on the overall assessment.

1. Requestor Eligibility and Capacity

Criterion	Assessment Considerations	Rating
Identity and affiliation	Is the requestor clearly identified and affiliated with a legitimate institution or organisation?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Qualifications and expertise	Does the requestor have appropriate expertise to use the data responsibly?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Role clarity	Are the roles and responsibilities of all team members clearly described?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory

2. Scientific, Public, or Societal Value

Criterion	Assessment Considerations	Rating
Purpose of the request	Is the purpose clearly stated and appropriate for the Registry’s mission?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Value and relevance	Does the project demonstrate scientific, public health, or societal value?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Avoidance of duplication	Does the request overlap with existing or ongoing projects? If so, is this justified or coordinated?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory

3. Data Requested and Proportionality

Criterion	Assessment Considerations	Rating
Data minimisation	Is the amount and type of data requested proportionate to the stated aims?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Sensitivity of data	Does the request involve sensitive, rare, or potentially identifiable data?	☐ Low ☐ Moderate ☐ High
Access level requested	Is the requested access level (e.g. aggregate, pseudonymized) appropriate?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory

4. Ethical and Regulatory Compliance

Criterion	Assessment Considerations	Rating
Ethics approval	Has appropriate ethics or institutional review approval been obtained, if required?	☐ Yes ☐ Pending ☐ Not applicable
Legal basis for data use	Is there a clear and appropriate legal basis for the proposed data use?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Participant expectations	Is the proposed use consistent with participant consent and reasonable expectations?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory

5. Data Protection and Security

Criterion	Assessment Considerations	Rating
Data handling plan	Is there a clear plan for secure storage, access, and processing of data?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Risk of reidentification	Are risks of reidentification assessed and mitigated?	☐ Low ☐ Moderate ☐ High
Data retention and destruction	Are retention periods and disposal methods clearly defined?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory

6. Data Use, Sharing, and Outputs

Criterion	Assessment Considerations	Rating
Intended analyses and outputs	Are analyses and outputs clearly described and appropriate?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Restrictions on reuse	Are secondary use, onward sharing, or commercial use appropriately addressed?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory
Acknowledgement and attribution	Are plans for acknowledgement of the Registry and contributors specified?	☐ Satisfactory ☐ Needs clarification ☐ Unsatisfactory

7. Conflicts of Interest

Criterion	Assessment Considerations	Rating
Declared conflicts	Have all potential conflicts of interest been declared?	☐ Yes ☐ No
Impact of conflicts	Could any declared conflict compromise objectivity or trust?	☐ Low ☐ Moderate ☐ High

Summary of Key Strengths

Summary of Key Concerns

DAC Decision

• ☐ Approved
• ☐ Approved with conditions
• ☐ Not approved

Conditions or Recommendations (if applicable)

Notes

• Requests involving high-risk or highly sensitive data may require additional safeguards, restrictions, or staged access.
• The DAC may revisit decisions if project scope or data use changes.

This rubric is provided as a template and may be adapted to fit the needs and maturity of different registries or data repositories.

GovernanceIRB & ethics documentation

This section describes the Institutional Review Board (IRB) or ethics approvals for the registry. Proper ethics oversight ensures that data collection and sharing comply with regulations and protect participants.

IRB Approval: This registry study is approved by [Name of IRB or Ethics Committee].

• Protocol ID: [IRB protocol number or ID]
  
• Approval Date: [Date of approval]
  
• Renewal/Expiration: [If applicable, when does the approval expire or renew]
  
• Consent: [Describe the consent provided by participants, e.g., "All participants signed informed consent allowing their data to be used in deidentified form for research."]

Notes: The data shared through this site is deidentified and adheres to the conditions set by the IRB. Users of the data must agree to use it only for the approved purposes. If you have questions about the ethical use of the data, please contact the study coordinator or the IRB office at [contact info].

Instructions: Update the details above with your actual IRB approval information. You can also attach or link to official documentation if appropriate (e.g., an IRB approval letter, if it can be shared). If multiple IRBs or approvals cover different parts of the data, list them all here.

DocumentationCohort overview

⚠️ Sample Content Only
This page includes placeholder language meant to help registry teams create their own cohort summary.
Please replace all text and values with data specific to your project.

🔍 Purpose

This overview provides a high-level summary of the participant population currently included in the registry. It is intended to support researchers in assessing feasibility and relevance for proposed research.

👥 Participant Summary

• Total enrolled participants: [Insert number]
• Data collection start date: [Insert date]
• Most recent data freeze or refresh: [Insert date]
• Participating sites (if applicable): [List or number]

📊 Key Demographics

Variable	Summary
Age (mean/range)	[e.g., 47 years (range: 18 to 92)]
Sex distribution	[e.g., 58% female, 42% male]
Race/Ethnicity	[Insert summary or "See table below"]
Geographic distribution	[e.g., 12 U.S. states + 3 international sites]

🧾 Clinical Highlights

Include a few registry-specific clinical characteristics here:

• Most common diagnoses: [e.g., Disease A (35%), Disease B (28%)]
• Treatment history recorded: [e.g., Yes, medications, surgeries, etc.]
• Key clinical variables: [e.g., biomarker values, diagnostic imaging, lab results]

📂 Available Data Domains

The registry captures data in the following categories:

• Demographics
• Medical history
• Diagnostic test results
• Treatments and procedures
• Patient-reported outcomes
• [Other categories]

For full variable definitions, see the Data Dictionary.

📎 Additional Notes

• Data availability may vary across time periods and sites.
• Data extraction requires review and approval, see Information for Researchers for details.

📬 Contact

Questions? Contact [datarequests@yourorganization.org] for more information or to request a detailed data cut.

Last updated: [Insert date]
Note: This summary is provided for general awareness and planning purposes. It reflects a snapshot of the registry at the time of analysis and may not reflect current enrollment.

DocumentationData dictionary

This page provides a detailed data dictionary for the registry. Below is a list of the key data fields collected, along with their definitions and allowable values. Use this as a reference to understand the data set.

Example structure: you might use a table or list to present the data dictionary. Here's a suggestion for a table format:

Field Name	Description	Type / Units	Notes
patient_id	Unique identifier for each participant	Integer	(e.g., study ID, no personal info)
enrollment_date	Date the participant was enrolled in the registry	Date (YYYY-MM-DD)
age_at_enrollment	Age of participant at time of enrollment	Integer (years)	Derived from DOB and enrollment date
...add your fields...

Instructions: Edit the table above to include all variables in your data set. For each field, provide a clear description. Include units or format (e.g., "Date (YYYY-MM-DD)" or "Categorical: 0=No, 1=Yes"), and any notes (like derivation or if the field is optional). If your registry has multiple tables or modules of data, you could split this into multiple pages or sections.

DocumentationDerived fields

This page explains any derived or calculated fields in the registry data set. Derived fields are those not collected directly, but computed from other data. Documenting them is important for transparency and reproducibility.

For each derived variable, explain how it’s calculated or defined. For example:

• Body Mass Index (BMI): Calculated as weight (kg) divided by squared height (m^2), using the most recent weight and height from the participant record.
• Age Group: Derived from the exact age; categorized into groups (0-17 = child, 18-64 = adult, 65+ = senior) at time of enrollment.
• Disease Duration: Computed as the time in years from reported diagnosis date to the last follow up date.

Instructions: Replace the examples with your actual derived fields. Provide enough detail that another researcher could recreate the field from the source data. If a derived field comes from an external algorithm or reference, cite or describe that as well.

IntakeEnd user survey

Thank you for your interest in accessing this patient registry data. To help us understand your needs and ensure responsible data sharing, please complete the following questionnaire.

🧠 1. Intended Use

1.1 What is the title or primary aim of your research project?
Example: “Identifying phenotypic clusters in X disease and linking to gene expression data.”

Your answer:

1.2 What are your primary research questions or use cases?
(Select all that apply):

• Descriptive statistics
• Epidemiology
• Comparative effectiveness
• Health services research
• Clinical trial design or feasibility
• Genomic/Omic integration or phenotype-genotype analysis
• Biomarker discovery or validation
• Multi-modal data analysis (e.g., combining clinical and imaging or biospecimen data)
• Linkage with biospecimen or biobank data
• Algorithm development (e.g., phenotyping, prediction models)
• Policy or access equity analysis
• Other (please specify):

  Your answer:

🧰 2. Tools & Technical Preferences

2.1 What analysis tools or environments do you prefer to use?
(Select all that apply):

• R
• Python / Jupyter notebooks
• SAS
• SPSS
• Stata
• Excel / CSV
• SQL / Relational database
• Bioinformatics tools (e.g., Galaxy, Bioconductor)
• HPC or cloud-based workflows (e.g., Terra, DNAnexus)
• Other (please specify):

  Your answer:

2.2 Are you familiar with working in a secure remote analysis environment (enclave)?

• Yes, I regularly use enclaves or cloud-based notebooks
• Somewhat, I’ve used them occasionally
• No, I prefer local file downloads or offline analysis

🔁 3. Data Refresh and Timeline

3.1 How frequently would you need data updates, if at all?

• One-time snapshot
• Quarterly
• Biannually
• Annually
• Other (please specify):

  Your answer:

3.2 Will your project evolve over time (e.g., need new variables or participant cohorts)?

• Yes
• No
• Not sure

➕ 4. Data Scope and Needs

4.1 Is the minimal shared dataset likely to meet your needs?
(Minimal dataset includes core demographic, clinical, and visit variables.)

• Yes
• No, I’ll likely request additional data
• Not sure

4.2 If requesting additional data, which categories are of interest?
(Check all that apply):

• Longitudinal clinical data
• Imaging metadata or derived variables
• Genomic, transcriptomic, proteomic, or metabolomic data
• Patient-reported outcomes
• Visit-level or procedure-level detail
• Geolocation or provider-level information
• Other (please describe):

  Your answer:

🔐 5. Compliance and Review

5.1 Has your institution required or initiated a Data Use Agreement (DUA)?

• Yes
• No
• Not sure

5.2 What is the status of your IRB or ethics board approval?

• Approved
• Submitted, awaiting decision
• Not yet submitted
• Exempt / not applicable (please explain):

  Your explanation:

🧬 6. Use of Biospecimens or Linkage

6.1 Will you be requesting data to be linked with biological samples or a biobank?

• Yes, we plan to request biospecimen linkage
• No, we will use registry data only
• Not sure

6.2 If yes, what types of biospecimen data will be used or integrated?
(e.g., blood, saliva, tumor tissue, omics, sequencing platform, etc.)

Your answer:

📝 7. Additional Information

7.1 Is there anything else you'd like us to know about your project scope, collaborators, or data needs?

Your answer:

Please return this completed form to [datarequests@yourregistry.org] or submit it via our data access portal.

InfrastructureSharing platforms & technologies

Patient registry teams must carefully consider where and how to store and share data, particularly when sharing with external researchers. The platform used should support regulatory compliance, data privacy, secure access, scalability, and usability across technical skill levels. Below is a breakdown of key storage and access models, major cloud vendors, and important considerations for implementation.

1. Cloud-Based Platforms

• Amazon Web Services (AWS)
• HIPAA-eligible services (e.g., S3, RDS, EC2)
• Supports secure data lakes, analytics, and machine learning
• Common choice for enterprise health data infrastructure

• Broad integration with Python/R/SQL-based notebooks (e.g., SageMaker, EMR)

• Microsoft Azure

• Trusted by many academic medical centers
• Tools for AI/ML, relational databases, and Azure Synapse Analytics

• Provides granular identity and access control

• Google Cloud Platform (GCP)

• Popular in research computing (BigQuery, Cloud Datalab)
• Optimized for analytics-heavy workflows
• Strong support for FHIR and healthcare APIs

2. Local/Institutional Servers

• Maintained by your own organization (e.g., hospital IT, university research computing)
• May be required by data governance agreements
• Pros: direct control, no third party exposure
• Cons: scaling, security patching, and external access can be more difficult

🔍 Key Questions to Ask

• Does the platform meet HIPAA, GDPR, or IRB requirements?
• What data access controls are supported (e.g., single sign-on, user audit logs)?
• Are there approved environments for PHI or limited data sets?
• What types of users will need access (e.g., R users, Python users, Stata/SPSS users)?
• Will external collaborators work within a secure enclave or receive downloaded datasets?

💡 Enclave Environments: An Alternative to Downloading Data

Instead of providing datasets for download, some registries use a secure enclave, a virtual environment where researchers log in to conduct analyses remotely. These setups often use Jupyter Notebooks, RStudio Server, or even locked-down terminal access.

Benefits

• Enhanced security: no raw data leaves the enclave
• Audit logs and reproducibility
• Easier to control software, packages, and compute environments

Limitations and Considerations

• Users must adapt to cloud-based workflows (e.g., notebooks)
• Some researchers prefer point-and-click tools (e.g., SPSS/Stata)
• Requires robust user support and onboarding
• Data visualization may be limited unless tools are configured

Examples of Enclave Tools

• AWS SageMaker Studio Lab / EC2 JupyterHub
• Microsoft Azure Machine Learning Workspaces
• GCP Vertex AI Workbench
• NIH's BioData Catalyst / dbGaP Authorized Access Workspaces

🔄 Summary: Match Tools to Users

Feature/Need	Best Fit Platform
Raw statistical file sharing	Encrypted cloud folder or secure FTP
SQL analysis and reporting	Cloud-hosted RDS or BigQuery
Notebook-based collaboration	AWS/GCP/Azure Notebooks or JupyterHub
Protected health information	Enclave with IRB + DUA controls

When in doubt, start with a small pilot and gather user feedback before expanding access.

For policy implications and best practices, see the NIH Data Sharing Language Explained section.

AssessmentData sharing readiness assessment

🧭 How to Use This Page

This assessment is organized into three layers:

1. Foundational Readiness: Can your data be responsibly shared?
2. Standardization Readiness: Can others understand and reuse it?
3. OMOP Readiness (Optional): Can it be transformed into a common data model?

You do not need to complete every section to begin sharing data. Use what fits your use case/goals.

🧾 1. Registry Content Inventory

• Master variable list compiled across all data sources
• Data Dictionary exists for each data set (surveys, labs, genomics, etc.)
• Linkage documentation describes how sources are joined (e.g., participant ID, visit date)
• Data source tags included for merged variables (provenance)
• Derived variables clearly labeled with source(s) documented
• Date standardization and time alignment addressed
• Missingness summary reported per source
• Cohort definition consistent across sources

📄 2. Governance & Documentation

• Data Use Agreement (DUA) specifies which data sources are shared
• IRB protocol covers all data sets and secondary use
• Consent language reviewed for each source (EHR, biospecimen, survey)
• Oversight committee includes data set-specific expertise
• Review process supports partial or multi-source requests
• End user intake form asks which data types are requested
• Publications policy supports tiered or layered access

💻 3. Technical Infrastructure

• Each data source available in a common export format (CSV, RDS, JSON, etc.)
• Data integration pipeline documented (manual or automated)
• Deidentified linking key exists
• Secure transfer options for large or sensitive files
• Remote analysis environment available if needed
• Access logs / audit trails maintained
• Documentation portal or metadata catalog exists

👥 4. Registry Team Roles & Capacity

• Staff assigned per source (e.g., genomics lead, EHR analyst)
• Request fulfillment timelines defined
• Capacity to answer provenance and transformation questions
• Governance team understands cross-source dependencies

🔐 5. Privacy and Ethics

• Identifiability risk assessed across combined data sets
• Omics, imaging, geospatial data reviewed for reidentification risk
• HIPAA / GDPR compliance validated per data stream
• Tiered access model defined (public, controlled, restricted)
• Secure analysis options offered for sensitive data
• Data destruction policy covers all formats and systems

🧩 Layer 2: Data Standardization Readiness (Recommended)

🧠 6. Variable Definitions & Semantics

• Variables have clear, unambiguous definitions
• Similar variables across sources are reconciled
• Units stored separately and consistently
• Dates distinguish onset vs diagnosis vs observation
• Null values distinguish missing, unknown, and not applicable

🧬 7. Standard Vocabulary Use

• Diagnoses coded or mappable (SNOMED, ORPHA, MONDO)
• Phenotypes structured or mappable (HPO)
• Labs coded or mappable (LOINC + UCUM units)
• Medications normalized (RxNorm / ATC)
• Procedures use a recognized coding system
• Source values retained alongside standard codes

📊 8. Data Quality & Provenance

• Completeness monitored by source
• Value range and format checks defined
• Provenance captured for merged variables
• data set versions tracked with change logs

🧬 Layer 3: OMOP Readiness

🧱 9. OMOP Structural Fit

• Person-level records with stable IDs
• Visit or event-based structure
• Longitudinal data capture
• Core clinical domains represented

OMOP Domain	Present
PERSON	⬜
VISIT_OCCURRENCE / DETAIL	⬜
CONDITION_OCCURRENCE	⬜
MEASUREMENT	⬜
DRUG_EXPOSURE	⬜
PROCEDURE_OCCURRENCE	⬜
OBSERVATION	⬜
DEATH	⬜

🔄 10. OMOP ETL Practicality

• Source tables are stable
• Variable meanings are consistent
• Units explicitly stored
• Dates are parseable and complete
• Corrections and updates can be tracked

📐 OMOP Readiness Scale & Rubric

Level 0: Not OMOP-Ready

Status: Foundational gaps prevent OMOP mapping.

Typical characteristics

• No stable person identifiers
  
• Flat or cross-sectional data only
  
• Heavy reliance on free text for key domains
  
• No consistent visit or event dates
  
• Variable definitions unclear or missing

What to focus on next

• Create a master data dictionary
  
• Define person- and event-level structure
  
• Standardize dates, identifiers, and provenance

Level 1: Structurally Aware

Status: Data structure exists, but semantics are weak.

Typical characteristics

• Person-level records with stable IDs
  
• Longitudinal data present
  
• Minimal or inconsistent use of standard vocabularies
  
• Local codes or free text dominate
  
• Mapping would rely heavily on OMOP OBSERVATION

What to focus on next

• Clarify variable definitions
  
• Identify candidate standard vocabularies
  
• Normalize units and dates

Level 2: Terminology Mappable

Status: Core domains can be mapped with moderate effort.

Typical characteristics

• Diagnoses, labs, and medications partially coded or mappable
  
• Units stored separately
  
• Source values preserved
  
• Visit structure mostly consistent
  
• Limited governance around vocabularies

What to focus on next

• Formalize vocabulary mappings
  
• Reduce free text in high-value fields
  
• Document mapping decisions

Level 3: OMOP-Compatible

Status: OMOP ETL feasible with standard effort.

Typical characteristics

• Core clinical domains map cleanly to OMOP tables
  
• Standard vocabularies used consistently
  
• Longitudinal visits or events well-defined
  
• Provenance and versioning tracked
  
• Initial OMOP ETL completed or piloted

What to focus on next

• Expand to additional domains (e.g., genomics, PROs)
  
• Improve automation and quality assurance
  
• Prepare for federated analyses

Level 4: OMOP-Operational

Status: OMOP is production-ready and reusable.

Typical characteristics

• Routine OMOP refreshes
  
• Automated and versioned ETL pipeline
  
• Data quality checks aligned with OMOP conventions
  
• Participation in federated or networked studies
  
• Clear governance for mappings and updates

What to focus on next

• Optimization and performance
  
• Advanced phenotyping and cohort reuse
  
• Cross-network harmonization

📊 How to Assign a Level

Use the OMOP checklists above and apply the following rule:

• Level 0: Fails multiple Structural Fit items
• Level 1: Structural Fit ✔, Terminology Mapping mostly ✖
• Level 2: Structural Fit ✔, Terminology Mapping mostly ✔
• Level 3: Structural + Terminology + ETL Practicality ✔
• Level 4: Level 3 plus operationalized ETL and reuse

🧮 Optional Quantitative Scoring

Assign points to each OMOP readiness checklist item:

• ✔ = 1 point
• ✖ = 0 points

Score ranges

• 0 to 4: Level 0
  
• 5 to 8: Level 1
  
• 9 to 12: Level 2
  
• 13 to 16: Level 3
  
• 17+: Level 4

🧩 Tips for Multi-Source Registries

• Use data source tagging and consistent naming conventions
• Track data provenance: what came from where, and when
• Clarify which data sources are required vs optional
• Share core data sets by default, restrict sensitive or high-dimensional data
• Provide diagrams of data architecture or flow

📌 Summary

Use this assessment to identify gaps before inviting data access requests or pursuing harmonization.

Many registries begin with Layer 1, progress through Layer 2, and only complete Layer 3 when needed.

Consider publishing a data inventory table summarizing each source, access level, and documentation status.

PartnershipsSharing data with industry sponsors

1. Purpose

This document establishes a policy for the responsible sharing of participant-generated data (PGD) collected through a advocacy group's tracker application or patient registry. It is intended to protect:

• Clinical trial integrity
• Participant privacy and informed consent
• Ethical and regulatory compliance
• Scientific credibility

2. Scope

This policy applies to:

• The participant tracker app or registry operated by the advocacy group
• Any biopharmaceutical company (“Sponsor”), including those:
  • Conducting ongoing clinical trials
  • Planning future trials

It governs sharing of:

• Aggregate and individual-level data
• Historical and contemporaneous datasets
• Scientific, commercial, and regulatory uses of participant-generated data

3. Regulatory Background: Key Guidance

This section summarizes official FDA and EMA guidance, and concrete regulatory precedents, that are relevant to sharing participant-generated data (PGD) with clinical trial sponsors.

3.1 FDA, Real world Data and Real world evidence (2023)

Guidance:
“Considerations for the Use of Real world Data and Real world evidence to Support Regulatory Decision making for Drug and Biological Products” (Guidance for Industry, Aug 2023).

• FDA guidance

Key points and quotes:

• Sponsors are expected to have a prospectively defined protocol and SAP for any RWD study that will support a marketing application.

• The guidance states:

  “Sponsors should provide draft versions of their proposed protocol and statistical analysis plan (SAP) for Agency review and comment…”

• FDA emphasizes that it must be confident that data sources and analyses were not selected to favor a particular conclusion. This is why informal, ad hoc use of external data streams is viewed skeptically.

3.2 FDA, Real world Data: Assessing Registries (Dec 2023)

Guidance:
“Real world Data: Assessing Registries to Support Regulatory Decision making for Drug and Biological Products” (Guidance for Industry, Dec 2023).

• FDA guidance

Key points and quotes:

• Registries are defined as systems that enroll a predefined population and collect prespecified health related data.

• The guidance notes:

  “Establishing registries involves enrolling a predefined population and collecting prespecified health related data for each participant in that population.”

• For regulatory use, sponsors are responsible for ensuring the registry supports relevant and reliable data.

• The guidance also states:

  “Sponsors should… submit the protocols and statistical analysis plans to the Agency before conducting the study.”

Together, these guidance documents establish that regulatory-grade RWD/RWE must be pre-planned, protocol-driven, and governed, not ad hoc.

3.3 EMA, Computerised Systems and Electronic Data in Clinical Trials (2023)

Guideline:
“Guideline on Computerised Systems and Electronic Data in Clinical Trials” (EMA/INS/GCP/112288/2023).

• EMA Guideline

Key points and quotes:

• The guideline sets expectations for validated, controlled computerised systems used for trial data, including ePRO, wearables, EHR, and other electronic sources.

• It explains that it:

  “…covers requirements and expectations for computerised systems, including validation, user management, security, and electronic data for the data life cycle.”

• The underlying goal is that all clinical-trial data used in decision making are traceable, auditable and under sponsor or investigator control.

Unplanned importing of external app data into a trial context sits uncomfortably with these expectations.

### 3.4 EMA, Reflection on External Controls and RWD **Program:** “Development of a reflection paper on the use of external controls in evidence generation and regulatory decision making.” - [EMA page](https://www.ema.europa.eu/en/development-reflection-paper-use-external-controls-evidence-generation-regulatory-decision making-scientific-guideline) The reflection work emphasizes that external controls and RWD must be used under **prospectively planned, well-governed designs** to avoid bias. External data that are not prespecified or quality-controlled are considered high-risk for decision making. ### 3.5 Regulatory Precedent: External Controls Not Accepted Publicly available FDA reviews and secondary analyses show multiple cases where RWD-based external controls were **not accepted** as adequate for regulatory decision making, mainly due to methodological flaws and lack of prespecified design. #### Rozlytrek (entrectinib), ROS1-positive NSCLC - External control arm built from Flatiron Health RWD to compare with single arm trials. - FDA’s Division of Epidemiology concluded the RWD cohort was **not comparable** to the trial population and that the study: > “is not adequate to allow a robust comparison of treatment outcomes between crizotinib and entrectinib study arms.” - FDA also advised that future RWD studies should be based on an **a priori** (prospectively defined) protocol, and viewed the current analysis as post-hoc. Key documents: - [FDA RWD review](https://www.accessdata.fda.gov/drugsatfda_docs/nda/2019/212725Orig1s000%2C%20212726Orig1s000OtherR.pdf) - [Case summary](https://evidence-hub.aetion.com/learnings-from-three-fda-decisions-on-eca-submissions-in-oncology) #### Xpovio (selinexor), Relapsed/Refractory Multiple Myeloma - RWD external control from Flatiron was submitted to contextualize overall survival. - FDA stated that: > “The evidence generated from the RWD analysis is not adequate to provide context or comparison for the overall survival observed in the [clinical trial] participants.” - Reasons included **lack of comparability** and multiple biases (selection, confounding, immortal time, missing data). Key documents: - [FDA review](https://www.accessdata.fda.gov/drugsatfda_docs/nda/2019/212306Orig1s000MultidisciplineR.pdf) - Case summary: same Aetion article as above. #### Balversa (erdafitinib), FGFR-mutant Bladder Cancer - RWD external control was submitted for overall survival. - FDA’s epidemiology reviewers concluded: > “DEPI [did] not consider the study sufficiently valid for supporting regulatory decisions pertaining to drug effectiveness…” - Methodological issues included confounding, selection bias, data missingness, temporal bias, and limited sample size. Key documents: - [FDA RWD review](https://www.accessdata.fda.gov/drugsatfda_docs/nda/2019/212018Orig1s000OtherR.pdf) - Case summary: same Aetion article.

3.6 Implication for Participant-Advocacy Group

These guidance documents and precedents collectively support the view that:

• Non-prospectively-defined access to external data (such as contemporaneous participant-tracker data) is not aligned with regulatory expectations.
• Regulators expect RWD used in decisions to be gathered under prespecified protocols and SAPs, in validated, controlled systems, and free from ad hoc “data peeking.”
• Even if the sponsor does not intend to use the tracker data directly in a submission, access to such data can still create concerns about biasing trial conduct or interpretation.

4.1 Prospective Planning

All data sources and intended uses must be predefined. Non-prospectively planned data sharing is discouraged.

4.2 Protection of Clinical Trial Integrity

PGD must not:

• Unblind or risk unblinding
• Provide informal interim signals
• Influence trial conduct
• Circumvent DSMB/IDMC processes

4.3 Consent & Privacy

• Sharing must align with the tracker app’s consent
• Deidentification must meet relevant regulatory standards
• Reidentification risk must be assessed

4.4 Data Governance

Requires:

• A Data Use Agreement (DUA)
• Documented sponsor firewalls

4.5 Transparency

Participants should understand potential data sharing practices.

5.1 Deidentified or Anonymized Data

• Meets HIPAA/GDPR standards
• Reidentification risk assessed

5.2 Limited Impact on Trials

• Historical (non-contemporaneous)
• Aggregated
• Cannot reveal efficacy or safety trends

5.3 Governance and Firewalls

• DUA in place
• Access limited to RWE teams
• Trial teams excluded

5.4 Clear, Prespecified Use

Examples:

• Natural history studies
• Burden-of-illness projects
• HEOR
• Non-regulatory scientific uses

5.5 Ethics Oversight

Recommended for small rare disease populations.

6. When Data Sharing Is Not Permissible

High-risk scenarios:

• Contemporaneous participant level symptom data
• Data revealing efficacy/safety trends
• Likely overlap with trial participants
• Inadequate consent
• No DUA or governance
• Ad hoc exploratory sponsor requests
• Any sharing that could bias trial conduct

Important: The issue exists even if the sponsor does not intend to use the data in a regulatory submission. Regulators assess whether access could have influenced the trial.

7.1 Data Preparation

• Predetermined data fields
• Deidentified
• Aggregated

7.2 Timing Controls

• Lag of ≥3 to 6 months
• Avoid sharing during blinded phases

7.3 Sponsor Firewalls

Allowed:

• RWE / Epidemiology
• HEOR
• Privacy/security teams

Prohibited:

• Clinical operations
• Trial statisticians
• Medical monitors
• Protocol authors

7.4 Auditability

• Logs of all transfers
• Access logs inside sponsor systems
• Annual review

Advocacy Group / Data Controller

• Consent management
• Deidentification
• Risk assessments
• DUA enforcement

Sponsor

• Maintain firewalls
• Control internal access
• Avoid trial contamination

Oversight Committee (Optional)

• Review high-risk cases
• Advise on ethics and expectations

Purpose

• Purpose defined
• Sponsor trial activity identified
• Regulatory vs non-regulatory use clarified

Data Characteristics

• Type
• Aggregation level
• Timing
• Granularity

Consent & Privacy

• App consent allows sharing
• Reidentification risk reviewed
• HIPAA/GDPR compliance documented

Trial Integrity

• Overlap with trial evaluated
• Unblinding risk assessed
• Firewall documented

Governance

• DUA signed
• Named data recipients
• Prohibited teams identified
• Access controls set
• Logs enabled

## 10. Safe Sharing Model (Table Format) ### Data Flow Overview - to be turned into a diagram | Step | Description | Flow | |------|-------------|------| | 1 | PGD collected | App → Advocacy Group | | 2 | Deidentified + aggregated | Advocacy Group → Prepared Dataset | | 3 | Shared only with RWE | Prepared Dataset → Sponsor RWE Team | | 4 | Firewalls enforced | RWE Team → (No access to Trial Team) | | 5 | Optional high-level insights | RWE Team → Filtered Summary → Trial Team (optional) | ### Sponsor Access Rules | Team | Access to PGD | Notes | |------|----------------|-------| | RWE / Epidemiology | Yes | Primary recipients | | HEOR | Yes | Aggregate use only | | Privacy/Security | Yes | Compliance only | | Clinical Operations | No | Firewalled | | Trial Statisticians | No | Firewalled | | Medical Monitors | No | Firewalled | | Protocol Authors | No | Firewalled | ---

PartnershipsSharing with external repositories

Sharing data from a patient registry with external data repositories or aggregators can greatly amplify the impact of those data, but it requires careful planning and governance. This guidance is intended for all stakeholders involved in a registry, technical leads, program managers, and governance staff alike, and covers benefits, legal/ethical considerations, data formatting and harmonization, privacy concerns, long term stewardship, and emerging models (like federated networks and the OMOP common data model). These considerations apply across data types (clinical data, genomic data, patient-reported outcomes, etc.).

Benefits of Participating in External Data Platforms

• Accelerate research and insights, particularly for rare diseases or small populations
• Gain access to advanced analytics and domain expertise
• Increase visibility and impact through collaboration and broader dissemination
• Support public health and drug development via real world data

Governance, Ethical, and Legal Considerations

• Data Ownership and Rights: Confirm your ability to share and retain control where needed.
• Participant Consent and IRB: Ensure data sharing aligns with consents and ethical approvals.
• Data Sharing Agreements: Use formal contracts to govern use, access, and attribution.
• Oversight: Establish a Data Access Committee and transparent approval processes.
• Regulatory Compliance: Align with HIPAA, GDPR, and other privacy regulations.

Key Questions:

1. Who owns and controls the data post-sharing?
2. What is allowed under the data sharing agreement?
3. How is privacy protected?
4. What oversight does the registry retain?
5. What are the costs and resource needs?

Data Formatting and Harmonization

• Common Data Models: Adopt standards like OMOP for interoperability.
• Terminologies and Ontologies: Use controlled vocabularies (e.g., SNOMED CT, LOINC).
• Metadata and Documentation: Provide data dictionaries and provenance details.
• Curation Support: Coordinate with repositories on standardization and validation.

Privacy and Security Considerations

• Deidentification: Remove direct/indirect identifiers per HIPAA and GDPR.
• Sensitive Data: Treat genomics and biomarker data with extra caution.
• Security Standards: Ensure encrypted storage, secure transfers, and role based access.
• Transparency: Communicate plans to participants and oversight boards.

Long term Data Stewardship

• Retention: Understand repository policies for long term storage and sunsetting.
• Versioning: Plan for data updates and user notifications.
• Monitoring Use: Track and report on downstream data access and use.
• Revocation and Misuse: Have plans for removing or correcting data if needed.
• Attribution: Ensure acknowledgment policies are in place.

Federated Data Sharing Models

• Definition: Keep data local, share queries and aggregated results only.
• Advantages: Enhanced privacy, local control, compliance.
• Infrastructure: Requires standardization and compatible software.
• Use Cases: Ideal for cross-jurisdiction collaboration or high-sensitivity data.

Data Types to Consider

• Clinical Data: Standardized structured data (e.g., labs, medications)
• Genomics/Biomarkers: Consider file types, repositories, and privacy
• Patient-Reported Outcomes: Include instruments and scoring guides
• Biospecimens: Share metadata and access conditions
• Derived Variables: Explain algorithms and usage contexts

Summary

Treat external data sharing as a strategic endeavor. With governance, technical preparation, and transparent policies, patient registries can responsibly amplify the utility of their data and accelerate research. Consider the guidance above a roadmap for initiating or refining your data sharing strategy.

PolicyNIH data sharing language explained

⚠️ Disclaimer
This page provides a general explanation of NIH data sharing expectations, particularly as they apply to patient registries. It is not legal or regulatory advice. Please consult your institution’s IRB or regulatory officials to determine how these policies apply to your specific registry and data governance practices.

The inclusion of NIH Data Sharing language in data use agreements is essential for ensuring compliance with federal policy, protecting participant privacy, and supporting responsible scientific research.

This page outlines why such language is important, what it requires of investigators, and how it applies specifically to patient registries such as those managed by [Registry Owner/Organization].

1. NIH DMS Policy Applies to All NIH funded Research

As of January 25, 2023, the NIH requires all funded research to include a Data Management & Sharing (DMS) Plan.

🔗 NIH Data Sharing Portal

Researchers Must:

• Plan how scientific data will be managed and shared
• Specify data types, repositories, formats, access levels, and timelines
• Follow their DMS Plan as a condition of funding
• Justify any restrictions or limits on sharing

If registry data are included, your DMS Plan must not violate privacy protections or registry policies.

2. Registry Data Often Cannot Be Openly Shared

Even when deidentified, patient registry data may pose reidentification risks due to:

• Rare or small populations
• Geographic/demographic uniqueness
• Traceability through center affiliation

Typically, consent forms do not permit public sharing of record-level data. Instead, data must be shared via controlled access mechanisms.

NIH recognizes that legal or ethical concerns may limit sharing:

🔗 Allowable limitations on data sharing (NIH)

3. NIH Projects Must Coordinate with the Registry

If a research project involves NIH funding:

• Notify the registry team (e.g., [datarequests@yourorg.org])
• Coordinate any changes requested by NIH reviewers
• Allow the registry to supply appropriate documentation

This protects all parties and ensures NIH, HIPAA, and registry policies align.

4. Journals Expect Data Sharing, But Not Public Posting

Journals and funders now ask for:

• Data availability statements
• Clear access pathways for other researchers

❌ Do not post registry data on:

• GitHub
• Kaggle
• Dryad
• Figshare
• Supplemental materials in manuscripts

Without checking with your Institutional Review Board first!

✅ Instead, use NIH-compatible controlled access language:

“Data may be available from [Registry Organization] upon request and contingent on approval by the [Registry Oversight Committee]. Access restrictions are in place to protect participant privacy.”

5. Why This Is Important to Understand

Benefit	Description
🛡️ Protects Participants	Prevents accidental reidentification
✅ Complies with NIH	Meets DMS Plan expectations
🧭 Clarifies Roles	The registry owner is the gatekeeper, not the external PI
🧠 Avoids Mistakes	Prevents premature or inappropriate data sharing
🤝 Builds Trust	Maintains public confidence in research participation

Key NIH Resources

• NIH Scientific Data Sharing Homepage
• NIH DMS Policy Summary
• NIH on Sharing & Preservation Limitations

ReferenceFrequently asked questions

📌 What is this website?

This site provides documentation for a patient registry project. It includes information on the data dictionary, governance, how to access the data, and more.

📝 Who can request access to the data?

Access policies vary by registry. Please refer to the Data Access page for current eligibility and procedures.

🔒 Are the data deidentified?

Yes. All data shared through this registry is deidentified according to HIPAA standards (or applicable regulations in your region).

⏳ How long does it take to get access?

Once a data use request is submitted with the required approvals, typical turnaround is 2 to 4 weeks.

📃 What documents are required to request data?

Usually:

• Completed Data Use Agreement (DUA)
• IRB or ethics approval documentation
• A brief proposal or justification for data use

See the DUA and IRB pages for more information.

🧩 Can I link this data with other data sets?

This depends on the registry’s policies and the identifiers available. Please contact the data custodians for guidance.

📬 Who do I contact with other questions?

Email us at your.email@institution.edu or use the contact form on the homepage.

ReferenceKey resources

Welcome to the Key Resources section. This page is designed to guide researchers, collaborators, and stakeholders to essential documents, tools, and educational materials related to patient registry research and responsible data sharing.

🏢 Your Organization(s)

• [Insert the name of your institution, sponsoring organization, or affiliated research network here]

📄 Publications from Our Registry

• [List any publications, reports, or posters based on your registry’s data. These can include DOI links, conference posters, or open-access PDFs]

📘 Book

Guide to Real world Data for Clinical Research
By Danielle Boyce (ALS TDI) and Pavel Goriacko (Montefiore)
👉 Visit rwd.guide

🎓 Online Course

Introduction to OMOP: Your Frequently Asked Questions Answered
Taught by Danielle Boyce (ALS TDI) and Pavel Goriacko (Montefiore)
👉 Enroll in the course

🌐 External Links and Policy Guides

• NIH Data Sharing Language Explained
  A plain-language guide to the NIH Data Management & Sharing Policy and how it applies to patient registries.

• PubMed, Search for biomedical and life sciences literature.

• ClinicalTrials.gov, Information on publicly and privately supported clinical studies.
• NIH Sharing Policies, Learn about federal data sharing policies.
• FDA Real world evidence, Explore how real world data are used in regulatory decisions.
• EMA Real world evidence, European guidance on using real world data sources.

CreditsAcknowledgements

🧑‍🔬 Project Team

• Dr. Danielle Boyce, Principal Investigator
• [Your Name Here], Project Coordinator
• [Team Member Name], Data Manager

🏛️ Partner Institutions

• [Institution 1 Name]
• [Institution 2 Name]
• [Funding Agency Name, if applicable]

💸 Funding Support

This work was supported by:

• [Grant Name or Number]
• [Institutional Support Description]

🤝 Collaborators

We also thank the advocacy groups, clinicians, and researchers who have helped shape the design and use of this registry.

Keep goingRelated across EpilepsyLive

Where to go next, across the Learn shelf and the rest of the site.