Skip to content

App Device Profile

Canonical../StructureDefinition/nexus-emr-core-appdevice
Statusdraft · 1.26.0
BaseDevice (constraint)
SourceFSH · JSON

Simple profile for applications that integrate with patient data and require consent tracking. Contains just the essential information: app name, client_id, and basic details.

Overview

Overview

The Nexus EMR Core App Device profile is the registration record for a third-party application that integrates with patient data: its name, its OAuth client_id, and whether the registration is active. It exists so consent can name an application: NexusEmrCoreAppConsent references it from provision.actor.reference, which is restricted to this profile. The Device therefore has to exist before the consent that points at it.

The profile is deliberately minimal — it carries app identity, not app capability. Nothing about scopes, endpoints, or authorization state is modelled here.

App Device and EMR Device are siblings on Device

Device carries two NexusEmr profiles for two different things, and meta.profile is what separates them:

  • nexus-emr-core-appdevice (this profile) — a third-party application, the actor of an app consent. Only deviceName (with deviceName.name) and status are mandatory.
  • nexus-emr-core-emrdevice — an EMR software product or instance, used for provenance. It mandates manufacturer, deviceName.name and .type, type (with type.text fixed to software), version.value, and owner referencing a NexusEmrCoreOrganization — all 1..1.

A reader that validates an application registration against the EMR profile collects failures on five mandatory elements that an app has no values for, so confirm which profile a Device claims before treating its absent elements as data quality problems. Conversely, an app-device instance is not a source-system descriptor: do not read it as provenance for clinical data.

What the profile constrains

Every constrained element is must-support:

  • deviceName 1..1 with deviceName.name 1..1 — the app name shown to staff and patients. Narrower than base Device.deviceName (0..*), so exactly one name is carried. deviceName.type is left as inherited, unlike the EMR profile which requires it.
  • status 1..1 — active or inactive, meaning whether the registration itself is live. It says nothing about whether any patient has consented; that answer lives in the Consent resource.
  • identifier 0..* — include the OAuth client_id. No canonical system is mandated, so use the registry's own system URI where there is one. The identifier is the join between the FHIR record and the authorization layer, so an app registration without one is hard to reconcile in practice even though the profile permits it.
  • manufacturer 0..1 — the developer or company.
  • type 0..1 — the kind of software application. Unlike the EMR profile, nothing is fixed here.
  • note 0..1 — a brief description. Narrowed from base 0..*, so a producer emitting several notes fails validation; use one.

Exposure

The profile is exposed to SMART apps read-only (device:read). This is a security boundary rather than a preference: the resource is the application registration and carries the OAuth client_id, so an app able to write Device could mutate registrations — its own or another application's. SMART exposure is declared per resource type, so the EMR Device profile is read-only for the same reason. Registrations are created and maintained through EMR-side administration, not through the SMART API.