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.Īdditionally, SMART Web Messaging enables other interesting capabilities.
Interrogating the orders scratchpad / shopping cart, currently only known within the ordering provider’s CPOE session. suggesting a diagnosis or a condition to the patient’s chart. annotating a procedure with an appropriateness score or a radiation count. Communicating a decision made by the clinician within the SMART app, such as:. 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.įor these embedded apps, there are some key use cases that SMART and CDS Hooks don’t address today: 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. Once launched, web applications are often embedded within an iframe of the main UI. WhyĬlinical 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). 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. 
SMART Web Messaging allows applications to push unsigned orders, note snippets, risk scores, or UI suggestions directly to the clinician’s EHR session. SMART Web Messaging enables tight UI integration between EHRs and embedded SMART apps via HTML5’s Web Messaging.
0 kommentar(er)
