CernerCare App Registration

What is CernerCare app registration?

CernerCare app registration is the process of creating a client application in Oracle Health's code Console using a free CernerCare account. Registration gives the app a client ID for Oracle Health's authorization server, and for confidential or system apps a managed secret, so the app can request SMART on FHIR authorization against Oracle Health FHIR APIs.

The CernerCare account is simply the identity the developer uses to sign in. The registration that matters is the application record created under that account, because every customer that later enables the app is enabling that record.

What do you need before registering?

You need a free CernerCare account, a clear idea of who the app's user is, and the redirect and launch URLs the app will use. Oracle's Authorization Framework documentation states that a free CernerCare account is required to register applications.

• Account owner: Register with a shared team identity or a named owner who will stay with the company, because system account details are tied to the registering account.
• User type: Decide whether a clinician, a patient or no person at all will authorize the app.
• URLs: The SMART launch URL for EHR launch and the redirect URL that receives the authorization code.
• Resource list: The FHIR resources the app reads or writes, checked against Oracle Health's published list of supported resources.
• Gap analysis: For provider and system apps, Oracle asks developers to document a gap analysis against the available FHIR resources.

How do you register an app in code Console?

You register an app by signing in to code Console with the CernerCare account, creating a new application with the intended type and privacy, and completing the registration form. Oracle's documentation describes exactly those two steps, after which a client ID is issued.

• 1. Sign in: Use the CernerCare account at Oracle Health's code Console.
• 2. Create the app: Choose the application type, such as provider, patient or system, and the privacy setting, public or confidential.
• 3. Set launch details: Enter the launch and redirect URLs and the FHIR version.
• 4. Choose scopes: Select the user, patient or system scopes the app needs, and nothing more.
• 5. Register: Save the app and record the client ID shown on the application details page.
• 6. Test: Launch the app against Oracle Health's open sandbox before showing it to any customer.

Keep a record of every setting, including the scope list, in the team's own documentation. When a customer's security reviewer asks what the app can access, the answer should come from that record, not from memory or screenshots.

Which application type should you choose?

Choose the application type by asking who authorizes access. A clinician launching the app inside the EHR is a provider app, a patient connecting their own record is a patient app, and a backend service acting without a person is a system app.

• Provider app: Launched from the clinician's workflow with SMART EHR launch, uses user scopes and reads data for the patient in context.
• Patient app: Used by patients to reach their own data through patient-facing endpoints, with patient scopes and the patient's consent.
• System app: A server process, such as a nightly sync or a Bulk Data export, that authenticates with its own credentials rather than a user's login.
• Public or confidential: A browser or mobile app that cannot keep a secret is public; a server that can protect a secret is confidential.

Many products need more than one registration. A clinician-facing SMART app and a backend sync job are different clients with different scopes, and combining them into one broad registration makes every customer's review harder.

How do system accounts and secrets work?

When an app is registered with the System type or as a Confidential client, Oracle issues a system account automatically. Oracle's documentation says the customer secret for that account is managed through Cerner Central system accounts, reached from the application details page in code Console, where JWKS for bulk applications can also be set up.

The system account is issued to the same CernerCare account that registered the app, and a confirmation email goes to that account's address. Oracle also warns developers to protect the secret, never post or email it insecurely, and rotate the credentials through Cerner Central if it is ever compromised.

• Secret storage: Keep the secret in a managed secrets store, never in source code, build logs or shared documents.
• Key-based auth: Where JWKS is supported, prefer signed assertions with a published key set over a shared secret.
• Rotation plan: Write down who can rotate the secret, how the app picks up the new value and how to test it without downtime.
• Ownership: Make sure the CernerCare account that owns the system account is not tied to one person's employment.

How do consumer apps differ from provider and system apps?

Consumer apps follow a lighter path to production. Oracle Health's developer page says that after a consumer access app is registered, it is provisioned for all active Millennium Platform and Soarian Clinicals FHIR API consumer access endpoints.

For consumer apps, the same page lists accepting Oracle Health's API terms and conditions, reviewing the documentation and consumer app guidance, and registering in the developer console. It strongly recommends, without requiring, sandbox testing and attesting to the CARIN Alliance Code of Conduct.

Provider and system apps are different. Oracle's page lists accepting the API access terms, documenting a gap analysis, registering the app and building a working demo against the open sandbox, after which the app is available for Oracle Health clients to consider. In other words, registration makes the app eligible; each customer still decides whether to turn it on.

What happens when a customer enables the app?

A customer enables the app by authorizing that client ID for its own domain, which Oracle's documentation describes as the step that gives the app access to that customer's protected resources. Until then, the registered app works only in the sandbox.

• Security review: The customer checks the app's scopes, data use, hosting and the vendor's security answers.
• Domain setup: The customer's team enables the client in its non-production domain first, then production.
• Launch configuration: For provider apps, the customer decides where the app appears in the clinician's workflow and who can launch it.
• Testing with real builds: The vendor tests against the customer's configuration, which differs from the sandbox in data, code sets and enabled resources.
• Go-live: Production enablement, monitoring and a named contact on both sides for incidents.

What should a vendor prepare for the customer review?

A vendor should prepare a short, accurate package that answers the customer's security, privacy and clinical questions before they are asked. Reviews stall most often while a health system waits for basic facts about the app.

• Data inventory: Every FHIR resource and scope the app uses, why it needs each one, and whether it reads, writes or both.
• Data handling: Where data is stored, for how long, how it is encrypted and who at the vendor can see it.
• Architecture sketch: The app, its backend, the Oracle Health authorization server and the FHIR endpoints, with the direction of each call.
• Credentials: How secrets or private keys are stored and rotated, and who holds the CernerCare account that owns them.
• Clinical workflow: Where in the clinician's day the app launches and what it shows, with screenshots from the sandbox.
• Support model: Named contacts, hours, incident process and how the customer will be told about outages.

Write the package once and keep it current with each release. A new scope or a new data store changes the answers, and customers that approved an earlier version will expect to hear about it before the change reaches their production domain.

Business terms move in parallel. A business associate agreement, the commercial contract and any data use limits usually need signatures before production enablement, so start them during technical testing rather than after it.

Where do Oracle Health app registrations go wrong?

• Wrong app type: A server process is registered as a provider app, and the team later discovers it needs a system registration.
• Scope creep: Broad scopes chosen for convenience in the sandbox slow every customer's security review.
• Orphaned account: The engineer who registered the app leaves, and nobody can manage the system account or its secret.
• Sandbox confidence: An app that works with sandbox data fails with a customer's local codes and missing resources.
• Secret in code: A confidential client's secret is committed to a repository and has to be rotated in a hurry.
• Assumed enablement: Sales commits a go-live date before the customer's review and domain setup are scheduled.

Nearly all of these are planning problems rather than coding problems. A one-page registration plan, listing each client, its type, scopes, owner and secret handling, prevents most of them and gives customers a clear picture from the first call.

How Agnotic can help

Agnotic Technologies builds Oracle Health and Epic integrations for digital health vendors. We plan the registrations an app needs, configure SMART launch and scopes, set up confidential clients with secrets or key sets held in managed stores, and prepare the documentation customers ask for during review.

Agnotic then works through each customer's enablement with the vendor: testing against the customer's non-production domain, fixing data and code differences from the sandbox, and supporting the production go-live.

Sources

• Oracle Health Millennium Platform APIs: Authorization Framework
• Oracle Health: API access and fees and registering an app