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
  • General Preconditions and Assumptions
  • Profiles
  • Option 1: Submit Data operation
  • Option 2: Collect Data operation
  • Option 3: Subscription service combined with the Collect Data operation
• Must Support

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

• The following resources are used in all these transactions:

  Resource Type	Profile Name	Link to STU3 Profile	Link to R4 Profile
  Library	DEQM Library Profile	DEQM Library (STU3)	DEQM Library (R4)
  Measure	DEQM Measure Profile	DEQM Measure (STU3)	DEQM Measure (R4)
  MeasureReport	DEQM MeasureReport Profile	DEQM MeasureReport (STU3)	DEQM MeasureReport (R4)
  Organization	DEQM Organization Profile	DEQM Organization (STU3)	DEQM Organization (R4)
  Patient	QI Core Patient Profile	QI Core Patient (STU3)	QI Core Patient (R4)
  Subscription	DEQM Subscription Profile	DEQM Subscription (STU3)	DEQM Subscription (R4)

• Depending on the specific Measure, various DEQM and QI Core Profiles are also used in addition to the profiles listed above

Graph of DEQM Resources:

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.

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 .

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.

Example Data Requirements operation

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

HTTP/1.1 200 OK
[other headers]

{
   "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.

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

Example Submit Data operation

{
   "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",
        ...}
      },

    ]
 }

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 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.

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

Example Collect Data operation

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

HTTP/1.1 200 OK
[other headers]

{
   "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 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.

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]

Example Subscription Transaction

<?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>

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.

Usage

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

POST [app notification endpoint]

Example Subscription Notification

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

• This guide adopts the QI Core Must Support definition with the following additional expectations:

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