follow-the-data — Boyce Data Science

1The route every data type follows

A registry is a set of promises made to participants, kept through a chain of technical decisions. The chain has the same links whichever data type is passing through it. Naming the links once means each data type section below can be read as a set of answers to the same questions.

Stage	The question it answers	Common mistakes
Consent	What did the participant agree to, for how long, and for whom?	Consent language written for one data type and later stretched to cover others it never mentioned.
Collection	How is the data captured, by whom, on what device or form, and in what raw format?	Raw files kept without the device settings, form version, or protocol version that give them meaning.
Standardization	Which vocabulary, model, or file standard makes this data comparable with someone else's?	Standardizing at the end instead of at design time, when the fields needed for the mapping no longer exist.
Storage and governance	Where does it live, who can reach it, how is it de-identified, and how is access logged?	Identifiers stored beside the data, or a de-identification method chosen without checking whether the data type can even be de-identified that way.
Linkage	How is this record tied to the same participant's other records and to the right point in time?	Different identifier schemes per data type, and timestamps in local time with no zone recorded.
Analysis	Which methods fit this data, and what do they answer?	Methods borrowed from a different data type, or an analysis that needed a design decision made at collection time.
Sharing and return	How does the data leave the registry, to whom, and what goes back to participants?	No repository or format chosen in advance, so the data sharing plan promised to a funder cannot be met.

The most useful habit this guide can teach: for every new data type, fill in the seven rows above before the first participant is enrolled. The sections that follow do exactly that for each type.

2Consent and governance across every data type

Consent is the first data element a registry collects, and it has a structure of its own. The choices below apply to all of the data types in this guide; the type-specific sections say where a given type needs more.

Consent models

Study-specific consent covers one protocol. It is the simplest to explain and the hardest to reuse.
Broad consent permits future research within described limits. Under the revised US Common Rule it has defined content requirements and requires tracking of refusals. Registries that intend to support many future studies usually need it.
Tiered or dynamic consent lets a participant say yes to some uses and no to others (for example, EHR linkage yes, whole genome sequencing no, commercial use no), and change those answers later. This requires a consent record that is itself structured data, with one field per permission and a full history of changes.
Assent and re-consent apply when children enroll and later reach the age of majority, and when a participant dies or loses capacity. Rare disease registries in particular need a written plan for each of these.

What the consent record should contain as data

Store the consent as coded fields, not only as a signed PDF. The GA4GH Data Use Ontology (DUO) gives standard codes for permitted uses (general research use, disease-specific research, no commercial use, and so on) that can be attached to each dataset and checked automatically when an access request arrives. At minimum, record: consent form version, date, permissions by data type, permission to re-contact, permission to return results, permission to share with external researchers, permission for commercial use, and a withdrawal status with date and scope.

Withdrawal, per data type

A participant who withdraws is asking for something different depending on the data. Decide in advance, write it into the consent, and build the mechanism before it is needed.

Data type	What withdrawal can realistically mean
EHR extracts and surveys	Stop new collection; existing de-identified data used in completed analyses usually stays, and the form should say so.
Biological samples	Destroy remaining aliquots; derived omics data already generated may be retained or deleted depending on the consent language.
Genomic data	Cannot be fully de-identified; withdrawal should trigger removal from any controlled-access repository submission not yet released.
Voice recordings and images	Raw media are identifiable; withdrawal usually means deleting raw media while retaining derived features if consented.
Wearable streams	Revoke the device or app authorization and stop the feed; decide whether already-received days are kept.

Electronic consent

eConsent platforms (REDCap's eConsent framework is common in academic registries) capture the signature, the version shown, and a PDF snapshot, and they can branch the form so that each tier is a separate question. The FDA and OHRP issued joint guidance on electronic informed consent that describes what an eConsent process needs to do.

Governance documents to write before enrolling

Data management and sharing plan. NIH requires one for funded research; the NIH DMS policy pages describe the required elements and the repositories NIH recognizes.
De-identification standard. Under HIPAA, either Safe Harbor (remove the listed identifiers) or Expert Determination; the HHS guidance explains both. Some data types (genomes, raw voice, facial imaging) cannot meet Safe Harbor and need a controlled-access model instead.
Data access policy and committee. Who reviews requests, on what timeline, and against which DUO codes.
Data use agreement templates for external researchers, and a material transfer agreement template for samples.
Registry protocol. The AHRQ guide Registries for Evaluating Patient Outcomes: A User's Guide is the standard reference for what a registry protocol contains.
Trusted research environment decision. Whether analysts come to the data (enclave) or the data goes to analysts (download), and what that means for the storage design in every section below.

3Electronic health record data

EHR data are the most common registry input and the one most often mistaken for a single thing. An EHR extract is a set of tables (diagnoses, procedures, medications, laboratory results, encounters, notes) written for billing and care, each with its own vocabulary and its own quirks. The route below assumes the registry receives extracts from one or more health systems.

Consent	Permission to obtain records from named or unnamed providers, a HIPAA authorization where the registry is not a covered entity, and a statement about how far back and how far forward the records may be pulled. Many registries also collect a medical release form per provider.
Collection	Options in rough order of effort: participant-uploaded portal downloads, a health information exchange query, FHIR API pulls (the US Core profiles most systems now expose), a direct extract negotiated with the health system's data warehouse, or a commercial aggregator. Record the source, extraction date, and the source system's own vocabulary version for every load.
Standardization	Map to the OMOP Common Data Model, using the OHDSI standardized vocabularies (SNOMED CT for conditions, RxNorm for drugs, LOINC for measurements, ICD as source codes). If the extract arrives as FHIR, the OHDSI community maintains FHIR-to-OMOP mapping guidance. Keep the source values beside the mapped concept so mappings can be audited and redone.
Storage and governance	A relational database (PostgreSQL is the usual choice for OMOP), with the identified person table separated from the analytic tables and dates shifted or kept according to the de-identification standard. Free-text notes are identifiable and need either de-identification tooling or an enclave.
Linkage	A registry participant ID mapped to each source system's medical record number in a crosswalk table kept outside the analytic database. Encounter dates give the time axis that other data types are aligned to.
Analysis	Cohort characterization, incidence and prevalence, treatment pathways, comparative effectiveness with propensity methods, computable phenotyping, natural language processing on notes, and patient-level prediction. The OHDSI tool stack (ATLAS, HADES packages in R) covers all of these against an OMOP database.
Sharing and return	OMOP-formatted data can join federated network studies without leaving the registry. For sharing outside, a de-identified OMOP extract with a data use agreement is the usual unit.

Learn more: EHR data and OMOP documentation, tutorials, and recorded workshops

The Book of OHDSI, the open textbook for the whole OMOP and OHDSI approach; chapter 4 covers the common data model.OHDSI
OMOP CDM Workshop, March 2022, a two-session recorded workshop led by the CDM working group.videoOHDSI community call
OMOP Common Data Model and Standardized Vocabularies, full 2019 tutorial.videoOHDSI Symposium
Developing and evaluating your ETL process to the OMOP CDM, 2025 tutorial.videoOHDSI Symposium
What is the OMOP Common Data Model, a short introductory lecture.videoUC Davis
HL7 FHIR US Core implementation guide, the profiles most US EHR APIs expose.HL7
HADES, the OHDSI R packages for characterization, estimation, and prediction.OHDSI

4Patient reported outcomes and medical history surveys

Surveys are the data type the registry controls most completely, which makes them the easiest place to get standardization right and the most common place to get it wrong. A home-grown question that resembles a validated instrument cannot be compared with anything outside the registry.

Consent	Permission for repeated contact on a stated schedule, and a statement about whether responses can prompt clinical follow-up (a suicidality item in a mood instrument, for instance, needs a response plan written before the survey goes live).
Collection	An electronic data capture system with versioned forms, skip logic, and an audit trail. REDCap is the most common in academic registries; commercial systems and FHIR Questionnaire-based apps are alternatives. Record the instrument version, the language, the mode (self, proxy, interviewer), and the completion date for every response.
Standardization	Use validated instruments with known scoring (PROMIS, PedsQL, EQ-5D, disease-specific scales) and code the items to LOINC where codes exist. For the medical history section, draw items from an existing common data element set: the NIH CDE Repository and the NINDS common data elements (which include epilepsy and ALS sets) already define response options and permissible values. Phenotype descriptions belong in HPO terms, so the survey should ask questions that can be coded to HPO rather than free text.
Storage and governance	Survey data are usually the least sensitive type and can often meet Safe Harbor once dates are handled. Free-text fields are the exception and should be minimized or reviewed before release.
Linkage	Survey responses map into the OMOP observation and measurement tables (the survey_conduct table records the instrument instance), which keeps them on the same time axis as the EHR. HPO-coded phenotypes can also be written into a Phenopacket for each participant.
Analysis	Descriptive statistics and score trajectories over time (mixed-effects models), minimal clinically important difference analyses, psychometric evaluation of the instrument itself, comparison of proxy and self report, and missing data handling, since survey nonresponse is rarely random.
Sharing and return	Aggregate results returned to participants (dashboards, newsletters) are the most direct way to keep response rates up. Item-level data with a data dictionary is the sharing unit; the NIH CDE Repository format doubles as a dictionary.

Learn more: surveys, PROs, and common data elements

HealthMeasures, home of PROMIS, Neuro-QoL, and the scoring services for each.Northwestern University
NIH Common Data Element Repository, searchable and downloadable CDE sets across institutes.NIH NLM
NINDS Common Data Elements, disease-specific sets with case report forms.NIH NINDS
REDCap training resources, including the recorded introductory videos.videoVanderbilt University
FDA guidance on patient reported outcome measures, the reference for what makes an instrument fit for regulatory use.FDA

5EEG

EEG is a time series recorded at hundreds of samples per second on tens of channels, plus the annotations a reader places on it. A registry can hold the clinical report only, the report plus the raw recording, or a research-protocol recording collected specifically for the registry. Each choice changes the whole route.

Consent	Clinical EEG reports are part of the medical record and follow the EHR consent. Raw recordings need explicit permission, and a research EEG session needs its own procedure consent. State whether recordings may be shared as raw files, since EEG is generally not considered directly identifying but can contain patient names in file headers and technician notes.
Collection	Clinical systems export in vendor formats; ask for European Data Format (EDF or EDF+) or BrainVision, which most tools read. Capture the sampling rate, channel montage and reference, filter settings applied at acquisition, electrode positions, recording state (awake, asleep, sedated), and any stimulation protocol. Without these, the recording cannot be reprocessed.
Standardization	Organize files with EEG-BIDS, the Brain Imaging Data Structure extension for EEG, which fixes folder names, sidecar metadata, and event files so that analysis pipelines run without custom loaders. The reader's findings (spike location, background slowing, seizure type) belong in the structured record coded to SNOMED CT or HPO, not only in a PDF report. Seizure classification should follow ILAE terminology.
Storage and governance	Raw EEG is large (hours of recording at 256 Hz or higher across many channels); object storage with the BIDS folder tree and a metadata index in the registry database is the usual pattern. Strip header identifiers at ingest and keep the original in the identified zone.
Linkage	The recording start timestamp with time zone, tied to the participant ID and to the encounter in the EHR. Medication timing relative to the recording is often the analytic question, so the alignment has to be exact.
Analysis	Preprocessing (filtering, artifact removal, re-referencing, independent component analysis), spectral analysis (power in delta, theta, alpha, beta, gamma bands), connectivity measures, event detection (spikes, seizures) by rule-based or machine learning methods, and feature extraction for comparison across visits. Tools: MNE-Python, EEGLAB (MATLAB), and Brainstorm.
Sharing and return	BIDS-formatted datasets can be deposited in OpenNeuro when consent allows. Derived features (band power summaries) are far easier to share than raw recordings.

Learn more: EEG standards and analysis

MNE-Python tutorials, a narrated sequence from loading raw data through preprocessing, epoching, and time-frequency analysis.MNE project
Analysing EEG data with MNE in Neurodesk, a worked notebook using BIDS-formatted sample data.Neurodesk (academic consortium)
Brain Imaging Data Structure, the specification and starter kit.BIDS community
ILAE definition and classification of seizures and epilepsies.ILAE
PhysioNet, open physiological signal datasets, including EEG, for practicing methods.MIT (NIH-funded)

6Imaging reports and images

Most registries hold the radiology report and, when they can, a pointer to the images themselves on a separate server. The report is text and follows the EHR route with a few additions; the images are DICOM objects with their own standards and their own identifiability problems.

Consent	Reports follow the EHR consent. Image transfer needs explicit permission and a statement about facial reconstruction risk for head MRI and CT, since 3D reconstructions of the face are identifiable.
Collection	Reports arrive as text or as FHIR DiagnosticReport resources. Images arrive as DICOM studies, either pushed from the site's PACS or fetched via DICOMweb. Capture the modality, scanner, sequence parameters, and the report date, and keep the report's impression section distinguishable from the findings section.
Standardization	Code report findings to RadLex or SNOMED CT and the procedure to LOINC or the RadLex Playbook. Images keep DICOM as the container; for research processing, convert to NIfTI and organize with BIDS (MRI) so the same folder structure serves imaging and EEG. Structured reporting templates from the RSNA reduce the free-text problem at the source.
Storage and governance	Images live on an imaging server (an open source PACS such as Orthanc, or an XNAT instance) rather than in the registry database; the registry stores the study identifier and a link. DICOM headers hold dozens of identifying tags; the DICOM standard's de-identification profiles list what to remove, and defacing is needed for head images before release.
Linkage	The DICOM study instance UID and accession number mapped to the participant ID and encounter, with the report tied to the same study. The link the participant follows from the registry to the image server should hold only the study identifier, never the participant identifier.
Analysis	Natural language processing on report text (finding extraction, negation handling), volumetric and morphometric analysis (FreeSurfer, FSL, SPM), radiomics feature extraction, and deep learning classification or segmentation. Cross-sectional comparison and longitudinal change are the common registry questions.
Sharing and return	De-identified DICOM or NIfTI deposited in a domain repository (OpenNeuro for BIDS neuroimaging; the NIH-supported Cancer Imaging Archive for oncology). Reports are shared as coded findings rather than as text.

Learn more: imaging standards and analysis

DICOM standard, current edition; Part 15 covers de-identification profiles.DICOM Standards Committee
XNAT, an open source imaging informatics platform built for research.Washington University in St. Louis
Orthanc, a lightweight open source DICOM server.Open source
RSNA data tools and standards, including RadLex and structured reporting templates.RSNA
The Cancer Imaging Archive, an example of a de-identified imaging repository and its submission process.NCI
NIH VideoCast past events, searchable for imaging science lectures (the John Doppman Memorial Lecture series among them).videoNIH

7Biological samples and multiomics

A sample is a physical object whose value depends on paperwork: how it was collected, how long it sat, at what temperature, and what the participant agreed could be done with it. The omics data generated from it inherits all of that, and adds file sizes and identifiability problems no other data type has. This section covers the sample itself first, then each omics layer.

The sample

Consent	Sample type, future use scope, whether the sample may be shared with other institutions or companies, whether cell lines may be derived, whether results (especially genetic results) will be returned, and what happens to the sample on withdrawal. Genomic data cannot be anonymized; the consent has to say that the registry will use controlled access instead of promising anonymity.
Collection	A collection protocol with the pre-analytic variables recorded per sample: collection time, fasting state, processing delay, centrifugation, aliquot count, freeze time, and storage temperature. The SPREC code (Standard PREanalytical Code) packs these into a short string. Blood, saliva, urine, cerebrospinal fluid, and tissue each have their own protocol.
Standardization	MIABIS (Minimum Information About Biobank data Sharing) defines the sample and collection attributes a biobank should be able to describe. ISO 20387 is the biobanking quality standard. Sample types are coded with the OBI or SNOMED CT specimen hierarchies, and a Phenopacket can hold a Biosample element linking the sample to the participant's phenotype.
Storage and governance	A laboratory information management system (LIMS) or biobank system tracks freezer location, aliquots, and chain of custody. The registry database holds the sample ID and metadata, not the physical location. A material transfer agreement template governs every sample that leaves.
Linkage	Sample ID to participant ID, with the collection timestamp aligned to the clinical timeline (which visit, what medications at the time). This alignment is what makes a metabolomics result interpretable later.
Analysis	The sample itself is analyzed only by the assays run on it; the registry's analytic job is to track which assays have been run on which aliquots so that a future study can be planned against remaining material.
Sharing and return	Samples are shared under a material transfer agreement and an access committee decision. Return of individual genetic results, if promised, requires a CLIA-certified confirmation and a genetic counseling pathway.

The omics layers

Each layer measures a different class of molecule, produces a different file type, and is analyzed with its own methods. The table names the layer, what it measures, the usual assay, the raw and processed formats, the repository the field expects, and the main analytic approaches. Genomics is the identifiable layer; the others are less directly identifiable but can be re-identified when combined with a genome.

Omics layers compared what each layer measures, its formats, repositories, and analyses

Layer	What it measures	Usual assay	Formats	Repository	Main analyses
Genomics	DNA sequence: variants, structural changes, copy number	Whole genome, whole exome, targeted panels, arrays	FASTQ (reads), BAM or CRAM (aligned), VCF (variants)	dbGaP, AnVIL, EGA (Europe)	Variant calling, annotation (ClinVar, gnomAD), rare variant burden, polygenic scores, phenotype-driven prioritization with HPO (Exomiser)
Epigenomics	DNA methylation, chromatin accessibility, histone marks	Methylation arrays, bisulfite sequencing, ATAC-seq	IDAT (arrays), FASTQ, BED, bigWig	GEO, dbGaP	Differential methylation, epigenetic clocks, peak calling
Transcriptomics	RNA abundance: which genes are expressed and how much	Bulk RNA-seq, single-cell RNA-seq, arrays	FASTQ, count matrices, h5ad or Seurat objects (single cell)	GEO, SRA	Differential expression (DESeq2, edgeR), clustering, cell type annotation, pathway enrichment
Proteomics	Protein abundance and modifications	Mass spectrometry (DDA, DIA), affinity panels (Olink, SomaScan)	mzML (HUPO-PSI open format), vendor raw, intensity matrices	PRIDE	Peptide identification, quantification, differential abundance, normalization for batch
Metabolomics	Small molecules: metabolites in blood, urine, CSF	LC-MS, GC-MS, NMR; targeted or untargeted	mzML, feature tables, Metabolomics Standards Initiative reporting	Metabolomics Workbench, MetaboLights	Peak picking and alignment, annotation, univariate and multivariate comparison, pathway analysis
Lipidomics	Lipid species, a subset of the metabolome with its own methods	LC-MS with lipid-specific libraries	mzML, lipid tables	Metabolomics Workbench	As metabolomics, with lipid class summaries
Microbiome	Microbial community composition and function	16S rRNA amplicon, shotgun metagenomics	FASTQ, feature tables (BIOM), taxonomy tables	SRA, Qiita	Diversity metrics, compositional data analysis, differential abundance

Where multiomics analysis begins

Single-layer analysis compares participants within one layer. Multiomics integration asks whether patterns across layers, in the same participants, explain more than any layer alone. The prerequisite is not statistical; it is that the same participant IDs, sample timestamps, and batch labels exist in every layer's table. Methods once that prerequisite is met:

Unsupervised factor models such as Multi-Omics Factor Analysis (MOFA) find shared and layer-specific sources of variation.
Similarity network fusion builds a participant-by-participant network per layer and merges them.
Pathway-level integration maps each layer onto shared pathway databases (Reactome, KEGG) and tests pathways rather than molecules.
Supervised integration uses penalized regression or machine learning with features from every layer, with cross-validation that keeps whole participants in one fold.
Batch and confounding control comes first in every case: collection site, assay run date, and storage time explain more variation than disease in many registry datasets.

Learn more: omics and multiomics standards, repositories, and recorded lectures

Introduction to multi-omics data integration and visualisation, the full on-demand course materials with recorded lectures on integration methods, MOFA, data standards and ontologies, Cytoscape, and Reactome (CC BY 4.0).videoEMBL-EBI Training
EMBL-EBI on-demand training, short courses on genomics, proteomics, metabolomics, and the repositories that hold them.EMBL-EBI
NIH VideoCast proteomics lecture archive, including the Proteomics Interest Group seminar series.videoNIH
A pragmatic approach to clinical proteomics.videoNIH VideoCast
Metabolomics Workbench, the NIH Common Fund repository, with tutorials and the standards it expects.NIH Common Fund
dbGaP, the NIH controlled-access repository for genotype and phenotype data, with submission guidance.NIH NCBI
NHGRI educational resources, including recorded lecture series on genomics.videoNIH NHGRI
GA4GH standards: VRS for variant representation, htsget for sequence transfer, Beacon for discovery, Passports for access, DUO for consent codes.GA4GH
Reactome, the open pathway database used for pathway-level integration in the EMBL-EBI course above.Reactome (OICR, NYU, EMBL-EBI)

8Wearables, accelerometry, and voice recordings

Digital data types arrive continuously, at high frequency, from devices the registry does not control, and they are the types most likely to be collected before anyone has decided what to do with them. Deciding the analytic unit in advance (a day of activity, a night of sleep, a thirty-second voice task) is what makes them usable.

Wearables and accelerometry

Consent	Which device, what it collects (acceleration only, or heart rate, location, sleep), how long it is worn, whether data flow through a vendor cloud, and whether the vendor's terms give the vendor its own rights. Location data are identifying and usually excluded.
Collection	Research-grade accelerometers (ActiGraph, Axivity, GENEActiv) export raw triaxial acceleration at 30 to 100 Hz; consumer devices export summaries through a vendor API. Record the device model, firmware, sampling rate, wear location, and the wear protocol. Non-wear time and device delivery days have to be detected before anything else.
Standardization	Raw acceleration in an open format (CSV or the device's open binary with documentation). Derived summaries follow Open mHealth schemas or the IEEE 1752 mobile health data standard. Open-source metrics such as ENMO (from GGIR) and MIMS units are reproducible across device brands; vendor "activity counts" are not.
Storage and governance	Raw streams are large and low-sensitivity on their own; daily summaries are small and are what most analyses need. Store both, with the processing pipeline version recorded on every summary row.
Linkage	Device ID to participant ID with wear start and end timestamps in UTC plus the participant's time zone, so that a night of sleep or a day of activity can be aligned with medication and event dates in the EHR and survey data.
Analysis	Non-wear detection, activity intensity classification, sleep detection, step and gait metrics, circadian rhythm measures, functional data analysis of the full daily curve, longitudinal mixed models on daily summaries, and machine learning activity recognition. R packages GGIR and adept, and Python packages such as GaitPy and FLIRT, are the open tools.
Sharing and return	Daily summaries with the pipeline version are the sharing unit. Returning a participant's own activity summary is a low-risk, well-received form of result return.

Voice recordings

Consent	Voice is a biometric identifier. Consent has to distinguish raw audio (identifiable, controlled access only) from derived acoustic features (shareable under a data use agreement), and state whether recordings may be used to train models. The NIH Bridge2AI Voice consortium wrote its protocols around exactly this split.
Collection	A standardized task set (sustained vowel, reading passage, free speech, diadochokinetic tasks) recorded with a documented microphone, sampling rate (44.1 kHz or higher), and quiet-room instructions, through an app that records the task ID and duration. Recording conditions explain more variation than disease if they are not controlled.
Standardization	Lossless audio (WAV or FLAC) with a metadata sidecar per recording. Acoustic features extracted with open tools (openSMILE, Praat, Parselmouth) using a published feature set (eGeMAPS is the common baseline) so that features are comparable across studies.
Storage and governance	Raw audio in the identified zone with strict access logging; derived features in the analytic zone. Transcripts of free speech are also identifying and stay with the raw audio.
Linkage	Recording ID to participant ID and task ID, with the recording timestamp aligned to the clinical timeline. Repeated recordings over visits are the main design.
Analysis	Acoustic feature extraction (pitch, jitter, shimmer, harmonics-to-noise ratio, spectral features, speech rate and pause metrics), statistical comparison between groups and over time, and machine learning classification or regression with cross-validation by participant. Explainability methods are expected for any model that will be reported.
Sharing and return	Derived features are deposited under a data use agreement (the Bridge2AI Voice dataset on PhysioNet is the reference example of a derived-feature release with a separate controlled-access raw audio tier).

Learn more: wearables and voice

Data analytics in physical activity studies with accelerometers: a scoping review, which catalogs the analytic methods in use and when each fits.PubMed Central
An open-source monitor-independent movement summary (MIMS) for accelerometer data.PubMed Central
GGIR, the R package for raw accelerometer processing, with its documentation and vignettes.CRAN
The PAAWS dataset: labeled laboratory and free-living accelerometer data, useful for learning activity recognition methods on real data.PubMed Central
NIH Bridge2AI program, including the Voice as a Biomarker of Health project and its training materials.NIH Common Fund
Bridge2AI Voice consortium, with the multi-disorder voice protocols and the Voice AI Symposium recordings.videoUSF and Weill Cornell (NIH-funded)
Bridge2AI-Voice dataset on PhysioNet, an example of a tiered voice data release.PhysioNet (MIT)
FDA Digital Health Center of Excellence, the regulatory reference for digital health technologies used in research.FDA

9Linking it all together

A multimodal registry becomes more than a set of silos through three tables and one discipline. The tables are the participant crosswalk, the event timeline, and the provenance log. The discipline is that nothing enters the analytic zone without a row in each.

The participant crosswalk

One registry participant ID, generated by the registry and meaningless outside it, mapped to every source identifier: medical record numbers per health system, sample IDs, device IDs, recording IDs, DICOM study UIDs, and survey record IDs. This table lives in the identified zone, is the only table that can re-identify anyone, and is the table an analyst never sees.

The event timeline

Every data item is placed on one time axis, in UTC with the participant's time zone recorded. Encounters, sample draws, EEG sessions, imaging studies, survey completions, wear periods, and recording sessions all become events, and OMOP's observation period and visit tables can serve as this timeline for the clinical types. The timeline is what allows "EEG within thirty days of a medication change" to be a query rather than a project.

The provenance log

For every dataset in the analytic zone: source, extraction date, pipeline name and version, vocabulary version, and the person who ran it. Reproducibility of any registry analysis depends on this table more than on the analysis code. The FAIR principles describe what the log makes possible; RO-Crate is one packaging format that keeps provenance with the data when it is shared.

Phenopackets as the participant-level summary

A GA4GH Phenopacket is a single structured document per participant holding HPO-coded phenotypes with onset and severity, diseases, measurements, biosamples, genomic interpretations, and medical actions. For a rare disease registry it is the natural export unit: everything the registry knows about one participant, in a format that diagnostic and matching tools can read directly.

10Standards and models, explained once

When a registry planner reads "we use OMOP and FHIR and HPO and Phenopackets," the sentence is describing four different kinds of thing: a database model, an exchange format, a vocabulary, and a document schema. The glossary sorts them by kind so the combinations make sense.

Data models and exchange formats

OMOP Common Data Model: A relational database design for observational health data (person, condition, drug exposure, measurement, observation, visit, and more) paired with standardized vocabularies. Its purpose is analysis: once data are in OMOP, the same analytic code runs anywhere. Maintained by the OHDSI community.
HL7 FHIR: An exchange standard: resources (Patient, Observation, Condition, DiagnosticReport, Questionnaire) with a REST API. Its purpose is moving data between systems. Registries receive FHIR and store OMOP; the two are complementary.
GA4GH Phenopackets: A schema for one participant's phenotypic and clinical picture, built for rare disease and extended for cancer. Its purpose is sharing a computable case description with diagnostic tools and other registries. A Phenopacket is generated from the registry, not used as its database.
CDISC standards (CDASH, SDTM, ADaM): The clinical trial submission standards required by FDA and PMDA. A registry that expects to support regulatory submissions or to feed trial recruitment benefits from CDASH-aligned case report forms.
BIDS: A folder-and-metadata convention for neuroimaging and neurophysiology data (MRI, EEG, MEG, iEEG). Its purpose is making raw data pipelines run without custom code.
DICOM: The medical imaging file and network standard. Every clinical image arrives as DICOM.
Open mHealth and IEEE 1752: Schemas for mobile and wearable health measures (step count, heart rate, sleep episode) so that device summaries from different vendors can be compared.

Vocabularies and ontologies

Human Phenotype Ontology (HPO): A structured vocabulary of phenotypic abnormalities with parent-child relationships, so that "focal seizure" is computably a kind of "seizure." Its purpose is deep phenotyping that algorithms can reason over; it is the phenotype language of rare disease diagnosis and of Phenopackets.
SNOMED CT: The clinical terminology covering conditions, procedures, findings, and specimens. The OMOP standard vocabulary for conditions.
LOINC: Codes for laboratory tests, measurements, and survey items. The OMOP standard for measurements and the way a PRO item becomes comparable across studies.
RxNorm: Normalized names and codes for medications, from the NLM. The OMOP standard for drugs in the US.
ICD-10-CM and ICD-11: Diagnosis classification used for billing. Present in nearly every EHR extract as a source code; mapped to SNOMED CT in OMOP.
Orphanet (ORPHAcodes) and Mondo: Rare disease nomenclatures. Mondo unifies Orphanet, OMIM, and others into one disease ontology used in Phenopackets and by the Monarch Initiative.
Data Use Ontology (DUO): Codes for consent-based data use conditions. Attached to a dataset, they let an access system check a request automatically.
Common data elements (CDEs): Not a vocabulary but a set of pre-defined question-plus-answer-options pairs. The NIH CDE Repository and the NINDS disease-specific sets are the sources; using them is the fastest route to a registry that can pool with others.

Omics and signal file standards

FASTQ, BAM, CRAM, VCF: Sequencing reads, aligned reads (CRAM is the compressed form), and called variants. Specifications are maintained by the GA4GH file formats working group.
mzML: The open XML format for mass spectrometry output, from the HUPO Proteomics Standards Initiative; used for proteomics and metabolomics.
EDF and EDF+: The open format for physiological time series, especially EEG and polysomnography.
NIfTI: The research neuroimaging volume format that DICOM series are converted to for processing.
WAV and FLAC: Lossless audio containers for voice recordings.

11Analytic methods, and what each one answers

The methods below appear throughout the data type sections. Each entry says what question the method answers, which data types it fits, and where to learn it from a government or academic source. A registry rarely needs all of them; it needs to know which of its questions correspond to which method before the data are collected, because several methods require design decisions made at that point.

Describing and comparing cohorts

Cohort characterization: What do the people in this group look like: demographics, conditions, treatments, over what observation period? The first analysis in any registry and the basis of every feasibility count. OHDSI's characterization tools run this against OMOP data. Learn: Book of OHDSI, Characterization chapter.
Incidence and prevalence: How often does an outcome occur, and how common is a condition, per unit of person-time? Requires a defined observation period per participant, which is why the OMOP observation_period table exists.
Survival and time-to-event analysis: How long until an event, accounting for people who have not yet had it? Kaplan-Meier curves, Cox models, and competing risks. Fits any registry with follow-up: time to diagnosis, to treatment change, to hospitalization. Learn: MIT OpenCourseWare biostatistics materials.
Mixed-effects and longitudinal models: How does a measure change over time within people, and does the trajectory differ between groups? The standard method for repeated PRO scores, repeated EEG features, and daily wearable summaries. Handles unequal visit spacing.
Missing data methods: What can be concluded when responses or records are absent, and is the absence itself informative? Multiple imputation, inverse probability weighting, and sensitivity analysis. Registry data are missing by design (people skip visits) more often than at random.

Estimating effects

Propensity score methods: Do treated and untreated participants differ in outcome once their pre-treatment differences are balanced? Matching, stratification, or weighting on the probability of treatment. The core of comparative effectiveness in registry data. Learn: Book of OHDSI, Population-level estimation.
Target trial emulation: What would a randomized trial of this question have looked like, and can the registry data be arranged to mimic it? A design framework that makes eligibility, treatment assignment, and follow-up explicit before the analysis starts.
Self-controlled designs: Within one person, is an outcome more frequent in the window after an exposure than in other windows? Self-controlled case series and case-crossover designs remove between-person confounding and suit drug safety questions.
Causal inference with directed acyclic graphs: Which variables must be adjusted for, and which must not, to estimate a given effect? Drawing the graph before analysis is the design step; the analysis follows from it. Learn: Causal Inference: What If (Hernán and Robins), free from Harvard.

Phenotyping and text

Computable phenotyping: Which participants have condition X, defined as a reproducible rule over codes, labs, drugs, and text? Rule-based definitions, and increasingly machine-learned ones, validated against chart review. OHDSI's PheValuator estimates their accuracy; the PheKB library holds published definitions.
Natural language processing: What do the notes and reports say, in structured form? Named entity recognition, negation detection, and, increasingly, large language model extraction, always validated against a manually annotated sample. Fits EHR notes, radiology reports, and EEG reports. Learn: NLM UMLS for the terminology layer that clinical NLP tools map to.
Semantic similarity over HPO: How close is this participant's phenotype profile to a known disease, or to another participant? Ontology-based similarity measures used in diagnosis (Exomiser, Phen2Gene) and in registry cohort discovery.video The Human Phenotype Ontology: algorithms and applications (Peter Robinson).

Signals and time series

Spectral analysis: How much of a signal's energy sits in each frequency band? The Fourier transform and power spectral density, applied to EEG (band power) and to accelerometry (activity rhythms). Learn: MNE time-frequency tutorials.
Artifact removal and source separation: Which parts of the recording are the brain and which are eye blinks, muscle, and line noise? Filtering and independent component analysis, applied before any EEG feature is trusted.
Event detection: When does a spike, seizure, step, or fall occur in a continuous stream? Rule-based detectors and trained classifiers, evaluated by sensitivity and false alarms per hour against expert annotation.
Functional data analysis: How do whole daily curves (not summary numbers) differ between groups? Treats each participant's 24-hour activity profile as one observation. Fits accelerometry and continuous glucose monitoring. Learn: the accelerometry scoping review in the wearables section above.
Acoustic feature extraction: What measurable properties of a voice recording change with disease? Pitch, perturbation (jitter, shimmer), spectral shape, and timing, extracted with a published feature set for comparability.

Omics and high-dimensional data

Differential expression and abundance: Which genes, proteins, or metabolites differ between groups, after correcting for testing thousands at once? Negative binomial models for counts (DESeq2, edgeR), linear models for intensities (limma), with false discovery rate control.
Pathway and enrichment analysis: Do the molecules that differ cluster in known biological pathways more than chance would predict? Over-representation and gene set enrichment against Reactome, GO, and KEGG.
Dimensionality reduction and clustering: What are the main axes of variation, and do participants form groups along them? Principal component analysis, UMAP, and hierarchical clustering, used first as quality control (batch effects appear here) and then for discovery.
Multi-omics integration: What do the layers share, and what is specific to each? MOFA, similarity network fusion, and pathway-level integration, described in the samples and omics section. Learn: EMBL-EBI multi-omics course materials.video
Variant interpretation: Which of the variants in a genome could explain the phenotype? Annotation against population frequency and clinical databases, ACMG classification, and phenotype-driven ranking with HPO. Learn: Sharing phenotype and disease information with Phenopackets (Peter Robinson, GHGA lecture series).video

Prediction and machine learning

Patient-level prediction: Given what is known about a person at one moment, what is the probability of an outcome in a defined window? Regularized regression, gradient boosting, and neural networks, with the model's performance reported by discrimination and calibration on held-out data. Learn: Book of OHDSI, Patient-level prediction.
Deep learning on raw signals and images: Can a model learn features directly from EEG, audio, or images instead of from hand-built features? Convolutional and transformer architectures. Requires more data than most single registries hold and careful separation of participants between training and test sets.
Explainability: Which inputs drove a model's prediction? SHAP values and saliency maps, expected in any reported model and required by some journals and regulators.
Federated analysis: How can several registries answer one question without pooling their data? Each site runs the same code on its own OMOP database and shares only aggregate results; the OHDSI network study design is the working example.

12Planning checklist

The same checklist is available as a download from the top of the page. Each item corresponds to a stage in the route; the last group is specific to multimodal linkage.

Consent and governance

Consent model chosen (study-specific, broad, tiered) and reviewed against every data type planned
Consent stored as coded fields with version history and DUO codes
Withdrawal procedure written per data type
Re-consent plan for minors reaching majority and for loss of capacity
De-identification standard chosen, with controlled access for types that cannot meet it
Data access committee, request form, and data use agreement template in place
Data management and sharing plan written with named repositories
Enclave or download model decided

Collection

For each data type: source, device or form, raw format, and metadata to capture, written down
Form and protocol versions recorded on every record
Pre-analytic variables (SPREC) recorded for every sample
Device model, firmware, sampling rate, and wear or recording protocol recorded

Standardization

Target model per data type chosen (OMOP, BIDS, DICOM, Phenopackets, Open mHealth)
Validated instruments and existing CDEs used before any new question is written
Phenotypes coded to HPO, conditions to SNOMED CT, labs to LOINC, drugs to RxNorm
Source values kept beside mapped values

Storage and governance

Identified zone and analytic zone physically separated, with access logged
Large raw files (EEG, images, audio, sequencing) in object storage with an index in the database
Header identifiers stripped at ingest (DICOM tags, EDF headers, audio metadata)
Backup, retention, and destruction schedule written

Linkage

One registry participant ID, with a crosswalk to every source identifier, kept in the identified zone
One event timeline in UTC with participant time zone
Provenance log with pipeline and vocabulary versions on every analytic dataset

Analysis and sharing

Primary questions listed, each matched to a method and to the data it requires
Design decisions the methods depend on (observation periods, task sets, batch labels) built into collection
Sharing unit per data type defined (OMOP extract, BIDS dataset, derived features, Phenopacket)
Result return plan for participants, including what will not be returned

13Learning library

Every video and course linked in this guide, in one place, with the institution that produced it. Only government, academic, and open scientific consortium sources are listed. Links were checked on 7 September 2026.

OMOP CDM Workshop, March 2022videoOHDSI
OMOP CDM and Standardized Vocabularies, full 2019 tutorialvideoOHDSI Symposium
Developing and evaluating your ETL to the OMOP CDM, 2025 tutorialvideoOHDSI Symposium
What is the OMOP Common Data ModelvideoUC Davis
The Book of OHDSIOHDSI
GA4GH Connect: Phenopackets (Jules Jacobsen, Queen Mary University of London)videoGA4GH
Sharing phenotype and disease information with Phenopackets (Peter Robinson)videoGHGA lecture series (German Human Genome-Phenome Archive)
The Human Phenotype Ontology: algorithms and applications (Peter Robinson)videoCharité, hosted lecture
Introduction to multi-omics data integration and visualisation, course materialsvideoEMBL-EBI Training
EMBL-EBI on-demand training catalogEMBL-EBI
NIH VideoCast proteomics lecture archivevideoNIH
A pragmatic approach to clinical proteomicsvideoNIH VideoCast
NIH VideoCast channel on YouTubevideoNIH
NHGRI educational resources and lecture seriesvideoNIH NHGRI
MNE-Python tutorialsMNE project
Analysing EEG data with MNE in NeurodeskNeurodesk
REDCap training videosvideoVanderbilt University
Bridge2AI Voice consortium, protocols and symposium recordingsvideoUSF and Weill Cornell (NIH Common Fund)
Causal Inference: What IfHarvard T.H. Chan School of Public Health
Registries for Evaluating Patient Outcomes: A User's GuideAHRQ