⚡EpilepsyLive ✉ Suggest a correction
Demonstration and educational project by Danielle Boyce. Not medical, legal, or regulatory advice. Sample and template language is provided for illustration and must be reviewed and adapted before any real use. Not affiliated with, endorsed by, or representing any advocacy group, registry, company, or institution named.
Learn Overview Patient Registries 101 Data Analysts Grant Writers Data Sharing in a Box
Module 10 of 19Part 3 · Data Collection

Patient-Reported Data & the 21st Century Cures Act

Goal: Understand how the 21st Century Cures Act creates participant rights to access their EHR data via APIs, and how your registry can leverage this.
▶ View slides ⇩ Slides (.pptx) ⇩ Full course (PDF)

The 21st Century Cures Act

The 21st Century Cures Act (passed 2016, final rules 2020 to 2021) transformed participant data access. Its key provisions for registries:

Information Blocking Prohibition

EHR vendors and health systems are prohibited from blocking patient access to their electronic health information. This means:

  • Participants have the right to access their complete EHR data in electronic form
  • Health systems cannot charge unreasonable fees for this access
  • EHR vendors must provide standardized API access

Mandatory FHIR APIs

All EHR vendors certified under ONC's 2015 Edition must now implement FHIR R4 APIs allowing patient access via SMART on FHIR. This means that as of 2022, essentially every major EHR system, Epic, Cerner/Oracle, Meditech, Athenahealth, must support patient-directed FHIR data access.

This is transformative for patient registries. Participants can now legally direct their EHR data to any app or registry they choose, with their treating institution required to comply.

OAuth 2.0 and Patient Authorization

How it works

OAuth 2.0 is the authorization protocol that makes patient-directed data access secure. When a participant authorizes your registry to access their EHR:

  1. Authorization Request: Your registry redirects the participant to their EHR's authorization server
  2. Participant Authentication: The participant logs in to their patient portal (e.g., MyChart)
  3. Consent: The participant reviews and approves the specific data types your registry is requesting
  4. Authorization Code: The EHR returns a short-lived authorization code to your registry
  5. Token Exchange: Your registry exchanges the code for an access token
  6. Data Access: Your registry uses the access token to call FHIR APIs and retrieve the participant's data

The participant can revoke this authorization at any time.

Scopes, What you can request

SMART on FHIR uses OAuth 2.0 scopes to define what data an app can access:

patient/Condition.read         - Patient's diagnoses
patient/Observation.read       - Lab results, vital signs
patient/MedicationRequest.read - Prescriptions
patient/Procedure.read         - Procedures
patient/DocumentReference.read - Clinical notes, C-CDA documents

Request only what you need. Requesting broad scopes reduces participant trust and authorization rates.

Direct from Participant: The Registry Opportunity

The Cures Act creates a direct path from participant to registry that bypasses institutional barriers:

  1. Participant enrolls in your registry
  2. Participant clicks "Connect my health records"
  3. Participant logs in to their EHR portal and authorizes specific data sharing
  4. Registry receives structured FHIR data directly, diagnoses, labs, medications
  5. Data updates automatically as new information appears in the EHR

No health system agreement required. No IRB coverage of the health system. The participant is exercising their own data rights.

Important caveat. While no health system agreement is needed for patient-directed access, your registry still needs IRB approval covering the collection and use of EHR data obtained through patient authorization.

Health Apps and the Patient Portal Ecosystem

Major patient portal apps now support patient-directed FHIR access:

  • Apple Health Records, iOS users can aggregate records from thousands of institutions; data can be exported in FHIR format
  • CommonHealth (Android), a nonprofit, Apple-Health-style aggregator from The Commons Project. Its consumer app has effectively wound down, so treat it as historical rather than a current integration target; verify any specific aggregator is still operating before relying on it.
  • Particle Health, Aggregates participant records from 270M+ participant records nationally via CareQuality and CommonWell networks

Some registries integrate with these aggregators rather than building direct EHR connections, significantly reducing development complexity.

Practical implementation

Using Bulk FHIR for site level data

For clinical sites that agree to participate in your registry as data contributors, FHIR Bulk Data allows the site to export FHIR data for all consented participants at once, rather than participant-by-participant.

This requires:

  • Site participation agreement
  • BAA with the health system
  • IRB approval covering the health system

Testing your FHIR implementation

Before going live, test against public FHIR sandboxes:

Key resources

← Module 9 | Module 11: Designing Questionnaires →

Network exchange: TEFCA and Individual Access Services (IAS)

Aligned with EpilepsyLive. Beyond a single participant-portal login, records can be matched across many providers at once through national networks.
  • ASTP/ONC. The federal health-IT office formerly called ONC was renamed ASTP/ONC (Assistant Secretary for Technology Policy / Office of the National Coordinator) in July 2024. It administers the frameworks below, so recent materials use the new name.
  • TEFCA, the Trusted Exchange Framework and Common Agreement sets a nationwide floor for health-data exchange. It runs through Qualified Health Information Networks (QHINs) that connect participating providers.
  • Individual Access Services (IAS), the TEFCA pathway that lets a person use an app or service of their choice to request their own records across participating providers, after identity verification. Reach is broad in theory and grows as the networks mature.
  • In practice, portal login (SMART on FHIR), C-CDA download, HIPAA authorization, and TEFCA/IAS usually run through a vendor or platform rather than being wired directly into a registry.

EEG & imaging studies

Especially relevant for epilepsy. The actual EEG recordings (e.g., EDF) and imaging studies (DICOM) are large binary files that generally do not travel through C-CDA documents or the standard FHIR document flows. Report text may appear, but the studies themselves usually have to be requested separately, from the neurology or radiology department, or via an image-exchange service, often under a HIPAA authorization. Plan for these as their own acquisition pathway.

See the Registry Toolkit health records demo, which walks through all five pathways, and the Guide glossary for the underlying terms.
RelatedRegistry Toolkit: health records demo·EHR integration, C-CDA & FHIR
Something look wrong or unclear? Suggest a correction or send a note. EpilepsyLive is a demonstration project by Danielle Boyce, boycedatascience.com.