FHIR or Custom APIs? What Actually Works for Sharing Clinical Data

Ask any clinician why swapping patient records still feels like pulling teeth, and you'll get a shrug. "Every system speaks its own language." We've all wrestled with a discharge summary that refused to transfer, or an app that needed a custom bridge to the EHR. The real question: do we keep building those rickety bridges, or do we finally agree on a common tongue like FHIR?

Why I stopped defending custom APIs

I used to think custom APIs were the pragmatic choice. Need a special endpoint for your research study? Build it. Want to tweak data fields for a niche clinic? Go ahead. But after a decade in this space, I've watched too many projects rot. Vendor updates break our code. Partners with different EHRs hit a wall. And suddenly, we're debugging interfaces at 2 a.m. instead of sleeping.

Standards feel slower upfront. But they're built to evolve. FHIR R5, out in March 2023, boasts 157 resources—covering everything from allergies to genomics. The U.S. Core Data for Interoperability (USCDI) has grown from 52 to 94 elements in just a few years. These aren't static specs; they bend as needs change. That's not rigidity—it's resilience.

What the numbers tell us

Let's look at adoption. In 2011, only 28% of hospitals and 34% of physicians had EHRs. By 2021, those figures hit 96% and 80%, respectively. That leap didn't happen by magic. The federal government tied incentives to certified tech through Meaningful Use. But having an EHR is one thing; using it to share data is another. That's where standards shine.

Consider the CMS Patient Access API. When the feds mandated that payers open up patient data, they chose FHIR R4—not some bespoke format. Why? Because a common language is the only way to make interoperability real. And it's working. The ONC's HTI-1 rule, effective March 2024, even demands transparency for AI algorithms in certified health IT. Try that with a custom API that no one else can see.

The security angle we can't ignore

Custom interfaces often cut corners on security. HIPAA's Security Rule requires safeguards like access controls and audit trails. NIST's SP 800-66 Rev. 2 gives us a roadmap. Standards like FHIR aren't just about data formats—they establish predictable behaviors we can lock down.

Take information blocking rules under the Cures Act. They force data sharing, but they also demand patient privacy. Standardized APIs and common terminologies like LOINC and SNOMED CT make data both useful and safe. And if a breach happens—say, a stolen laptop with ePHI—the Breach Notification Rule gives you 60 days to notify patients. A standardized approach makes tracking data easier, which lowers breach risk in the first place.

A real-world headache

Picture a small clinic prepping for MIPS in 2026. The performance threshold is 75 points, and the Promoting Interoperability category is worth 25% of that. If you're using custom APIs that don't align with national standards, good luck meeting the data exchange measures. But with FHIR-based tools, you can connect to registries effortlessly—earning points and, more importantly, improving care.

I remember a client, a three-physician practice, stuck with a legacy interface. They spent months and thousands of dollars just to exchange lab results with one hospital. When they finally switched to a FHIR-based portal, it took two days. Two days. That's the difference standards make.

Where to go from here

Let's be honest: moving to standards isn't a walk in the park. It takes money, training, and a shift in mindset. But the alternative—endless one-off integrations—is a dead end. We need to push vendors to support FHIR and USCDI out of the box. The infrastructure is already here. TEFCA has set up a nationwide network, with the first Qualified Health Information Networks named in December 2023. Information blocking rules make data hoarding illegal. What's missing is our resolve.

So here's my plea: Next time you're tempted to build a custom API, stop. Ask if a standard would do. Your future self—and your patients—will thank you.

Sources

• ONC / HHS (Report to Congress) - https://healthit.gov/news/onc-outlines-health-it-interoperability-progress-report-congress/
• HL7 FHIR (Version History) - https://www.hl7.org/fhir/history.html
• Federal Register (CMS Interoperability and Patient Access Final Rule) - https://www.federalregister.gov/documents/2020/05/01/2020-05050/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-and
• ONC Standards Bulletin 2022-2 (USCDI v3) - https://healthit.gov/standards-onc-technology/onc-standards-bulletin/onc-standards-bulletin-2022-2/
• ONC / HHS (TEFCA) - https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca
• Federal Register (CY 2026 Physician Fee Schedule) - https://www.federalregister.gov/documents/2025/11/05/2025-19787