Registry·Demo Registry ToolkitLive MonitorEcosystemLearnGuide Suggest a correction
Demonstration and educational project. Not medical, legal, or regulatory advice. Every participant, record, and organization shown is fictional or illustrative. Sample and template language must be reviewed and adapted with your own IRB and legal counsel before any real use. Not affiliated with, endorsed by, or representing any advocacy group, registry, company, or institution named.

Course · under construction

Registries 101

A 22-module course on building a research registry that someone else can use. The modules are in production. The full curriculum is published below so you can see what is coming, use the objectives as your own checklist, and tell me what is missing.

Status

No module is complete. What is published is the curriculum: scope, objectives, and cross-links. If a module you need is only outlined and you would use it, say so, that is how the production order gets set.

Part 1 · Before you collect anything

Four modules that cost nothing but an afternoon each, and that determine whether everything after them will pay off.

Module 1 · The question comes first Draft in progress

A registry is an answer to a question you asked first. This module is about writing the question down and defining what would count as an answer.

By the end you can

  • State a research question specific enough that you would recognize the answer
  • Distinguish questions that need longitudinal data from questions that need a defensible count
  • Name who needs the answer and what they will do with it
  • Decide honestly what happens if the question is never answered

Module 2 · What you already hold Draft in progress

Most groups hold more than they think. The gap is usually documentation rather than collection.

By the end you can

  • Complete an asset and evidence map for your own organization
  • Identify assets that are not usually counted as data, minutes, abstracts, past survey exports
  • Read the empty cells as a roadmap rather than a failure

Module 3 · Where you actually are Draft in progress

Five tracks, five stages, and the rule that your composite stage is the lowest one you have reliably reached.

By the end you can

  • Place your organization on all five maturity tracks
  • Explain why governance caps every other track
  • Identify the kind of outside help that exists at your stage

Module 4 · Registry, natural history study, or something else Outlined

These are not synonyms, and choosing the wrong one is an expensive way to learn the difference.

By the end you can

  • Distinguish a contact registry, a participant-reported registry, a natural history study, and a clinical trial readiness cohort
  • Match each design to the kind of question it can answer
  • Recognize when the honest answer is that you do not need any of them yet
In this siteLive Monitor

Part 2 · Designing what you collect

The decisions that are cheap now and very expensive to reverse eighteen months in.

Module 5 · Instruments and variables Outlined

Where a validated instrument exists, use it even if it is imperfect. Where none exists, say so in your documentation.

By the end you can

  • Find whether a validated instrument exists for what you want to measure
  • Weigh a validated instrument against a shorter locally written one
  • Flag locally developed items so downstream users know what they are looking at
  • Sequence modules over time rather than asking everything at enrollment

Module 6 · Common data elements and what they buy you later Outlined

Harmonization is the difference between a dataset that is yours and a dataset that can be combined with anyone else's.

By the end you can

  • Explain what a common data element is and where to look for existing ones
  • Map a locally designed variable to an existing common data element
  • Describe what you lose by deciding to harmonize after collection rather than before

Module 7 · The data dictionary Draft in progress

Could an outsider understand your dataset from the documentation alone? If not, it is not shareable, however much of it you have.

By the end you can

  • Write a field-level data dictionary entry that stands on its own
  • Document derived fields, including how they were calculated
  • Publish a dictionary before publishing data

Module 8 · Who is in the registry, and who is not Outlined

Representativeness is a design problem, not a limitation you note in the discussion section.

By the end you can

  • Name the recruitment mechanisms that systematically exclude people
  • Describe how digital-first enrollment shapes a cohort
  • Build at least one measure of representativeness into the design up front
  • Report who is missing as a finding rather than a caveat

Part 3 · Getting the data

Where the money goes, and where the surprises are.

Module 9 · Platforms and what they actually do Outlined

Registry platforms, survey tools, and clinical data management systems solve overlapping but different problems.

By the end you can

  • Distinguish a survey platform from a registry platform from a clinical data management system
  • List what you must own regardless of platform, your dictionary, your consent, your export
  • Ask what happens to your data if the platform relationship ends

Module 10 · Records: five acquisition pathways Draft in progress

From a free portal download to network exchange, with an order of magnitude between the ends.

By the end you can

  • Compare the five pathways on completeness, cost, and effort
  • Match a pathway to your use case rather than to your budget
  • Recognize that imaging and raw recordings travel on a separate channel entirely

Module 11 · What clinical data looks like when it arrives Outlined

C-CDA documents and FHIR resources, what each is good at, and why the packaging varies far more than the content.

By the end you can

  • Describe the structure of a C-CDA document and of a FHIR resource
  • Explain why the same clinical fact often arrives twice
  • Distinguish the parts of processing that are specification-driven from the parts specific to your source
  • Ask a data provider a specific question about delivery format

Module 12 · Talking to vendors Draft in progress

The question bank, and the questions that waste everyone's time.

By the end you can

  • Operationalize a per-record or per-extraction quote out loud
  • Request a completed security review and know what to do with it
  • Ask for a test-patient demonstration rather than a pilot
  • Recognize what is genuinely outside a vendor's scope

Part 4 · Governance, quality, and sharing

The north star track. Nothing above this line holds up if this part is missing.

Module 13 · Consent that permits what you will want to do Draft in progress

Groups discover their consent does not permit future sharing at the worst possible moment.

By the end you can

  • Read your own consent for future-use and sharing language
  • Explain broad consent, dynamic consent, and re-contact permission
  • Estimate the real cost of re-consenting a community

Module 14 · Standing up a data access committee Outlined

Three volunteers and a written rubric is a functioning committee. The rubric does more work than the roster.

By the end you can

  • Draft a data access committee standard operating procedure
  • Build an evaluation rubric that makes decisions consistent and defensible
  • Decide in advance what you will refuse

Module 15 · Data quality as a practice, not an audit Outlined

Conformance, completeness, and plausibility, and the difference between unmapped and wrong.

By the end you can

  • Apply a recognized data quality taxonomy to your own dataset
  • Set thresholds that fail a data load rather than being noted afterward
  • Explain why coverage metrics are necessary but not sufficient
  • Design a clinical spot review cheap enough that it actually happens

Module 16 · Privacy on the way out Outlined

Which artifacts carry identifiers, and the pattern of pseudonymizing at the boundary rather than at construction.

By the end you can

  • Audit your own outputs for direct identifiers
  • Apply the produce-once, pseudonymize-on-the-way-out pattern
  • Bring three specific questions to your IRB about a proposed disclosure

Module 17 · Sharing, and what FAIR means without a budget Outlined

Publishing discoverable metadata is possible even when the raw data stays controlled.

By the end you can

  • Distinguish findable, accessible, interoperable, and reusable, and score yourself on each
  • Publish metadata for a dataset you are not ready to release
  • Choose between a repository deposit, a partner agreement, and a controlled-access portal

Part 5 · Modern practice

The parts of this work that changed in the last few years, and that most introductory material has not caught up with.

Module 18 · Participant-mediated and decentralized data Outlined

People can now retrieve, hold, and contribute their own records. That changes what a small organization can do alone.

By the end you can

  • Describe participant-directed record retrieval and what it makes possible
  • Weigh participant-mediated collection against vendor-mediated collection
  • Design a workflow that returns something useful to the participant

Module 19 · Network exchange and the policy layer Planned

Nationwide exchange frameworks, individual access, and information blocking rules, what they promise and what they currently deliver.

By the end you can

  • Explain network exchange and individual access services in plain language
  • Identify the coverage and identity-verification gaps that determine real-world yield
  • Decide whether to wait for the networks or work around them
In this siteGuide: TEFCA

Module 20 · AI in registry workflows Planned

Where language models genuinely help, where they quietly cost you your data quality, and what has to be validated before output leaves the building.

By the end you can

  • Distinguish tasks where model output can be checked from tasks where it cannot
  • Describe why free-text extraction is a research problem rather than a configuration step
  • Set a validation standard before adopting any automated extraction
  • Document provenance for anything machine-derived

Module 21 · Evidence that regulators can use Planned

What changes when the audience for your data is a regulatory submission rather than a paper.

By the end you can

  • Explain fitness for purpose and why it is a property of a use, not a dataset
  • Describe the provenance and traceability expectations that follow
  • Identify what a registry would need to add to support an external control arm

Module 22 · Will anyone actually use it Draft in progress

Implementation science, and the six-month test. The last module because it is the one people skip.

By the end you can

  • Apply a recognized implementation framework to your own registry plan
  • Name a facilitator, a person whose job is adoption
  • Answer the six-month test honestly and write down what it exposes

Using the curriculum before the course exists

The objectives are written so they work as a self-audit. Take any module and ask whether your organization can already do the four things listed. Where the answer is no, the cross-linked page is usually the fastest route to yes.

That is not a substitute for the module. It is, however, most of the value, and it is available now.

Under construction