App State Profile¶
| Canonical | ../StructureDefinition/nexus-emr-core-appstate |
|---|---|
| Status | active · 1.26.0 |
| Base | Basic (constraint) |
| Source | FSH · JSON |
A profile for representing external application state in Nexus EMR.
Overview
Some stored records do not satisfy this profile. code.coding.system is constrained at error
severity to a ../CodeSystem/[app-name]-app-state URL (invariant
app-state-system-inv), and records are filed today under systems that cannot match it, so a
consumer validating Basic resources against this profile will meet records that fail; that is
tracked as FHIR-386. This guide declares no code system for them, because an app-state namespace
is declared by the app whose state it is rather than here.
Overview
The Nexus EMR Core AppState profile represents application state and settings data within the Nexus EMR ecosystem. Based on the FHIR Basic resource and following the SMART App Launch state persistence pattern, this profile enables external applications, integrations, and apps to store and retrieve configuration data, user preferences, and application-specific state information in the FHIR repository.
Key Features
- Namespaced State Management: Application-specific namespaces prevent conflicts
- Type-Safe Values: Supports string, boolean, and extensible value types
- Resource Association: Links state to specific FHIR resources (Patient, Organization, etc.)
- Standards-Based: Follows SMART App Launch v2.2.0 state persistence patterns
- Flexible Storage: Accommodates various application state requirements
Purpose and Use Cases
The AppState profile supports:
- User Preferences: Storing application-specific user settings
- Session State: Maintaining state across application sessions
- Configuration Data: Application configuration parameters
- Integration Settings: External system connection preferences
- Workflow State: Tracking multi-step process states
- Feature Flags: Application feature toggles and controls
State Management Pattern
AppState follows a structured pattern:
- Namespace: Application-specific CodeSystem URL identifies the app
- Type Code: Specific state type within the application namespace
- Subject: The FHIR resource the state is associated with
- Value: The actual state data (string, boolean, etc.)
Application Namespacing
Each application uses its own namespace:
- Pattern:
../CodeSystem/[app-name]-app-state - Prevents state conflicts between applications
- Enables easy filtering by application
- Supports multiple state types per application
Value Types
Currently supported value extensions:
- String Values: Text, JSON, XML, or any string data
- Boolean Values: True/false flags and toggles
- Future Extensions: Additional types can be added as needed
Clinical Integration
AppState enables:
- Personalized application experiences
- Workflow continuity across sessions
- User-specific display preferences
- Clinical decision support configurations
- Integration parameter storage
Security Considerations
Important aspects:
- State data should not contain PHI unless necessary
- Access controls follow subject resource permissions
- Applications should only access their namespaced state
- Sensitive configuration data should be encrypted
Relationships
AppState connects to:
- Patient: Patient-specific application settings
- PractitionerRole: Provider preferences and configurations
- Organization: Organization-wide application settings
- DocumentReference: Document-specific state
- Any FHIR Resource: Via subject reference
Implementation Guidelines
Best practices include:
- Use meaningful state type codes within namespaces
- Document state data structures for maintainability
- Implement cleanup for obsolete state data
- Version state schemas when structure changes
- Use appropriate value types for data
SMART App Launch Alignment
This profile aligns with:
- SMART App Launch v2.2.0 state persistence
- Experimental app state specifications
- Cross-platform state management patterns
- OAuth2 application contexts