This page is part of the SMART Web Messaging Implementation Guide: STU1 (v1.0.0: STU1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions
SMART Web Messaging enables tight UI integration between EHRs and embedded SMART apps via HTML5’s Web Messaging. SMART Web Messaging allows applications to push unsigned orders, note snippets, risk scores, or UI suggestions directly to the clinician’s EHR session. Built on the browser’s javascript window.postMessage function, SMART Web Messaging is a simple, native API for health apps embedded within the user’s workflow.
Why
Clinical workflow systems (such as EHRs) may be able to launch SMART applications in a few different ways: automatically at specific points in the workflow, by user interaction in the UI, or in response to a suggestion from a CDS Hooks Service (or other decision support service). Once launched, web applications are often embedded within an iframe of the main UI. In this model, the new application appears in close proximity to a patient’s chart and can work with the EHR via RESTful FHIR API. These RESTful APIs are great for CRUD operations on a logical FHIR Server endpoint, but they don’t enable tight workflow integration or access to draft FHIR resources that may only exist in memory on the EHR client.
For these embedded apps, there are some key use cases that SMART and CDS Hooks don’t address today:
Communicating a decision made by the clinician within the SMART app, such as:
placing an order
annotating a procedure with an appropriateness score or a radiation count
transmitting a textual note snippet
suggesting a diagnosis or a condition to the patient’s chart
Interrogating the orders scratchpad / shopping cart, currently only known within the ordering provider’s CPOE session.
Allowing an app to communicate UX-relevant results back to the EHR, for example, automatic navigation to a native EHR activity, or sending an “I’m done” signal.
Additionally, SMART Web Messaging enables other interesting capabilities. For example:
Saving app-specific session or state identifiers to the EHR for later retrieval (continuing sessions).
Interacting with the EHR’s FHIR server through this messaging channel (enabling applications that cannot access the FHIR server directly, e.g. those hosted on the internet).
How
SMART Web Messaging builds on HTML5’s Web Messaging specification, which allows web pages to communicate across domains. In JavaScript, calls to
window.postMessage can pass data between windows by dispatching MessageEvent objects.
The following sequence diagram outlines several of the key events that take place leading up to a successful app invocation of an EHR launched activity via SMART Web Messaging messages. For simplicity, the full details of the SMART App Launch sequence are abbreviated and the only details shown are the fields needed for conformant SMART Web Messaging.
Refer to the SMART Web Messaging technical documentation page for details on the specification.
|
Propose a change