Bulk FHIR Implementation Recommendations

Best practices for implementing Bulk FHIR to ensure compliance with interoperability standards.

Items are required by ONC certification criteria / the FHIR R4 US IG and must be implemented to maintain ONC compliance.

Indicates vendors who have implemented the recommendation well.

Indicates vendors who currently have implementation issues in this area.

Setup

Most Important

Basic requirements for Bulk FHIR implementation setup

1. Public link to FHIR documentation including Bulk FHIR integration

Self-service documentation for developers is invaluable for EHR vendors, as it offloads the most commonly asked, basic questions from your support staff.

Examples:

eCW, Athena, Elation, PracticeFusion, ModMed

Examples:

DrChrono

2. Support exporting all patients

This is commonly accomplished either through a group representing the entire practice, or through the all patient export API

Examples:

Athena (global group), PracticeFusion (all patient export), ModMed (all patient export)

Examples:

eClinicalWorks (static group only, must be continuously updated)

3. Public documentation on creating FHIR Groups in the EHR

Providing developers documentation to guide provider customers is valuable so that support staff are not continually asked about this process. If there is a global group for each practice that can be used for export, that group should be easily accessible or in a consistent, documented format.

Examples:

Athena, eCW

Examples:

DrChrono

4. Public documentation on FHIR app installation process

Providers may be unaware of how to install third party FHIR applications. Robust documentation allows developers to guide them in this process, offloading rote work from EHR support staff.

Examples:

eClinicalWorks, Athena (documentation is public, but buried in a release note and not in their API documentation)

Examples:

DrChrono, Elation, ModMed

5. Support self service installation

All health systems or practices should be able to install app without the special effort, friction, and dependency of contacting support.

Examples:

Athena, eClinicalWorks

Examples:

DrChrono, Elation, ModMed

6. All patients should be available for bulk as soon as the app is installed and not require a backfill process

Examples:

Athena, eClinicalWorks, ModMed, Elation

Examples:

DrChrono, PracticeFusion

Authentication

Requirements for authentication in Bulk FHIR implementations

1. Support JWKS authentication for system clients

Examples:

Athena, eClinicalWorks (has an undocumented requirement to "allowlist" a given application's JWKS URL before it can successfully authenticate)

Examples:

Elation

2. Allow a single system client to be registered to multiple practices (rather than requiring a separate app registration per practice)

Examples:

Athena, eClinicalWorks

Examples:

Elation, ModMed

Functionality & Performance

Requirements for functionality and performance in Bulk FHIR implementations

1. Bulk export should complete successfully in all cases, regardless of size

Examples:

Athena

Examples:

eClinicalWorks

2. Bulk export should complete in under 72 hours, regardless of size

Examples:

Athena, ModMed, PracticeFusion

Examples:

eClinicalWorks

3. Provide percentage based progress status using the X-Progress header

Examples:

Athena, eClinicalWorks

Examples:

ModMed

Data

Requirements for data quality in Bulk FHIR implementations

1. Clinical notes should be made available as individual DocumentReferences for each visit (not grouped together into a single CCDA XML file)

Examples:

Athena, ModMed

Examples:

eClincalWorks, DrChrono

2. DocumentReference attachments should be accessible to bulk clients

This can be via a presigned, publicly accessible storage link (e.g S3 URL), an embedded base64 encoded file, or a reference to a Binary resource. In the case of a Binary resource, this must be accessible to the bulk client via the FHIR API.

Examples:

Athena, ModMed

Examples:

DrChrono, eClinicalWorks (supports fetching Binary resources by exporting them as part of the bulk export, but this isn't typical and can make bulk exports take much longer), Elation

3. Bulk export files should contain at least 100 (ideally 1000) records per file

Rationale: a low number of records per export file can mean an unreasonably large export manifest size and place burden on the Bulk client to have to fetch tens of thousands of export files.

Examples:

Athena, ModMed

Examples:

eClinicalWorks

Vendor Implementation Scorecard

Based on our assessment of various EHR vendors' implementations of Bulk FHIR, we've compiled this scorecard to help healthcare organizations understand which vendors are most compliant with interoperability standards.

Vendor	Setup	Authentication	Performance	Data Quality
Athena	Excellent	Excellent	Excellent	Excellent
DrChrono	Poor	Good	Good	Poor
eClinicalWorks	Good	Excellent	Poor	Good
Elation	Good	Poor	Good	Poor
ModMed	Good	Poor	Good	Excellent
PracticeFusion	Good	Good	Excellent	Good

Next Steps for EHR Vendors

If you're an EHR vendor looking to improve your implementation of Bulk FHIR or other interoperability standards, here are some recommended next steps:

Review Documentation

Ensure your FHIR API documentation is publicly available and comprehensive
Document your app installation process clearly
Provide detailed guidance on authentication methods
Include examples and sample code for common operations

FHIR Bulk Data Access Implementation Guide

Address Compliance Issues

Prioritize fixing issues with ONC-required functionality (items marked with )
Implement proper DocumentReference handling for clinical notes
Ensure all patients are available for bulk export without backfill
Optimize performance for large exports

Report Implementation Issues