Every third-party application that connects to your FHIR APIs needs to be registered. An OAuth client has to be created, scopes need to be assigned, credentials need to be issued, and the registration needs to be recorded. That's true whether you do it manually or automate it with Dynamic Client Registration (DCR).

The difference is cost. Not just the licensing cost of tooling, but the engineering time, the operational overhead, the compliance risk, and the opportunity cost of partners waiting in a queue instead of building.

But here's what the manual-vs-DCR framing misses: neither one is the full answer. Manual registration is too slow. Raw DCR is too fast, trading speed for governance in an environment where regulators expect you to demonstrate control over who has access to patient data and why. The real question isn't manual or automated. It's how you get the speed of automation with the oversight compliance requires.

This article puts real numbers on the comparison, and then addresses what both approaches leave unsolved.

What Manual Registration Actually Involves

Manual SMART app registration is the default for most healthcare organizations starting their FHIR API programs. Here's what the process typically looks like:

Third-party developer submits a registration request (email, form, or portal)
Someone on your team reviews the request and verifies the application's identity
An administrator creates the OAuth client in your authorization server
Scopes are configured based on the application's stated purpose
Credentials (client ID and secret) are generated and sent to the developer
The registration is recorded in your system of record (spreadsheet, ticket, or portal)
If production access requires approval, the request enters a review queue

Each step involves a person. Each handoff introduces a delay. And the whole process resets for every new application.

The Cost Comparison

Here's what manual registration costs versus DCR across five dimensions, modeled for an organization managing 50 third-party applications per year.

Cost dimension	Manual registration	Dynamic Client Registration
Time per registration	2-4 hours elapsed (30-60 min hands-on, rest is wait time between handoffs)	Seconds (automated API call)
Annual staff time (50 apps)	100-200 hours of admin/engineering time	10-20 hours (policy configuration and monitoring)
Time to first API call	Days to weeks (depends on queue and availability)	Minutes (credentials returned immediately)
Error rate	Misconfigured scopes, wrong credentials sent, registrations missed in records	Consistent: same validation rules applied every time
Audit readiness	Records scattered across email, tickets, spreadsheets. Compiling audit report takes days.	System of record is the authorization server itself. Audit report is a query.

The Hidden Costs of Manual Registration

The table above covers the obvious costs. The hidden costs are bigger.

Partner attrition

Every day a developer waits for credentials is a day they're not building. Some developers wait. Many don't. They move to another platform, deprioritize the integration, or lose their internal champion's attention. You'll never see this cost in a report because the partner never sends an email saying "we left because registration took too long." They just stop responding.

In open banking, institutions that moved to automated registration saw measurable increases in partner conversion from "registered" to "first API call." The pattern was consistent: remove the wait and more partners complete the journey.

Scope drift

When scopes are configured manually, they drift. The engineer handling the registration grants broad scopes because it's faster. "We'll tighten it later." Later never comes. After a year of manual registrations, you have 50 applications with scopes that don't match their actual use, and no record of why those scopes were granted.

With DCR, scope assignment follows encoded policies. The application requests scopes, the server validates them against your rules, and only approved scopes are granted. The policy is the same at 9 AM on Monday and 4 PM on Friday. There's no drift because there's no human judgment call at the point of assignment.

Compliance remediation

When an auditor asks for your registration records and finds gaps (missing approvals, inconsistent scope grants, orphaned credentials), the remediation cost is significantly higher than the cost of doing it right from the start. Remediation means stopping other work, reconstructing records, reviewing every active application, revoking access that should have been revoked, and implementing the governance process you should have had.

Organizations that went through open banking audits report that scope governance remediation was one of the most expensive post-audit activities, not because the fix was technically complex, but because it required reviewing every existing registration by hand.

Engineering opportunity cost

The 100-200 hours per year spent on manual registration isn't free time. It's engineering time that could be spent on the FHIR APIs themselves, on data quality, on performance, or on features that make the API program more valuable. Manual registration is a tax on your most expensive resource.

When Manual Registration Still Makes Sense

DCR isn't always the right answer. Manual registration is appropriate when:

You have fewer than ten applications. The overhead of implementing DCR exceeds the time saved when the volume is low.
Every registration requires deep review. If your policy requires a human to evaluate every application before granting any access (not just production access), manual review is the process, and DCR adds automation around it rather than replacing it.
Your authorization server doesn't support DCR. Not all OAuth providers have DCR built in. If yours doesn't, the cost of building or integrating DCR support needs to be weighed against the manual registration cost.

But even in these cases, the manual process should be structured. Capture the same metadata DCR would capture. Record approvals in a system of record, not email. Apply scope policies consistently. The governance matters regardless of whether registration is automated.

What Neither Approach Solves Alone

The manual-vs-DCR comparison covers registration. Registration is day one. Compliance covers every day after that.

Neither manual registration nor raw DCR answers the questions auditors actually ask: Who approved this application's scope grant, and when? Has anyone reviewed whether these scopes are still appropriate? Which applications are dormant? Which credentials should have been revoked? When was the last access review conducted?

Those questions require a governance layer that sits above the registration mechanism. It doesn't matter whether the OAuth client was created by a person or by a DCR endpoint. What matters is that someone (or something) is managing the lifecycle: approvals, reviews, monitoring, and revocation. DCR solves the speed problem. Governance solves the compliance problem. You need both.

The Hybrid Approach

Most healthcare organizations don't need to choose manual or automated. The practical approach is a hybrid with a governance layer orchestrating both:

Sandbox registration is automated. Applications register for sandbox access through self-service or DCR. No approval required. Credentials are issued immediately. Developers start building the same day.
Production registration requires approval. When an application is ready for production, it submits a request that enters an approval workflow. A human reviews the requested scopes, verifies the application's purpose, and approves or rejects. Credentials are issued automatically upon approval.
Ongoing lifecycle is managed. Active applications are reviewed periodically. Scope grants are validated against current use. Dormant applications are flagged. Revocations are logged. The governance trail exists from registration through deactivation.

This gives you the speed of automation where it matters most (getting developers started), the governance of human review where the risk is highest (production access to patient data), and the ongoing oversight that compliance actually requires. It's the same pattern that open banking converged on after trying both extremes.

Making the Decision

If you're managing SMART app registration today, ask three questions:

How many applications will need access in the next 12 months? If the answer is more than 20, the manual costs in this article are real and growing.
Can you produce an audit-ready registration report in ten minutes? If not, your current process has a compliance gap regardless of whether you automate.
Are partners waiting more than 48 hours for credentials? If yes, you're losing partners to a process problem, not a product problem.

For a full compliance readiness assessment, start there. For the technical details on how DCR works, see what is Dynamic Client Registration.

Apiable is the governance layer. It orchestrates registration (manual or DCR), enforces scope policies, manages approval workflows, and maintains the audit trail across the full application lifecycle. DCR handles the front door. Apiable manages everything that comes after. Book a demo to see how it works for your FHIR API program.

SMART App Registration: Manual vs. DCR — What It Actually Costs