Da Vinci - Documentation Templates and Rules 0.2.0 - STU Ballot

This page is part of the Documentation Templates and Rules (v0.2.0: STU 1 Ballot 2) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions

CDS Hooks

One entry point into the Documentation Templates and Rules (DTR) application is launching from a Clinical Decision Support (CDS) Hooks Card.

DTR applications SHOULD, to the extent possible, capture and return information that is relevant to the specific use case.

As a part of a CDS Hooks response, the Payer IT system SHALL return a Card object with at least one Link object populated in the Card.links property. The Link object SHALL have a type property set to smart. The Link object SHALL have a URL property set to the launch URL of the DTR application.

A payer may secure endpoints from which the DTR application will retrieve additional artifacts to support execution. If the payer does require authentication, then the Payer IT system SHALL provide the authentication information through the appContext property of the Link object. The appContext property SHALL contain escaped JSON. The structure of this JSON is described in Section 4.4.1.1 - Authentication of SMART on FHIR application to payer API.

Establish Patient Context

When the DTR application is being launched from a CDS Hooks Card Link, the Electronic Health Record (EHR) system and DTR application will follow the procedures established by the SMART Application Launch Framework Implementation Guide Release 1.0.0. The EHR and DTR application SHALL follow the EHR launch sequence.

In Step 1 of the launch sequence, the DTR application SHALL request the patient/Patient.read scope. The DTR application MAY request other scopes to retrieve FHIR resources to use in order to evaluate payer rules. The DTR application MAY also request the openid and fhirUser scopes to establish a user session. Greater detail on this can be found in Section 4.4.5.2 - Requesting User Identity.

In Step 3 of the launch sequence, in the case where the EHR system is returning a response with an access token, the system SHALL also provide a patient property set to the identifier of the patient that is the subject of this interaction.

For cases where the DTR application is being launched outside the context of Coverage Requirements Discovery workflow, please see Section 4.4.8.