Da Vinci 3-4 Coverage Requirement Discovery and Medication Reconciliation Profile

The profile contains a set of routes that implement two major processes:

  1. Coverage Requirements Discovery: Prior to prescribing a treatment, the Provider makes a request to the Payer to get information about the co-payment and other requirements, if any. In this scenario, the Provider and the Payer exchange data using CDS hooks and the Provider receives CDS cards with information about co-payment and other requirements as a response.
  2. Medication Reconciliation: After the Provider prescribes a treatment, the Provider has to notify the payer of the treatment and medication that have been prescribed for the patient. The process consists of two steps: at first, the Provider makes a request to the Payer to get the FHIR resources currently supported by the Payer's FHIR server. Then, the Provider submits the supported FHIR resources to the Payer's FHIR server.

Coverage Requirements Discovery Process

External Request Processing Route

The route does the following:

  • The route receives a POST request that carries a medication-prescribe CDS hook.
  • The route extracts the medication code from the hook and makes a GET request to an external Coverage Requirement Discovery (CRD) service (emulated by the Da Vinci 3 CRD emulation route) and passes the medication code as a query parameter.
  • The CRD service returns a response with information about co-payment and requirements.
  • Based on the response from CRD, the route generates CDS cards with information about co-pay and other requirements, and the route returns the cards to the Provider.

Da Vinci 3 CRD emulation Route

This route emulates a Coverage Requirement Discovery (CRD) web service. The service receives a GET request with a medication code passed as a query parameter, and returns a JSON-formatted response that contains the medication description, costs, and other requirements.

Medication Reconciliation Process

Medication Reconciliation Data Requirements Route

The route represents a service that requests the Payer to return a list of currently supported FHIR resources.

The route does the following:

  • The route receives a GET request at the /measure-mrp/$data-requirements RESTful endpoint. This event is a signal to ask the Payer for the supported FHIR resources.
  • The route requests the Payer to return a list of supported FHIR resources. Here, the Payer is represented by the Da Vinci 4 Reconcilliation emulation route.
  • After receiving the response with a list of supported resources, the route builds a bundle that includes only the supported resources (resources are conditionally injected using the Velocity component) and returns the bundle to the caller (in this scenario, to the Provider).

Da Vinci 4 Reconciliation Emulation Route

The route returns a list of FHIR resources currently supported by the Payer's FHIR server.

Medication Reconciliation Submit Data Route

This route receives a POST request with information on the medication and treatment prescribed by the Provider for the patient.

The route does the following:

  • The route receives a POST request carrying a FHIR bundle that consists only of the resources currently supported by the Payer's FHIR server.
  • The route submits the bundle to the Payer's FHIR server.
  • After the bundle is stored on the Payer's FHIR server, the route responds with the 201 CREATED response code.