Data Exchange For Quality Measures Implementation Guide: STU1 Ballot 1 (for FHIR 3.0.1)

This page is part of the Da Vinci Data Exchange for Quality Measures (DEQM) FHIR IG (v0.1.0: STU 1 Ballot 1) based on FHIR R3. The current version which supercedes this version is 3.1.0. For a full list of available versions, see the Directory of published versions

General Guidance and Definitions

Introduction

Clinical Quality Measures are a common tool used throughout healthcare to help evaluate and understand the impact and quality of the care being provided to an individual or population. However, the data-of-interest for a particular quality measure is often spread throughout multiple organizations and systems. To effectively evaluate quality measures in such an environment requires timely exchange of the relevant data. This Guide (IG) uses a set of FHIR operations that provide a framework to enable the Exchange of Quality Measure Data between Data “Aggregators” (organizations that want to evaluate quality measures) and Providers (organizations that deliver care to patients). This guide describes three methods of exchanging data quality information:

  1. Measurement data may be submitted to the Aggregator by the Provider using the Submit Data operation
  2. Measurement data may be requested from the Provider by the Aggregator using the Collect Data operation
  3. The Aggregator may subscribe to a Provider’s Subscription service to be notified when the measurement data is available.

These transactions are triggered by use case specific clinical or administrative events such as the completion of a Medication Reconciliation.

General Preconditions and Assumptions

  • The “Aggregator” may be a Payer or another organization that is monitoring various clinical quality measures for the members of a population.
  • The Measure resource is used to provide both human- and machine-readable definitions of a quality measure
  • The MeasureReport resource is used as a quality-focused container for the exchange of quality information, not necessarily as a report of the actual measure score for a particular measure
  • Aggregators may process CQL, but are not required to in order to support the exchange scenarios described in this Guide
  • Providers do not need to use CQL to support the exchange scenarios described in this Guide.

Profiles

Graph of DEQM Resources:

DEQM Resource Graph.
measure-resource-graph.jpg


Option 1: Submit Data operation

The Submit Data operation allows a Provider to submit data-of-interest for a particular quality measure. There is no expectation that the data submitted represents all the data required to evaluate the quality measure, only that the data is known to be relevant to the quality measure, based on the data requirements for the measure.

To discover what data (i.e. resources) are relevant in the Submit Data payload for a particular measure, a Data Requirements operation MAY be invoked on a Aggregator’s measure instance endpoint. The response to this operation provides a list of Data Requirements which detail what data needs to be submitted in order for the Aggregator to evaluate the measure.

.
mrp-wf-overview.jpg

Gather Data Requirements From Aggregator

In this optional step, the provider queries the aggregator for which resources/profiles are needed for reporting a given measure. To support the Submit Data operation, an implementation needs to know what data to provide as the payload for the operation. This can be done manually by reviewing the measure definition to determine what data needs to be submitted, or it can be automated using the Data Requirements operation. These profiles are subsequently referenced in the MeasureReport.evaluatedResources element when submitting the measure data to the Aggregator .

Data Requirements Operation.
data-requirement.jpg

APIs

In addition to the resources listed above, the following artifacts are used in this transaction:

  1. Data Requirements: $data-requirements (R4) operation (Note - the same operation is used for both version STU3 and R4 transaction)
Usage

The required data for each Measure is discovered by invoking the Data Requirements operation on the aggregator’s Measure/[measure-id] endpoint. Using either the GET or POST Syntax, the operation can be invoked as follows:

GET|[base]/Measure/[measure-id]/$data-requirements?periodStart={periodStart}&periodEnd={periodEnd}

POST|[base]/Measure/[measure-id]/$data-requirements

Note the use of the periodStart and periodEnd parameters supports description of data requirements that filter based on the reporting period. For example, a measure may require data for a certain procedure within the last three years, and the data requirements returned will reflect that period.

Scenario

Provider X requests data requirements for the MRP measure from Payer Z. Library resource containing the required resources for MRP attestation returned on successful evaluation.

Request using GET

GET [base]/Measure/measure-mrp/$data-requirements?periodStart=2018&periodEnd=2018

Request using POST

POST [base]/Measure/measure-mrp/$data-requirements

Request body

{
   "resourceType":"Parameters",
   "parameter":[
      {
         "name":"periodStart",
         "valueDate":"2018"
      },
      {
         "name":"periodEnd",
         "valueDate":"2018"
      }
    ]
 }

Response

HTTP/1.1 200 OK
[other headers]

Response body

{
   "resourceType":"Library",
   "status":"active",
   "type":{
      "coding":[
         {
            "code":"module-definition"
         }
      ]
   },
   "relatedArtifact":[
      {
         "type":"depends-on",
         "resource":{
            "reference":"Library/library-mrp-model-definition"
         }
      }
   ],
   "dataRequirement":[
      {
         "type":"MeasureReport",
         "profile":[
            "http://hl7.org/fhir/us/davinci-deqm/STU3/StructureDefinition/measurereport-mrp"
         ]
      },
      {
         "type":"Patient",
         "profile":[
            "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
         ]
      },
      {
         "type":"Encounter",
         "profile":[
            "http://hl7.org/fhir/us/core/StructureDefinition/us-core-encounter"
         ]
      },
      {
         "type":"Location",
         "profile":[
            "http://hl7.org/fhir/us/core/StructureDefinition/us-core-location"
         ]
      },
      {
         "type":"Task",
         "profile":[
            "http://hl7.org/fhir/us/davinci-deqm/STU3/StructureDefinition/task-mrp"
         ]
      },
      {
         "type":"Organization",
         "profile":[
            "http://hl7.org/fhir/us/davinci-deqm/STU3/StructureDefinition/organization-davinci"
         ]
      },
      {
         "type":"Practitioner",
         "profile":[
            "http://hl7.org/fhir/us/davinci-deqm/STU3/StructureDefinition/practitioner-davinci"
         ]
      }
   ]
}


Submit Data Operation

Once the Provider understands the data requirements, they will use the Submit Data operation to submit a MeasureReport and the referenced resources as discovered by the Data Requirements operation to the Aggregator. The Aggregator simply accepts the submitted data; there is no expectation that the Aggregator will actually evaluate the quality measure in response to every Submit Data.

Submit data Operation.
submit-data.jpg

APIs

In addition to the resources listed above, the following artifacts are used in this transaction:

  1. Submit Data operation: $submit-data (R4) ( Note - the same operation is used for both version STU3 and R4 transaction)
  2. Various DEQM and QI Core Profiles depending on the specific Measure
Usage

Using the POST Syntax, the operation can be invoked by the Provider:

POST|[base]/Measure/[measure-id]/$submit-data

Examples

Scenario:

Provider X submits MRP data for Patient Y to Payer Z. The body of the request is a Parameters resource containing the required profiles for MRP attestation using Task as the resource used to evaluate the measure. An HTTP Status success code is returned on successful submission.

Request using POST

POST [base]/Measure/measure-mrp/$submit-data

Request body

{
   "resourceType":"Parameters",
   "parameter":[
      {
         "name":"measurereport",
         "resource":"{"resourceType": "MeasureReport",
         ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Task",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Patient",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Location",
          ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Practitioner",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Organization",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Coverage",
        ...}
      },

    ]
 }

Response

HTTP/1.1 200 OK
[other headers]


Option 2: Collect Data operation

In this scenario, the Aggregator initiates a Collect Data operation to gather any available quality reporting data for a particular measure from the Provider. In response to the operation, the Provider returns a MeasureReport containing data relevant to the Measure. As with the Submit Data operation, there is no expectation that this MeasureReport contains all the data required to evaluate the quality measure, nor is the measure score expected to be provided.

As with the Submit Data case above, discovery of what data (i.e. resources) are required is done through the Data Requirements operation on a Aggregator’s measure endpoint and the returned resources and profiles are referenced in the MeasureReport.evaluatedResources element.

.
collect-data-steps.jpg

Collect Data Operation

The Aggregator uses a Collect Data operation to request any available relevant data for the evaluation of a particular measure from a Provider. This would typically be done on a periodic basis to support incremental collection of quality data. The lastReceivedOn parameter can be used to indicate when the last Collect Data operation was performed, allowing the Provider to limit the response to only data that has been entered or changed since the last received on date.

Note that implementing this scenario requires that the Provider system understand the data requirements for the measure in order to provide the data. As with the Submit Data operation, the implementation can either manually determine the relevant data using the measure definition, or the implementation can use the Data Requirements operation to determine relevant data.

Collect data Operation.
collect-data.jpg

APIs

In addition to the resources listed above, the following artifacts are used in this transaction:

  1. Collect Data operation:$collect-data (STU3) or $collect-data (R4)
  2. Various DEQM and QI Core Profiles depending on the specific Measure

Usage

Collect Data (STU3 and R4):

Using either the GET or POST Syntax, the operation can be invoked by the Aggregator :

GET|[base]/Measure/[measure-id]/$collect-data&[parameters]

POST|[base]/Measure/[measure-id]/$collect-data

Examples

Scenario: Payer Z fetches MRP data from Provider X for Patient Z

Request using GET Syntax

GET [base]/MeasureReport/measure-mrp/$collect-data?patient=Patient/patient-z&provider=Practitioner/provider-x&periodStart=2018-06-19

Request using POST Syntax

POST [base]/MeasureReport/measure-mrp/$collect-data

Request body

{
   "resourceType":"Parameters",
   "parameter":[
      {
         "name":"patient",
         "valueUri":"Patient/patient-z"
      },
      {
         "name":"practitioner",
         "valueUri":"Practitioner/provider-x"
      },
      {
         "name":"periodStart",
         "valueDate":"Practitioner/2018-06-19"
       }
    ]
 }

Response

HTTP/1.1 200 OK
[other headers]

Response body

{
   "resourceType":"Parameters",
   "parameter":[
      {
         "name":"measurereport",
         "resource":"{"resourceType": "MeasureReport",
         ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Task",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Patient",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Location",
          ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Practitioner",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Organization",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Encounter",
        ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "Coverage",
        ...}
      },

    ]
 }


Data Requirements Operation

In order to complete the transaction the Provider may need to discover the required data for each Measure by invoking the Data Requirements operation on the aggregator ‘s Measure/[measure-id] endpoint. This operation is discussed in the section above


Option 3: Subscription service combined with the Collect Data operation

Subscriptions allow for a Provider to notify the Aggregator whenever new Measure data is available. Effectively, the Aggregator subscribes to the Provider’s system using the Measure as the criteria. It is a short-hand for subscribing to all the data-of-interest (as defined by the data requirements) for the measure, but using the Measure as the subscription point allows the implementation to determine the most efficient approach to notification. For example, notifications can be batched on a periodic basis, or they can be performed along transactional boundaries within the implementing system.

Once an Aggregator is notified, the Aggregator then uses the Collect Data operation described above to request the relevant data.

.
subscribe-data-steps.jpg

Subscribe for Measure Data

The Aggregator must first subscribe to the Provider for a notification for a particular measure. An Aggregator may also unsubscribe to a measure subscription.

Subscription Service.
subscribe-data.jpg

APIs

The following artifacts are used in the subscription transaction:

  1. DEQM Subscription Profile DEQM Subscription (STU3) or DEQM Subscription (R4)
  2. DEQM Measure Subscription Extension Measure Subscription (STU3) or Measure Subscription (R4)
Usage

To subscribe for measure notifications , The Aggregator SHALL use the standard FHIR Subscription API as follows:

POST [base]/Subscription

To unsubscribe:

Delete [base]/Subscription/[id]

Subscribe

POST [base]/Subscription

Request body

Using the Measure Subscription modifier extension to modify to the criteria element to define the measure instance id

<?xml version="1.0" encoding="UTF-8"?>
<Subscription xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../schema/subscription.xsd">
 <id value="med-rec-example"/>
  <text>
    <status value="generated" />
    <div xmlns="http://www.w3.org/1999/xhtml">[Put rendering here]</div>
  </text>
  <!--  this is a proposed extension to make criteria not just a search string -->
  <modifierExtension>
    <url value="http://example.org/measure-subscription"/>
    <valueCode value="active"/>
  </modifierExtension>
  <status value="active"/>
  <contact>
    <system value="phone"/>
    <value value="ext 4123"/>
  </contact>
  <reason value="Monitor medication reconciliation attestation"/>
  <criteria value="Measure/measure-mrp"/>
  <channel>
    <type value="rest-hook"/>
    <!-- TODO: Need a discussion on whether we can pass something here instead of having to expose different endpoints per measure -->
    <endpoint value="https://payersystem.com/fhirserver/on-measure-subscription-mrp"/>
    <payload value="application/fhir+json"/>
    <!--header value="Authorization: Bearer secret-token-abc-123"/-->
  </channel>  
</Subscription>

Response

HTTP/1.1 200 OK
[other headers]


Get Data Requirements

The DEQM Subscription Profile allows the subscriber to send a DEQM Measure instance id. By invoking the $data-requirements operation (see above) on a subscriber’s Measure instance endpoint, the server can discover what data is needed to calculate by a subscriber for particular measure. This information is necessary to correctly trigger a notification when the requisite data is available.

Measure Notifications

The Provider notifies the Aggregator when measure data is available. Exactly, how this notification is triggered is out of scope for this guide. Note that several architectures to implement the subscription notifications such as “point to point” notification or using a “feed handler” as an intermediary system, are available.

Measure Notifications.
measure-notifications.jpg

Usage

The standard FHIR Subscription API describes the REST Hook channel as follows:

POST [app notification endpoint]

Measure Notification:

POST https://payersystem.com/fhirserver/on-measure-subscription-mrp

** No notification body**


Collect Data Operation

Upon notification, the Aggregator uses the Collect Data operation to request a MeasureReport and any relevant data from the notifying Provider. This operation is discussed in the section above.

Must Support

  1. The receiver of data may not be able to complete processing and may “error out” if a Must Support element is unavailable.