List View to Detail App Recipe

Overview

A common pattern for apps in healthcare is to present a list of patients to a healthcare provider, then allow the provider to select one patient and see a detail view.  This interaction may seem simple but several key considerations need taken into account as you integrate this app with various EHR workflows:

  • How should the app manage the patients that are to be shown in the app (its list view)?
  • Should the app (its detailed view) be available within a patient's chart?
  • Should the app (its detailed view) be integrated with decision support prompts?
  • Should the app be integrated with messages to clinicians?

Ideally, the app would provide an implementation to support all of these use cases as:

  • The clinician opens the app without selecting a patient and sees the list view showing all list patients.
  • The clinician using the list view selects a patient, sees the detail view for the single patient, closes the detail view, sees the list view.
  • The clinician using the EHR selects a patient (opens their chart), sees a button for the apps detailed view, opens the detail view for the patient who's chart is showing in the EHR.
  • The clinician using their EHR selects a patient (opens their chart), sees a decision support alert/notification that this patient has <something> with a link to the app, clicks the app to open the detail view for the patient who's chart is showing.
  • The clinician using their EHR without selecting a patient sees an "inbox" message that the patient has <something> with a link to the app, clicks the link to open the patient's chart and app detailed view.
  • If a patient is selected within the EHR (their chart is open) should the app show any information for a different patient than the patient who's chart is open.

To support these various use cases of the same list and detailed view, the app should support the following perspectives:

 

ListDetailPerspectives.png

 

Implementation

Fortunately there are straightforward solutions for these use cases and perspectives.  To address each of these, we propose the following:

 

User Context (no patient selected)

In this use case, the app list view should complete a HL7 SMART Launch with the EMR requesting user-scoped data access.  For example, "user/Patient.rs user/Observation.rs" requests authorization to read ("r") and search ("s") any records permitted to the "user" within the "Patient" and "Observation" FHIR Resources.

When the app is granted authorization as part of the launch process, the app will be given a value along side of their access token if there is a patient already selected in the EHR (patient's chart is open).  This "Patient" parameter is optional in the response: if the value is provided, a patient's chart is open; if the value is not provided, no patient's chart is open.  See "patient" below:

{
"access_token": "secret-xyz",
"patient": "123",
"fhirContext": ["DiagnosticReport/123", "Organization/789"],
//...
}

The app must observe the "patient" value or lack of value, then show the appropriate view.  

  • If a "patient" value is NOT provided, the app can proceed to show the app's list view.  This is a "User Context" perspective.
    • In this perspective, the app can allow the user to select one of the patients from the app list view then show the user the app detail view, then allow the user to close the detail and select another patient.
  • If a "patient" value is provided (a patient's chart is open), the app MUST NOT SHOW the list view and other patient records, but should show the app's detail view for the provided patient.  This is a "Patient Context" perspective.
    • In this perspective, the app must not allow access to any list view, neither before showing the detail view or after showing the detail view.

Patient Context (patient selected, chart is open)

This use case has already been covered by the User Context use case.  Again, if the app is provided a "patient" value as part of launch, then the app must only show that single patient and no other by showing only the detail view.

 

CDS Hook (patient selected, CDS Hook is triggered by a hook notification)

As described in the CDS Hook spec, a CDS Hook service may return a "smart app link card" that contains a link to a SMART app.  The clinician, seeing the hook and app link, may select the link resulting in the app being launched.  In this perspective, the app detail view should be open directly without presenting the list view.

Note: the CDS Hook service that returns the smart app link card is something you would create as part of your system (your app and services as a whole).

 

Clinician Notification (no patient selected)

EHR vendors provide email-style notifications for clinicians.  Some EHR vendors provide APIs that allow app and service vendors to send messages to clinicians at a healthcare system to the clinician's inbox.  Some EHR vendors support these messages containing links to SMART apps.  

In this context, your services would decide to send a message to the clinician for a single patient.  The clinician would see the message and link to your app.  If they select the link to your app, your app would be launched from this user context.  It is assumed that the launch would contain a "patient" parameter.  Your app should behave within the Patient Context (not showing any other patient) by showing the detail view.  This should be the same logic implemented within your User Context/Patient Context launch flow.

Less common is for your app to send a notification to a clinician for all patients in your list.  In this workflow, the EHR Vendor would have to support a non-patient inbox notification with SMART app link.  If an EHR Vendor supports this workflow, your app only has to implement the User Context/Patient Context workflow and the "patient" parameter.

 

Let Us Help

We have implemented these scenarios many times with many EHR Vendors.  Contact us for support.

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.