This page is part of the Da Vinci Data Exchange for Quality Measures (DEQM) FHIR IG (v0.2.0: STU 1 Ballot 2) 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

Data Exchange Interactions

• Introduction
• Profiles
• Data Exchange
  • Submit Data operation
  • Collect Data operation
  • Subscriptions

Introduction

Clinical Quality Measures (CQMs) 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. The intent of “data-of-interest” is the source data needed to calculate a quality measure, as specified by the data requirements of the measure. For example, for a colorectal cancer screening measure, the data-of-interest is the set of conditions, procedures, and observations related to determining whether a patient is in the initial population, denominator, and numerator of the quality measure. To effectively evaluate quality measures in such an environment requires timely exchange of the relevant data.

Transactions between Consumers (organizations that want to evaluate quality measures) and Producer (organizations that deliver care to patients) are triggered by use case specific clinical or administrative events such as the completion of a Medication Reconciliation or a request from a Payer for the attestation information. Note that triggering is implementation specific and out of scope for this IG. This Implementation Guide (IG) describes three methods of exchanging data quality information using a set of FHIR operations that provide the framework to exchange CQM data:

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

FHIR operations allows the implementation to be viewed as a ‘black box’ free to decide how to satisfy the query - “give me the data of interest for a measure” - without requiring generic FHIR search functionality.

Profiles

The following resources are used in all data exchange transactions:

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:

Data Exchange

Submit Data operation

The Submit Data operation allows a Producer 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 Consumer’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 Consumer to evaluate the measure.

Gather Data Requirements From Consumer

In this step, the Producer queries a common knowledge store for profiles needed for reporting a given measure and how the sending of those data should be initiated. Common data profiles have been developed through a multi-stakeholder consensus-based development process and will be made available from the common site. To support the Submit Data operation, an implementation needs to know specifically what data are required 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 and it is automated by using the Data Requirements operation. These profiles are subsequently referenced in the MeasureReport.evaluatedResources element when submitting the measure data to the Consumer.

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

Click Here To See 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":"http://hl7.org/fhir/us/hedis/Library/library-mrp-logic"
         }
      }
   ],
   "dataRequirement":[
      {
         "type":"MeasureReport",
         "profile":[
            "http://hl7.org/fhir/us/davinci-deqm/STU3/StructureDefinition/measurereport-deqm"
         ]
      },
      {
         "type":"Patient",
         "profile":[
            "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-patient"
         ]
      },
      {
         "type":"Encounter",
         "profile":[
            "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-encounter"
         ]
      },
      {
         "type":"Location",
         "profile":[
            "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-location"
         ]
      },
      {
         "type":"Task",
         "profile":[
            "http://ncqa.org/fhir/us/hedis/StructureDefinition/hedis-task"
         ]
      },
      {
         "type":"Organization",
         "profile":[
            "http://hl7.org/fhir/us/davinci-deqm/STU3/StructureDefinition/organization-deqm"
         ]
      },
      {
         "type":"Practitioner",
         "profile":[
            "http://hl7.org/fhir/us/davinci-deqm/STU3/StructureDefinition/practitioner-deqm"
         ]
      }
   ]
}

Submit Data Operation

Once the Producer 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 Consumer. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population. The Consumer simply accepts the submitted data and there is no expectation that the Consumer will actually evaluate the quality measure in response to every Submit Data. In addition, the Submit Data operation does not provide for analytics or feedback on the submitted 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 Producer:

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

Click Here To See Example Submit Data Operation (edited for brevity)

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

For a complete un-edited example see the MRP Submit Data Operation example.

Collect Data operation

In this scenario, the Consumer initiates a Collect Data operation to gather any available CQM data for a particular measure from the Producer. In response to the operation, the Producer 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 CQM data (i.e. resources) are required is done through the Data Requirements operation on a Consumer’s measure endpoint and the returned resources and profiles are referenced in the MeasureReport.evaluatedResources element.

Collect Data Operation

The Consumer uses a Collect Data operation to request any available relevant data for the evaluation of a particular measure from a Producer. 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 Producer 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 Producer 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 Consumer :

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

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

Click Here To See 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",
        ...}
      },

    ]
 }

For a complete un-edited example see the COL Collect Data Operation example.

Data Requirements Operation

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

Subscriptions

FHIR Subscriptions allow for a Producer to notify the Consumer whenever new CQM data is available. Effectively, the Consumer subscribes to the Producer’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 CQM, 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.

The Consumer uses the Collect Data operation described above to request the relevant data after it is notified.

Subscribe for Measure Data

The Consumer must first subscribe to the Producer for a notification for a particular measure. The Consumer may subsequently 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 Consumer SHALL use the standard FHIR Subscription API as follows:

POST [base]/Subscription

To unsubscribe:

Delete [base]/Subscription/[id]

Click Here To See Example Subscription Transaction

<?xml version="1.0" encoding="UTF-8"?>
<Subscription xmlns="http://hl7.org/fhir">
 <id value="col-example"/>
  <!--  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="HEDIS Colorectal Cancer Screening Data"/>
  <criteria value="Measure/measure-col"/>
  <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 Producer notifies the Consumer 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]

Click Here To See Example Subscription Notification

Collect Data Operation

Upon notification, the Consumer uses the Collect Data operation to request the CQM data from the notifying Producer. This operation is discussed in the section above.