Patient Access Records Retrieval at Scale in CMS 9115

The following is based on a talk given by Flexpa Co-founder and CTO Joshua Kelly at the FHIR DevDays 2024 in Minneapolis in January 2024: Syncing Resources Between Distributed FHIR Servers a talk on Flexpa's experience building patient record retrieval at scale in the CMS 9115 network.

If you're starting on this problem today, Flexpa provides a real-world conformance service. See more at E2E Interoperability Testing with Flexpa for CMS-9115 and CMS-0057

The Core Problem

The challenge seems deceptively simple: build an agent that can connect to any patient access API on a FHIR server and discover all available resources for a patient. However, when you're dealing with hundreds of different implementations, the complexity quickly compounds.

To keep this discussion focused, we'll set aside several related challenges:

• Keeping resources up to date (this is about one-time sync)
• Copying all possible resources (we're focusing on patient-relevant data)
• Provenance tracking

Instead, we'll concentrate on three core issues:

1. Finding patient resources
2. Extracting and tagging these resources
3. Storing and loading the data

Let's dive into the nine specific challenges we encountered.

Challenge 1: The Patient $everything Operation Isn't Everything

The FHIR specification provides what seems like the perfect solution: the patient $everything operation. One request should return all patient data. Unfortunately, we discovered in our latest State of the Patient Access API Report that fewer than a third of payers actually support this operation - it wasn't considered in the IG development for payer patient access APIs in the US.

Even when supported, we encountered several issues:

• Performance: Counter-intuitively, the operation can be slower than making individual requests
• Pagination limitations: Some implementations have upper limits on returned resources and don't implement pagination
• Compartmentalization problems: The operation misses non-patient-compartmentalized resources that are referenced by patient data

Challenge 2: Batch Transaction Limitations

FHIR allows batch transactions with read and search operations, which seems like another elegant solution. However, this feature is rarely supported by patient access APIs. It's another example of a theoretically perfect solution that proves impractical in the real world.

Challenge 3: Capability Statement Unreliability

When falling back to individual search operations, we discovered that capability statements aren't always trustworthy. They can:

• Under-advertise supported resources
• Under-advertise supported operations
• Fail to fully disclose search parameters
• Lack information about maximum count limits for search results

Challenge 4: Non-Standard Implementation Requirements

Connecting to hundreds of FHIR servers reveals a world of non-spec requirements. Some implementations need extra headers or have unique connectivity requirements that aren't part of the standard specification.

Challenge 5: Reference Resolution Race Conditions

When processing returned resources, you need to resolve references (like an encounter referencing an organization). This creates several challenges:

• Rate limits on API calls
• Recursion depth management
• Potential race conditions and duplicate effort when resolving references
• Limited support for _include parameters

Challenge 6: Rate Limiting Complexities

Rate limiting presents its own set of challenges:

• HTTP 429 responses rarely come back as FHIR operation outcomes
• Need for connection pooling
• Balancing speed - too slow can lead to authorization expiration

Challenge 7: Resource Identifier Management

FHIR's use of strings as logical identifiers creates unique challenges when aggregating data from multiple sources:

• No guarantee of uniqueness across different endpoints
• Need for identifier rewriting (UUID V5 can help)
• Requirement to update all references after identifier changes

Challenge 8: Resource Validation Challenges

When dealing with hundreds of FHIR servers, perfect validation becomes impractical. Following Postel's Law becomes essential: be liberal in what you accept and conservative in what you send. Sometimes you'll need to rewrite data to meet specific profile requirements.

Challenge 9: Bulk Resource Storage

The final challenge comes with storing potentially tens of thousands of resources for patients with long health histories. Our recommendations:

• Use batch transactions with update-as-create operations
• Be prepared for performance challenges with large writes
• Consider bulk data import capabilities (though these are still in draft state)

Lessons Learned

Building a system to sync FHIR resources at scale has taught us several key lessons:

1. Layer your solutions: Always implement fallback options when primary approaches aren't supported.
2. Conformance testing is crucial: National-scale implementation guides need robust conformance testing to reduce variance.
3. UUID standardization would help: While it's too late to change, using UUIDs for logical identifiers in FHIR would have simplified many challenges. Maybe a subject for an implementation guide?

The variance in FHIR implementations across different organizations creates a complex landscape for developers. Success requires a pragmatic approach that combines theoretical best practices with practical fallback solutions.

At Flexpa, we've navigated these challenges to build a robust network connecting hundreds of payer APIs. As the healthcare API ecosystem around patient access continues to evolve, we hope sharing these experiences helps others building similar systems.

At JPM this year? Join us in person in San Francisco on January 15, 2025 for Medplum & Flexpa: Devtools for research, commercialization and more in life sciences. We'll show you how to build specialized healthcare applications in life sciences. Register for an invite and let us know that you want to come to this engineering focused event.