App Device Profile

Canonical	../StructureDefinition/nexus-emr-core-appdevice
Status	draft · 1.26.0
Base	Device (constraint)
Source	FSH · 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.

FSH

The authored source of truth: resources/StructureDefinition-nexus-emr-core-appdevice.fsh (edit on GitHub). One FSH file may define several related artifacts.

// Simple profile for applications that integrate with patient data
// KISS approach: Just the essentials for consent tracking and app management

Profile: NexusEmrCoreAppDevice
Parent: Device
Id: nexus-emr-core-appdevice
Title:          "App Device Profile"
Description: "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."

// THE effective date for this profile (see the EffectiveDate / NoEffectiveDate
// RuleSets): one date concept per resource, declared here rather than guessed.
* insert NoEffectiveDate

// SMART on FHIR exposure -- READ-ONLY, a SECURITY boundary: this profile is the application
// registration itself, carrying the OAuth client_id as an identifier. An app able to write
// Device could mutate app registrations, its own or another's. Per-type, so covers emrdevice.
* insert SmartExposedReadOnly(device)

* ^url = "../StructureDefinition/nexus-emr-core-appdevice"
* ^status = #draft
* insert NoResourceNoteExtension

* meta.source 0..1 MS
* meta.source ^short = "Identifies EMR instance & pipeline version the resource came from"
* meta.source ^definition = "A URI that identifies the EMR pipeline and version from which this resource originated.  This tells you which EMR instance (recommend using the instance identifier), and the version of the pipeline code/transformations."

// Essential elements only
// NOT Must Support, and the reason is what a production application can be relied on to write.
// `identifier` here is RECOMMENDED but not required. Must Support asserts that an implementer can
// be expected to populate an element, and no production writer mints a business identifier onto
// this type today -- the per-tenant scheme that once did was retired (FHIR-71), and nothing
// replaced it on the write path. Claiming Must Support for an element the specification neither
// mandates nor sees produced would state a guarantee that is not being made.
//
// THAT IS NOT THE SAME AS THE ELEMENT BEING EMPTY, and a reader should expect values. This
// guide's own examples carry one, and so does the synthetic corpus, under
// `NamingSystem/nexus-emr-appdevice-identifier` -- the app registration slug, which is also how an
// application is named on an AppConsent provision actor, a Composition author and a Provenance
// agent. A writer with either that slug or a source-system identifier should carry it.
//
// What would settle Must Support: a production registration path that assigns the slug onto the
// Device resource rather than only onto the references that name it.
* identifier 0..*
* identifier ^short = "App identifier (include OAuth client_id)"

* deviceName 1..1 MS 
* deviceName.name 1..1 MS
* deviceName.name ^short = "Simple app name"

* status 1..1 MS
* status ^short = "active | inactive"

* manufacturer 0..1 MS
* manufacturer ^short = "App developer/company (optional)"

* type 0..1 MS
* type ^short = "Software application type"

* note 0..1 MS
* note ^short = "Brief description of the app"