Clinician-facing
Your product is used alongside a patient chart.
What we define together
EHR launch, context handling and workflow-fit testing.
Epic SMART on FHIR Development
Epic SMART apps. The right context for better care.
Build an Epic-connected app around the person using it. We help you select the launch pattern, implement authorization and test the clinical workflow—not just the token exchange.
Plan my SMART appCompare launch patternsFor digital health teams, healthcare software companies and health systems.
The clinician’s launch journey
- 01Open the patient chart
The care team starts in their existing workflow.
- 02Launch your application
Receive and validate the available launch context.
- 03Authorize only what is needed
Use the configured scopes and supported authorization flow.
- 04Present useful information
Handle expired sessions, missing context and denied access.
Illustrative implementation plan · no patient data
Your starting point
Three patterns. Different users. Different tests.
Patient-facing
A person chooses to connect their health information.
What we define together
Standalone authorization, clear consent and recovery states.
Background service
A permitted service retrieves data without an interactive user.
What we define together
Backend authorization, key lifecycle and operational controls.
Launch pattern explorer
Choose for the user, not the acronym.
Launch alongside the clinical workflow.
Use an EHR-launch pattern when your product needs the context available from the clinical environment. The experience must still cope when optional context is missing.
- Entry point
- A configured launch from the EHR.
- Authorization
- Discover the authorization configuration and request the necessary permissions.
- Acceptance tests
- Correct context, denied scopes, expired sessions and customer-specific behavior.
Scope decision
Specify the clinician’s task and the context the app actually requires.
Authorization journey
The token is a step. The experience is the product.
Discover
Read the supported authorization configuration.
Request
Ask for the agreed scopes and launch context.
Validate
Check the response and establish the application session.
Use
Retrieve only the permitted data the feature needs.
Recover
Handle expiry, cancellation and lost access clearly.
Permission design
Least privilege should be visible in the specification.
An example scope is not a permission grant. Confirm syntax, operations and supported versions in the current Epic documentation.
User and patient context
List the context your feature needs and the fallback when it is absent.
Context contract and recovery behavior
Read and search operations
Map each requested permission to a concrete product feature.
Feature-to-scope matrix
Write operations
Validate supported writes and their clinical review requirements separately.
Operation-specific acceptance tests
Longer-running access
Choose token handling appropriate to the app type and permitted access.
Expiry, revocation and key lifecycle plan
Release readiness
Build a launch that survives the unhappy path.
Configuration review
Client IDs, redirects, launch URLs, environments and applicable app-update procedures.
Workflow validation
Missing context, partial data, user cancellation and inaccessible records—not only successful launches.
Customer handoff
Setup instructions, support contacts, known limitations and regression checks for subsequent releases.
SMART app questions
What your product team needs to know.
Is every SMART app a clinician-facing app?
No. Patient-facing apps and background services have different entry points and authorization patterns. Choose the model based on who acts and how access is granted.
Does passing Inferno g10 certify our SMART app?
No. Inferno g10 evaluates certified API-server capabilities. It is not a universal app certification or a guarantee that a customer will approve your product.
Can we request broad permissions now and use them later?
Scope the permissions around the features you are implementing. Additional access should follow a documented requirement and change process.
Can launch context replace a patient-matching strategy?
Do not assume every workflow provides the same context. Define the supported launch scenario and handle absent or incompatible identifiers explicitly.
Plan with the right evidence
Confirm the workflow. Then confirm the access.
Epic’s requirements and supported interfaces can change. Use the official documentation alongside your target customer’s implementation requirements.
Epic interoperability catalog ↗Epic developer documentation ↗Get the Epic Integration Checklist →Does sandbox success guarantee production access?
No. Production use requires the relevant app setup and customer-specific activation, permissions and validation.
What should we prepare for a scoping conversation?
Bring your intended workflow, required data and operations, target health systems, current integration status and any launch constraints. Do not share patient data.
Nirmitee.io provides independent integration engineering. This page does not imply Epic endorsement or guarantee customer approval.
Talk through your requirements
Let’s map the next useful step.
Tell us what your product needs to do and where you are in the integration journey. We’ll follow up to clarify the scope, dependencies and appropriate next step.
- Your workflow and target customer
- The data and operations you need
- What is already built—and what is blocked
Request received
Thank you for sharing the context.
Our team will review your requirements and follow up on scope and next steps.