Choosing a Platform or Vendor

Platform decisions are architecture decisions

The platform you choose determines what data you can collect, how it can be structured, whether it can interoperate with EHRs, and how easily data can be exported for analysis. A platform that seems easy to launch can become a barrier to research if it lacks FHIR support, cannot export in standard formats, or locks your data in a proprietary schema.

Evaluate platforms against your scientific requirements, not just their ease of setup.

The major platform categories

Purpose built registry platforms

Designed specifically for patient registries. Typically include patient portals, clinical site interfaces, data management, and export functionality.

REDCap (Research Electronic Data Capture)

Widely used in academic research. Free to institutions with a license (over 6,000 institutions worldwide hold licenses). Highly flexible, validated, and well-understood by academic collaborators.

Pros: Free (with institutional access), flexible, validated, large user community, good export options
Cons: Not designed as a patient portal; requires technical setup; hosting requires an institutional partner or paid hosting

Key resource: REDCap Consortium

FHIR-native platforms

If EHR integration is a priority, consider platforms built on or natively supporting HL7 FHIR:

• Firely, FHIR server and tooling
• Smile CDR, Enterprise FHIR platform
• Microsoft Azure Health Data Services, Cloud FHIR infrastructure
• Google Cloud Healthcare API, FHIR R4 compatible cloud storage

These are infrastructure components, not turnkey registry solutions, you'll typically build on top of them.

Key questions to ask every vendor

Data ownership and portability

• Who owns the data? (Answer must be: the advocacy organization owns the data, always.)
• In what format can data be exported? (Require: CSV, JSON, and ideally FHIR R4)
• What is the process for full data export if we change vendors?
• Are there any data lock-in provisions?

Security and compliance

• What is your SOC 2 Type II certification status?
• Are you HIPAA-compliant? Do you sign a Business Associate Agreement (BAA)?
• Where are servers located? (Matters for GDPR if collecting international data)
• What is your data breach notification policy and history?

Interoperability

• Do you support HL7 FHIR R4?
• Can participants import their health records via SMART on FHIR / 21st Century Cures Act APIs?
• Do you support standard terminologies (SNOMED CT, LOINC, ICD-10, HPO)?

Participant experience

• Is there a patient portal with longitudinal data entry?
• Can participants view their own data?
• Is the interface accessible (WCAG 2.1 AA)?
• Does it support mobile?

Research features

• Can you define branching logic in questionnaires?
• Is there audit trail / version control on data changes?
• Does the platform support validated patient-reported outcome instruments (PROMIS, EQ-5D, etc.)?
• What analysis tools are built in vs. what requires export?

Pricing model

• Is pricing per participant, per site, per year, or by data volume?
• What does scaling cost as your registry grows?
• Are there costs for data export?
• Is there a nonprofit or advocacy organization pricing tier?

Build vs. buy

Some organizations consider building a custom registry. This is almost always a mistake for organizations without a dedicated software engineering team.

Custom builds are justified when:

• Your data architecture is uniquely complex (e.g., multiomics, imaging, biosample tracking)
• You have a large technical team and sustained engineering budget
• No commercial platform meets your FHIR/interoperability requirements

For most advocacy organizations: Choose an established platform. The ongoing maintenance burden of a custom solution, security patches, hosting, feature development, is far greater than it appears at launch.

Hosted vs. self-hosted

Most advocacy organizations should use hosted/SaaS platforms. Self-hosting requires server management, security patching, backup infrastructure, and technical staff, capabilities most advocacy organizations lack.

Exception: If you have an academic partner willing to host REDCap, this is a cost-effective and academically credible option.

Checklist

• [ ] Listed platform requirements based on registry purpose and data elements
• [ ] Confirmed HIPAA BAA is available from shortlisted vendors
• [ ] Confirmed data ownership is explicitly assigned to your organization in vendor contracts
• [ ] Confirmed full data export capability (format and process)
• [ ] Evaluated FHIR support if EHR integration is a priority
• [ ] Requested nonprofit/advocacy pricing
• [ ] Verified SOC 2 Type II certification
• [ ] Piloted platform with a small test dataset before committing
• [ ] Confirmed SAB approval of platform selection

Key resources

• AHRQ Registry User's Guide Chapter 3: Registry Design
• NORD IAMRARE Registry Program
• REDCap Consortium
• Castor EDC
• HL7 FHIR Implementation Guide Registry

← Module 3 | Module 5: Common Data Elements →