Musings on healthcare IT, FHIR, EHR systems, and digital health innovation

🔥 FHIR in the hole!
Back to posts

Slow Bulk APIs: A Quality & Safety Bottleneck

View on LinkedIn

Shared link

Slow Bulk APIs: A Quality & Safety Bottleneck

Welcome back to Fun with the CMS/ASTP/ONC RFI!

Today’s Policy: Ensure Foundational Design and Performance for Bulk Data API Full Rec: https://lnkd.in/gQRnnBdW Voice: The QI Officer (Data-Driven, Patient-Focused)


In Quality Improvement, timely, comprehensive patient data is everything. It’s how we identify cohorts for quality measures, track outcomes, monitor care pathways, and report performance. The FHIR Bulk Data API promises standardized access to this vital clinical data.

But what happens when that certified Bulk FHIR API is painfully slow, flaky, or far outperformed by a vendor’s proprietary export tool? It cripples our work. We might spend days trying to extract data for a critical quality measure via the standard API, only for the process to time out or be so unreliable that we can’t depend on it for regular reporting. This forces us to invest in developing and maintaining custom code that only works with one specific vendor’s system, instead of leveraging open-source tools, standardized libraries, and the worldwide expertise available for FHIR. Our QI cycles slow down. Our ability to rapidly respond to safety issues is hampered. Demonstrating improvement becomes a constant battle with inefficient, non-standard data extraction.

This recommendation, “Ensure Foundational Design and Performance for Bulk Data API,” is crucial for effective QI.

For us, it means:

  1. Timely Data for Action (Performance Parity): If the FHIR Bulk Data API must perform as well as proprietary exports, we can get data for our quality dashboards and analyses promptly and reliably. No more waiting a week, or battling timeouts, for data that should take hours. This allows near real-time monitoring and quicker adjustments to our initiatives.
  2. Reliable Access to Comprehensive Data at Scale (Designed for Population Scale): Requiring the API to be architected for population-scale operations means we can trust it for large queries – our entire patient population or specific large cohorts – without system failure. This is vital for robust quality reporting and identifying system-level care trends.

Essentially, this recommendation would make the standardized FHIR Bulk Data API a truly functional tool for quality improvement, not just a theoretical capability. It would empower us to be more proactive and data-driven in our mission to improve patient care and safety. We could spend our limited resources analyzing data and implementing changes, not developing one-off solutions for slow or unreliable standard APIs.


“How would faster, reliable bulk data access via standard APIs change your work?