§170.315(g)(10)(viii) · §170.404(a)(1)

Application Registration

All technical requirements and attributes necessary to register an application with the Retinex authorization server.

Version 1.0 Updated 2026-06-03 Publicly accessible · No charge
No fee & no special effort. Registering an application, obtaining client credentials, and accessing the sandbox and this documentation are provided at no charge. Registration is not conditioned on a competitive relationship, a fee, or any of the prohibited terms at §170.404(a)(4)(ii)(B). See API Terms & Conditions.

1. Client Types

TypeExampleAuthentication
PublicNative mobile app, single-page appNo secret; Authorization Code + PKCE (S256)
Confidential — symmetricServer-side web appclient_secret_basic + PKCE
Confidential — asymmetricBackend service (SMART Backend Services)private_key_jwt with a registered public key

2. Required Technical Attributes

The following attributes are collected at registration (per §170.315(g)(10)(viii)). Required attributes depend on client type.

AttributeRequired forNotes
client_nameAllHuman-readable application name shown on the consent screen.
redirect_urisAuthorization Code clientsOne or more exact-match callback URIs. HTTPS, or an app-claimed private-use URI scheme for native apps.
grant_typesAllauthorization_code, refresh_token, and/or client_credentials.
response_typesAuthorization Code clientscode.
token_endpoint_auth_methodAllnone (public), client_secret_basic, or private_key_jwt.
scopeAllSpace-delimited list of requested scopes — see Supported Scopes.
jwks / jwks_uriConfidential asymmetricPublic key(s) used to verify the private_key_jwt client assertion.
contactsRecommendedDeveloper email(s) for security and operational notices.
logo_uri, policy_uri, tos_uriOptionalDisplayed on the patient consent screen.
launch_uriEHR-launch appsEndpoint Retinex invokes for an EHR launch.
software_id, software_versionOptionalStable identifier for the software across instances.

3. Dynamic Client Registration (RFC 7591)

Applications may self-register programmatically at the registration endpoint:

POST https://retinexv2-apim.azure-api.net/auth/register
Content-Type: application/json

{
  "client_name": "Acme Patient App",
  "redirect_uris": ["https://app.acme.example/callback", "com.acme.app:/oauth2redirect"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none",
  "scope": "openid fhirUser offline_access launch/patient patient/Patient.rs patient/Observation.rs",
  "contacts": ["dev@acme.example"]
}

Successful registration returns the assigned credentials:

{
  "client_id": "c_9f3a2b7c1d8e",
  "client_id_issued_at": 1780000000,
  "token_endpoint_auth_method": "none",
  "redirect_uris": ["https://app.acme.example/callback", "com.acme.app:/oauth2redirect"],
  "grant_types": ["authorization_code", "refresh_token"],
  "scope": "openid fhirUser offline_access launch/patient patient/Patient.rs patient/Observation.rs"
}

Confidential clients additionally receive a client_secret (symmetric) or register a jwks_uri (asymmetric).

4. Native (Mobile) Application Registration

Native apps register as public clients (token_endpoint_auth_method: none). Because a secret cannot be protected inside a distributed binary, security rests on PKCE and app-claimed redirect URIs:

  • Register a private-use URI scheme redirect (e.g. com.acme.app:/oauth2redirect) and/or an HTTPS claimed redirect (Android App Links / iOS Universal Links).
  • Use Authorization Code + PKCE S256 and request offline_access for a refresh token.
  • Store issued tokens in iOS Keychain / Android Keystore.

The full method for secure refresh-token issuance to native apps is documented under SMART Authorization → Native Applications.

5. Sandbox & Manual Registration

A free sandbox with synthetic patient data is available for development and testing. To request sandbox access or to register a production application manually, contact support@retinex.ai. There is no fee for access to the sandbox, test data, or registration.

6. Verification of API Users

Production registration verifies the developer's identity and contact information and the ownership of claimed redirect URIs/domains. Verification criteria are objective and uniformly applied to all similarly situated API users, consistent with §170.404(a)(3) and the non-discrimination condition at §170.404(a)(4)(i).

7. Change Log

DateVersionChange
2026-06-031.0Initial public application-registration documentation for §170.315(g)(10).