FHIR R4 · SMART App Launch 2.2

Register your SMART app.
Make the launch.

Ava Ecosystem gives vendors and clinic development teams one place to configure an EHR-launched app, provision a synthetic sandbox registration, and prepare for production security review across Ava EMR's 15-resource FHIR surface.

There are no client secrets to leak—every authorization flow is PKCE-protected.

Request
curl "https://sandbox.avaemr.ca/fhir/r4/{partition_id}/Patient/synthetic-patient-1"   -H "Authorization: Bearer $SMART_ACCESS_TOKEN"   -H "Accept: application/fhir+json"
Response 200 OK
{
  "resourceType": "Patient",
  "id": "synthetic-patient-1",
  "name": [{ "family": "Example", "given": ["Avery"] }],
  "gender": "unknown"
}
Request
curl "https://sandbox.avaemr.ca/fhir/r4/{partition_id}/Practitioner/synthetic-practitioner-1"   -H "Authorization: Bearer $SMART_ACCESS_TOKEN"   -H "Accept: application/fhir+json"
Response 200 OK
{
  "resourceType": "Practitioner",
  "id": "synthetic-practitioner-1",
  "active": true,
  "name": [{ "family": "Clinician", "given": ["Morgan"] }]
}
Request
curl "https://sandbox.avaemr.ca/fhir/r4/{partition_id}/.well-known/smart-configuration"   -H "Accept: application/json"
Response 200 OK
{
  "capabilities": [
    "launch-ehr",
    "client-public",
    "sso-openid-connect",
    "context-ehr-patient",
    "permission-patient",
    "permission-user",
    "permission-v2"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ],
  "scopes_supported": [
    "launch",
    "openid",
    "fhirUser",
    "launch/servicerequest",
    "patient/Patient.r",
    "patient/Patient.rs",
    "user/Patient.rs",
    "user/Practitioner.r",
    "user/Practitioner.rs",
    "user/PractitionerRole.rs",
    "user/Organization.rs",
    "user/Location.rs",
    "patient/Appointment.rs",
    "user/Appointment.rs",
    "patient/Encounter.rs",
    "user/Encounter.rs",
    "patient/Condition.rs",
    "user/Condition.rs",
    "patient/AllergyIntolerance.rs",
    "user/AllergyIntolerance.rs",
    "user/ServiceRequest.r",
    "patient/MedicationRequest.rs",
    "patient/FamilyMemberHistory.rs",
    "user/DocumentReference.c",
    "user/Media.c"
  ]
}

400+
Clinics running Ava EMR
1,200+
Physician users
15
FHIR R4 resources
14
Validated CA Core+ profiles
Current profile at a glance The moving summary pauses while this section is focused or hovered, or when paused using the button above.
  • FHIR R4: 15 resources
  • CA Core+: 14 validated profiles
  • SMART App Launch 2.2: EHR launch
  • SMART Backend Services 2.2: Asymmetric clients
  • OAuth public client: PKCE S256 · no shared secret
  • Synthetic sandbox: Organization isolated
  • Production: Security reviewed
From draft to production

A visible path with separate decisions.

Sandbox access, production approval, and marketplace publication are related workflows—not the same switch.

  1. 01 / CONFIGURE

    Describe the app

    Add launch and redirect URIs, choose supported permissions, and explain why the app needs each scope.

    Public App Launch · EHR launch
  2. 02 / SANDBOX

    Test with synthetic data

    The portal asynchronously provisions an organization-isolated sandbox registration and displays its public client ID.

    Synthetic data · organization isolated
  3. 03 / REVIEW

    Request production access

    Submit an immutable security snapshot. If you opt into the marketplace, its listing content receives an independent review.

    Production and publication can diverge
Current FHIR R4 surface

Build against what exists today.

Bidirectional by design: read, search, and write interactions across Ava EMR's 15 FHIR resources. Fourteen advertise validated CA Core+ profiles; Media is an ordinary FHIR R4 resource.

The CapabilityStatement and SMART discovery documents are generated from the same registry that enforces authorization — if it's advertised, it's implemented and tested.

Current Ava EMR FHIR MVP capabilities
ResourceProfilePublic App LaunchBackend Services
Patient CA Core+ read + search read + search
Practitioner CA Core+ read + search read + search
PractitionerRole CA Core+ read + search read + search
Organization CA Core+ read + search read + search
Location CA Core+ read + search read + search
Appointment CA Core+ read + search read + search
Encounter CA Core+ read + search read + search
Observation CA Core+ read + search
Condition CA Core+ read + search read + search
AllergyIntolerance CA Core+ read + search read + search
ServiceRequest CA Core+ read
MedicationRequest CA Core+ read + search
FamilyMemberHistory CA Core+ read + search
DocumentReference CA Core+ create create
Media FHIR R4 create
Launch: EHR launch Client: public Proof: PKCE S256 Standards: FHIR 4.0.1 · SMART 2.2

SMART Backend Services 2.2 (asymmetric client authentication) is live in Ava EMR. Self-serve backend client registration and system/ scope selection are coming to this portal — contact us to register a backend client today.

Security model

Public does not mean unprotected.

A public SMART client has no secret it can safely keep. Its controls live in PKCE, exact redirect matching, narrow scopes, review, and clinic consent.

Every launch

PKCE proves the authorization response belongs to the app

The client creates a one-time verifier for each authorization flow. A stolen authorization code is unusable without it.

Before production

Review freezes the security inputs

Authentication profile, launch URI, redirects, scopes, and rationales are snapshotted so reviewers approve an exact configuration.

Least privilege

Only catalogued scopes can be selected

Unsupported, wildcard, free-form, and system scopes are rejected from this interactive profile. Added permissions can require clinic re-consent.

Independent controls

A marketplace listing never grants FHIR access

Production registration and listing publication are reviewed separately. Unpublishing a listing does not silently revoke an approved client.

API governance

Versioned, governed, and documented for change.

The API contract is explicit about what can change, when, and how a caller finds out.

Base path

Versioned routes

The FHIR major version is part of the base path, /fhir/r4/…. A future FHIR version mounts side by side under its own path, and the meaning of an existing path never changes in place.

Change control

Documented change control

Breaking and non-breaking changes are defined in a public versioning policy with committed deprecation windows, and every change lands in a public changelog.

For coding agents

Agent-ready documentation

Docs are published as llms.txt and llms-full.txt, plus a one-page integration brief sized for a coding agent's context window.

Distribution choices

Build for your clinic or a wider market.

Distribution describes who should discover an app. It does not change the OAuth profile or bypass production review.

Available

Private

Keep the app outside the marketplace while your own team develops and operates it.

Not listed

Roadmap

Invite-only

Limited rollouts with installation codes and clinic-install orchestration are on the roadmap; today, choose private or marketplace distribution.

On the roadmap

Independent review

Marketplace

Request a listing review alongside security review. Approved listings are discoverable by 400+ clinics running Ava EMR; publication waits for both an approved listing and active production registration.

Optional

Start with a synthetic sandbox.

Create an organization, register a public SMART app, and receive the client ID you need to test EHR launch. The sandbox carries no extra cost and contains only synthetic data—no PHI.

We're currently working with early adopters — request access to join the early developer program.