Healthcare APIs Are Following the Open Banking Playbook

In 2018, the UK's Open Banking regulation required banks to give third-party applications access to customer financial data through standardized APIs. Banks had to open their systems, implement OAuth-based authorization, manage third-party application registration, and submit to regulatory oversight of their API programs.

In 2024, CMS-0057-F required healthcare payers to give third-party applications access to patient health data through standardized FHIR APIs. Payers have to open their systems, implement SMART on FHIR authorization, manage third-party application registration, and meet compliance deadlines for API readiness.

The industries are different. The playbook is the same.

If you're building healthcare APIs right now, the open banking experience offers lessons that can save you months of engineering time and compliance headaches. The teams that figured out open banking fastest treated it as an API product problem, not a compliance checkbox.

The Pattern

Both regulations follow the same five-step structure:

1. Regulators mandate data access. Customers (or patients) have a right to their data. Institutions must provide it through APIs, not portals or paper.
2. A standard defines the data format. Open banking uses the Open Banking API specification. Healthcare uses FHIR R4. Both ensure that third-party applications can consume data consistently across institutions.
3. A standard defines authorization. Open banking uses OAuth 2.0 with OpenID Connect and Dynamic Client Registration. Healthcare uses SMART on FHIR (also OAuth 2.0 based) with scope-based access control. Both mandate that applications declare what data they need and that institutions enforce those boundaries.
4. Third-party applications register and get certified. In open banking, fintech apps register with the Open Banking Directory and prove they're authorized to access financial data. In healthcare, third-party apps register with the payer and request FHIR scopes. The registration and approval mechanisms differ, but the principle is the same: you can't access data without proving who you are and what you need.
5. Institutions must prove compliance. Auditors verify that APIs work, that access controls are enforced, that logs are maintained, and that the institution can demonstrate governance over third-party access.

The parallels aren't superficial. They're structural. And the problems healthcare teams are encountering now are the same ones banking teams hit five years ago.

What Open Banking Taught Us

Open banking has been live long enough to know what worked, what didn't, and what surprised everyone.

The API was the easy part

Banks that started with the data layer, building the APIs to serve account and transaction data, found that the APIs themselves were the most straightforward part of the project. The hard parts were everything around the APIs: authorization infrastructure, third-party application management, audit logging, and the operational processes to maintain it all.

Healthcare teams are learning the same lesson. Getting FHIR endpoints to return correctly formatted data is a solvable engineering problem. Managing which applications have access to which data, enforcing scope boundaries, logging every access event, and handling the lifecycle of dozens of third-party applications is the part that takes longer than anyone expects.

Manual registration didn't scale

Early open banking implementations handled third-party application registration manually. A fintech would email the bank, the bank would create an OAuth client, someone would send credentials, and the registration was tracked in a spreadsheet. It worked for the first wave of fintechs. It collapsed when hundreds of applications needed access.

The solution was Dynamic Client Registration (DCR). The UK Open Banking standard adopted DCR as a required mechanism, allowing fintechs to register programmatically through a standardized API endpoint. Registration, credential issuance, and scope assignment happened automatically, following policies the bank defined.

Healthcare hasn't mandated DCR yet. But the trajectory is the same. The early adopters managing five or ten third-party apps manually will hit the same wall when the number grows to fifty. The organizations that implement structured registration now, whether through DCR or a well-governed manual process, will scale without the scramble.

Scope management became the compliance battleground

In open banking, the most common audit findings weren't about the APIs themselves. They were about scope governance: applications with more access than they needed, scope grants without recorded approvals, orphaned credentials from applications that no longer existed, and logs that couldn't demonstrate what data was accessed under which authorization.

Healthcare teams should expect the same. Scope management is where compliance meets daily operations, and daily operations is where shortcuts accumulate. The teams that treated scope governance as a first-class engineering requirement from the start passed audits. The teams that bolted it on after the fact spent months remediating.

The winners treated it as a product opportunity

Here's the lesson that most people miss: the banks that did best with open banking didn't treat it as a compliance burden. They treated it as a product opportunity.

They built developer portals. They created tiered API products. They invested in developer experience. Some monetized third-party access directly. Others used API-driven partnerships to acquire customers through fintech channels they couldn't reach on their own.

The banks that approached open banking as "build the minimum to satisfy the auditor" got exactly that: a minimum viable API that nobody wanted to use, maintained by a team that saw it as overhead.

The same choice is in front of healthcare organizations right now. CMS-0057-F mandates the APIs. But how you build them, how you package them, and how you manage the partner relationships around them is entirely up to you. A compliance-only approach gets you through the audit. A product approach gets you through the audit and creates a foundation for partner-driven growth.

What Healthcare Can Do Differently

Healthcare doesn't have to repeat every mistake open banking made. The playbook is public. Here's how to skip ahead.

Build the management layer alongside the APIs, not after. Don't ship FHIR endpoints and then figure out application registration, scope governance, and audit logging. Build them in parallel. The management layer is what auditors care about most, and it's the hardest to retrofit.

Plan for DCR even if you don't implement it immediately. Design your registration process so it can be automated later. Capture the same metadata you'd need for DCR (application identity, requested scopes, redirect URIs, software statements) even if registration is manual today. When the volume of third-party applications grows, you'll be ready to automate without redesigning.

Invest in scope governance from day one. Define your scope management policies before you grant the first scope. Decide which scopes require approval, who can approve them, how approvals are recorded, and how often they're reviewed. Encoding these decisions upfront is a fraction of the cost of reconstructing them for an auditor after the fact.

Think beyond compliance. The same infrastructure that supports CMS-0057-F compliance, a developer portal, structured onboarding, scope-based access control, usage analytics, can also support a broader API partner program. Healthcare organizations that build for the regulation alone will have to rebuild when they want to expand. Organizations that build for scale from the start won't.

The Convergence

Open banking and healthcare are converging on the same architecture: standardized APIs, scope-based authorization, structured third-party access, and audit-ready governance. The technology patterns are identical. The regulatory drivers are identical. The implementation challenges are identical.

The question for healthcare API teams isn't whether to follow the open banking playbook. It's whether to learn from it proactively or rediscover the same lessons the hard way.

Apiable was built for this pattern. Application registration, scope management, approval workflows, and audit logging for regulated API programs, whether in healthcare, financial services, or any industry where third-party API access needs governance. Book a demo to see how it works.