Healthcare data exchange is undergoing a paradigm shift that most people in the industry haven't fully grasped yet.

For decades, we've operated under one model: providers exchange data on behalf of patients. A doctor needs records from another hospital, so staff members navigate fax machines, portals, and release forms to obtain them. The patient is a passive participant whose signature authorizes others to act.

That model made sense in a paper-based world. It doesn't make sense anymore.

The Old Paradigm: Provider-Centric Exchange

Here's how traditional health information exchange works:

1. Patient visits a new doctor

2. Doctor's staff asks patient to sign a release form

3. Staff contacts the previous provider to request records

4. Previous provider (eventually) sends records via fax, portal, or mail

5. Records arrive days or weeks later

The patient's role in this process is signing a piece of paper. Everything else happens between institutions, often slowly and inefficiently.

This model has driven the growth of Health Information Exchanges (HIEs), networks like Carequality, and tools built on provider-to-provider access patterns. They solve a real problem, but they solve it from the provider's perspective; not the patient's.

The New Paradigm: Patient-Directed Access

The 21st Century Cures Act enabled a fundamentally different approach: patient-directed data access.

Under this model:

1. Patient authorizes an application to access their records

2. Application connects directly to the EHR via standardized API

3. Patient receives their data in real-time

4. Patient decides who to share it with, when, and for what purpose

The shift seems subtle, but the implications are profound.

When a doctor needs a patient's records, they shouldn't be calling another hospital. They should be asking the patient and that ask should be digital, instantaneous, and seamless. The patient authorizes sharing with a tap, and data flows in seconds rather than weeks.

Why the Distinction Matters

Patient-directed and provider-access approaches differ in ways that affect product design, compliance, and user experience.

Consent Granularity

Provider-access models typically operate on broad consent:

"I authorize Hospital A to obtain my records from Hospital B."

The patient has no control over which specific records are shared or how long the authorization lasts.

Patient-directed access enables granular consent. A patient might authorize sharing their medication list and lab results, but not their psychiatric history or reproductive health records. They might grant access for 30 days rather than indefinitely. They remain in control.

This granularity isn't just a nice feature, it builds trust. Many patients hesitate to share health data because they can't control what gets shared. When you give them that control, they're more willing to participate.

Data Freshness

Provider-access often returns point-in-time snapshots: a discharge summary, a continuity of care document, a PDF from last year's visit. The data is historical by design.

Patient-directed APIs connect to live EHR systems. When a patient authorizes your application, you get their current medication list, their most recent lab results, their up-to-date problem list. The data is as fresh as the EHR itself.

The Technical Reality: Documents vs. Discrete Data

The distinction between provider-access and patient-directed approaches often comes down to data format, and the format has major implications for usability.

Document-Based Exchange (CCD/C-CDA)

Traditional health information exchange typically returns Continuity of Care Documents (CCDs); XML-based clinical summaries designed for provider-to-provider handoffs.

A CCD is like receiving a PDF of someone's medical history. It contains valuable information: problems, medications, allergies, recent encounters. But the data is embedded in a document structure designed for human reading, not programmatic use.

For developers, this means:

• Parsing complex XML structures to extract discrete data elements

• Handling inconsistent formatting across different document sources

• Limited ability to query for specific data types

• Historical snapshots rather than real-time information

CCDs serve their purpose for care transitions between providers. But they're not optimized for modern health applications that need structured, queryable data.

FHIR-Based Patient Access APIs

Patient-directed access through ONC g(10) APIs returns FHIR resources; individual JSON objects representing discrete clinical concepts.

Instead of one large document, you receive separate resources for:

• Patient demographics

• Each condition on the problem list

• Each medication

• Each allergy

• Each lab result with values and reference ranges

• Immunization records

Each resource is self-contained, structured, and immediately usable. You can query for specific resource types, filter by date ranges, and build applications that display exactly the data users need.

The Practical Difference

Consider building a medication management app. With document-based exchange, you'd receive a CCD, parse the XML to find the medications section, extract medication names and dosages from narrative text, and hope the format is consistent across sources.

With FHIR-based patient access, you query the MedicationRequest endpoint and receive structured JSON with discrete fields for medication name, dosage, frequency, prescriber, and status. The data is ready to use.

The same pattern applies across clinical domains. FHIR resources give developers building blocks; documents give them puzzles to solve.

The Regulatory Direction Is Clear

The HTI-5 proposed rule released in December 2025 explicitly advances patient-directed access as the future of interoperability. It updates information blocking definitions to ensure patients can retrieve and share their data, proposes removing legacy document-exchange requirements in favor of FHIR APIs, and signals intent to support AI applications that need programmatic patient data access.

The writing is on the wall, and frankly, it mirrors broader trends we've seen in other industries. GDPR in Europe established that individuals have the right to access and port their personal data. Financial services has Open Banking. Healthcare is following the same trajectory.

If it becomes easy to obtain patient consent digitally - and the technology now exists to make it easy - why wouldn't regulators mandate that process?

What This Means for Healthcare Builders

If you're building healthcare applications, you have a choice: design around provider-access patterns, or design around patient-directed access.

Provider-access means integrating with HIEs, navigating complex participant agreements, and working with data formats optimized for clinical workflows rather than modern applications.

Patient-directed access means simpler compliance (the patient authorized you directly), fresher data (real-time API access), more granular consent (patients control what they share), and structured data (FHIR resources rather than documents to parse).

At Consolidate Health, we built our infrastructure around patient-directed access from day one. Our API enables patients to retrieve their records from major EHR systems and share them with applications they choose. We handle the EHR integration complexity; you build the features your users need.

The paradigm is shifting. The question is which side of that shift your product will be on.