Smart On FHIR Applications

This feature is currently incubating
Smart On FHIR integration requires the Healthcare Feature Set subscription.

Modeling

During modeling a model (process, decision or case) can use FHIR data types for their inputs. These inputs can be automatically fetched upon start operation by setting up custom attributes in the following way:

smart on fhir 1

Custom attributes must conform to the following rules:

  • Name of the attribute must be FHIR

  • Value of the attribute is an expression that references queries to be performed on FHIR service

Following is a list of expressions (these that are placed within {{ }})

context.patientId

references id of the patient that the application was started with

context.userId

references id of the current user (e.g., practitioner)

context.encounterId

references id of the encounter being started
smart on fhir 2

In addition to that, service tasks can also be used to interact with FHIR server. Service instance will be equipped with authorization information to work with FHIR server. Worth to note is the configuration of the service used by the service task.

smart on fhir 3

The configuration of the service is done in the same way as any other but there are two additional check marks important for SMART on FHIR application functionality

  • Allow URL Override - this instructs the service execution to use FHIR server given during the launch of the application. This means that the Server URL given here is optional.

  • Allow Provided Identity - this instructs the service execution to rely on identity information provided during the launch of the application. This means that identity does not have to be created for this service.

Publishing

A service upon publishing can be marked as SMART on FHIR application. By doing that the service will be equipped with additional metadata to be able to integrate with FHIR servers when the initiation of the service instance is done from EHR server or Application gallery.

smart on fhir 4

In SMART on FHIR section there are two fields that should be filled in in most of the cases:

  1. Client ID - corresponds to identifier assigned in the EHR portal that the application will be launched from. This identifier is assigned during the registration process of the application in EHR.

  2. Scopes - are the FHIR scopes that are required for application to run.

Both fields are optional (they will be given defaults if not provided) but recommended to follow the best practices of SMART on FHIR applications.

smart on fhir 5

Once a service is published, in the service library there is a dedicated section to healthcare integration.

smart on fhir 6

Client ID and Scope are displayed based on the values entered during publishing or if not given the default values.

Launch URI and Redirect URI are the endpoints that will be used by the EHR portal to start the application and perform authorization process.