{"id":"epcr-smart-on-fhir","slug":"epcr-smart-on-fhir","title":"ePCR SMART-on-FHIR App Launch","description":"Ambulance services increasingly need to embed specialist applications into the clinical workflow without rebuilding those tools from scratch inside the core ePCR product. A service may want a guideline calculator, a rese","category":"modules","tags":["modules"],"lastModified":"2026-04-22","source_ref":"content/modules/epcr-smart-on-fhir.md","url":"/developers/epcr-smart-on-fhir","htmlPath":"/developers/epcr-smart-on-fhir","jsonPath":"/api/docs/modules/epcr-smart-on-fhir","markdownPath":"/api/docs/modules/epcr-smart-on-fhir?format=markdown","checksum":"4f9d1539281a80563878d50df88cd16bb51a0ebe705534d8cc2e04ec8b07bb51","headings":[{"id":"overview","text":"Overview","level":2},{"id":"key-features","text":"Key Features","level":2},{"id":"use-cases","text":"Use Cases","level":2},{"id":"integration","text":"Integration","level":2},{"id":"open-standards","text":"Open Standards","level":2}],"markdown":"# ePCR SMART-on-FHIR App Launch\n\n## Overview\n\nAmbulance services increasingly need to embed specialist applications into the clinical workflow without rebuilding those tools from scratch inside the core ePCR product. A service may want a guideline calculator, a research enrolment assistant, a specialist decision-support tool, or a vendor application that needs secure access to the current patient context. The challenge is letting those apps see the right encounter at the right time without exposing the whole platform.\n\nThe SMART-on-FHIR module gives the platform a standards-based clinical app launch model for the ePCR workspace. Organisations can register approved apps, launch them in the context of a specific encounter, and expose only the patient and observation context that app needs for its task. This makes the ePCR workspace extensible without turning every integration into a custom one-off build.\n\n```mermaid\nflowchart TD\n    A[Organisation App Registry] --> B[Approved SMART App]\n    C[Active Encounter] --> D[Launch Request]\n    B --> D\n    D --> E[Context and Authorisation Scope]\n    E --> F[App Opens with Patient and Encounter Context]\n    F --> G[Specialist Decision Support or Workflow]\n    G --> H[Clinician Returns to ePCR Workspace]\n```\n\n**Last Reviewed:** 2026-04-22\n**Last Updated:** 2026-04-22\n\n## Key Features\n\n- **Per-Organisation App Registry**: Let each organisation register the third-party clinical apps it trusts without affecting other tenants on the platform.\n\n- **Encounter-Scoped Launch Context**: Start an app from the active encounter so it opens with the relevant patient and case context instead of asking the clinician to search again.\n\n- **Launch-Scoped Clinical Data Access**: Expose only the patient, encounter, and observation context required by the app rather than granting broad platform access.\n\n- **Admin-Controlled Enablement**: Put registration and app availability under organisational governance so clinical tools can be approved, retired, or changed without a platform release.\n\n- **Embedded Workflow Support**: Allow third-party apps to sit naturally inside the encounter workflow rather than forcing clinicians to leave the ePCR environment.\n\n- **Short-Lived Launch Sessions**: Reduce integration risk by issuing context for the current launch session instead of creating permanent broad credentials for every app interaction.\n\n## Use Cases\n\n- **Clinical Decision Support Calculator**: A service launches a specialist tool from the encounter to review vitals and patient context for a specific pathway decision.\n\n- **Research or Trial Enrolment Workflow**: An approved study app opens directly in the context of the current patient episode so the clinician can determine eligibility without double entry.\n\n- **Device or Vendor Companion App**: A partner application reads the current patient and observation context to provide a specialist view while leaving the main ePCR as the system of record.\n\n- **Specialist Clinical Programme**: A cardiac, stroke, or mental-health programme introduces an app for a targeted cohort without forcing all users through a redesigned core workflow.\n\n- **Hospital-Linked App Experience**: A downstream clinical partner launches a standards-based app experience using the same encounter context already held by the field team.\n\n## Integration\n\n- **Electronic Patient Care Report Clinical Workspace**: Apps launch from the live encounter and return clinicians to the same workflow once the specialist task is complete.\n\n- **FHIR Mapper and Clinical Data Layer**: The app ecosystem uses the platform's standards-based clinical representation rather than a proprietary private schema.\n\n- **Organisation Administration**: Tenant administrators control which apps are registered and where they can be launched from.\n\n- **Patient Telemetry and Device Context**: Other encounter-linked modules, such as wearable context or bedside device observations, can enrich the launch context available to approved apps.\n\n## Open Standards\n\n- **SMART App Launch Framework 2.1**: provides the standards-based launch and context model for third-party clinical applications.\n\n- **HL7 FHIR R4**: encounter, patient, and observation context is exposed using the standard healthcare interoperability model expected by SMART apps.\n\n- **OAuth 2.0**: authorisation for app launch and token exchange follows the standard delegated-access model used by SMART implementations.\n\n- **OpenID Connect Discovery and Well-Known Configuration Patterns**: app onboarding and launch compatibility align to common standards-based discovery expectations.\n\n- **JSON**: launch metadata and FHIR resources move in the standard structured format used across modern clinical application ecosystems.\n"}