Quick answer
Separate the app’s requested data permissions from its launch context and user identity. Verify the scopes actually granted, the resident shown, the data reachable and what happens when access ends. SMART support is version-specific, and a successful launch does not establish appropriate access or a safe integration.
Distinguish three kinds of information
A SNF evaluates an app launched from a resident chart. It opens the right name on screen, so the team assumes its permissions are correct. The app could still request broader resources, receive a different set of granted scopes or retain access after the interactive session.
HL7 SMART App Launch 2.2.0 distinguishes FHIR resource permissions, launch context and identity information. It also describes online and offline refresh access. Use the deployed implementation's version and capabilities; not every product supports the current published guide in full.
The technical standard does not decide the facility's disclosure authority, business-associate relationship or acceptable data use. Review those arrangements alongside the app's technical permissions.
Write a narrow app-purpose specification
State the task the app performs and the data it needs. For example, a read-only display of selected observations for the current resident should explain any request to write data or access all residents available to a user. Broad scopes may have a legitimate purpose, but they should be deliberate rather than copied from a sample integration.
This original acceptance matrix separates the claims:
| Test | Expected evidence | Failure to investigate |
|---|---|---|
| Scope negotiation | Requested and granted permissions recorded | App assumes every requested permission was granted |
| Resident launch | Correct resident context and visible identity | Stale context from a previous chart |
| User identity | Intended user represented where needed | Shared or misleading attribution |
| Resource boundary | Only authorized resource operations succeed | A broader query exposes unintended information |
| Write attempt for read-only app | Appropriate rejection | Unintended modification succeeds |
| Revocation/session change | Documented access and refresh behavior | Old authorization continues beyond the reviewed design |
Use synthetic residents and accounts with different scopes. A test account with universal access cannot reveal many boundary failures.
Test context changes and multiple tabs
Launch the app from Resident A, then open Resident B in another tab. Observe whether the app preserves its original context, changes it through a supported mechanism or requires a relaunch. The interface should not suggest it is displaying B while requesting A's data. Staff need a clear resident identity inside the app, especially when windows are detached or embedded.
Also test a launch with missing or denied context. The app should follow a supported safe behavior rather than choosing the first available resident. Where a user selects a resident inside the app, verify the permitted population and the displayed identity.
Inspect persistent access
Online and offline refresh arrangements differ. Ask why the app needs continued access, what is stored, who can use it and how the authorization can be ended. Test access after the user signs out, after app authorization is revoked and after the user loses the relevant organizational access. Record the observed behavior of access tokens and refresh tokens separately without exposing their secret values in reports.
A fictional test finds that signing out closes the app's screen but a background job continues under an approved offline authorization. That may be intended, but it must match the reviewed service purpose and lifecycle. Screen closure is not itself revocation.
Make failure and change visible
Test expired tokens, denied scopes, unavailable resources and an app version change that requests additional access. The app should not silently substitute incomplete data for a complete resident assessment. Define how staff see limitations and how the integration team receives failures.
Acceptance should retain the app/version, supported SMART/FHIR versions, reviewed purpose, actual granted scopes, synthetic test results and revocation design. Reassess when permissions, data use or the app's service model changes. That turns an appealing embedded app into a bounded, supportable addition to the full platform.
Questions & answers
Does receiving a resident launch identifier authorize all chart access?
No. Launch context and resource permissions are distinct. The app must operate within the actual authorization and user permissions.
Why review offline access?
A refresh token associated with offline access can permit new access tokens after the user is no longer online, subject to the authorization arrangement. That creates a different lifecycle from a single interactive session.
Primary sources
Use the cited source and its applicable version when making a facility-specific decision. These guides explain operational evaluation methods; they are not individualized clinical, coding, or legal advice.