Data Exchange For Quality Measures STU2 for FHIR R4 Implementation Guide CI Build

Data Exchange For Quality Measures STU2 for FHIR R4, published by HL7 International - Clinical Quality Information Work Group. This is not an authorized publication; it is the continuous build for version 1.1.1). This version is based on the current content of https://github.com/HL7/davinci-deqm/ and changes regularly. See the Directory of published versions

Data Exchange Interactions

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 Producers (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 although triggering is implementation specific and out of scope for this IG, there are a variety of potential triggering points for reporting events within clinical systems. These include:

and there will be a need to convey triggering information in a computable way to EHRs and other clinical systems.

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

This project recognizes the impact of the Argonaut Clinical Data Subscriptions project which is working on event based subscriptions and major revisions to the Subscription resource for FHIR R5. In a future version this guide, a subscription based exchange is planned and will align with the outcomes of the Argonaut project.

FHIR operations allow 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:

Resource Type Profile Name Link to Profile
Library CQFM Library Profile CQFM Library
Measure CQFM Measure Profile CQFM Measure
MeasureReport DEQM Data Exchange MeasureReport Profile DEQM Data Exchange MeasureReport Profile
Organization DEQM Organization Profile DEQM Organization
Patient QI Core Patient Profile QI Core Patient

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

The DEQM resources form a network through their relationships with each other - either through a direct reference to another resource or through a chain of intermediate references. These groups of resources are referred to as resources graphs. The DEQM data exchange resource graph is shown in Figure 2-1:

Figure 2-1 DEQM Resource Graph
measure-resource-graph.svg


Data Exchange

Submit Data operation

The Submit Data operation allows a Producer to submit data-of-interest for a particular quality measure within the specified time window when the data is ready. 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. Note that resources included in a Submit-Data bundle SHOULD be self-contained (in other words, should include all referenced resources in the data), unless the exchange is understood by both parties to be incremental. For example, if an Encounter references a Location, that Location is expected to be included in the bundle, unless the exchange is understood to be incremental and the sending system knows that it has already sent that particular Location as part of a previous submit.

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. In cases where reporting requirements are not known, the data would not be submitted until the correct measure and version is known.

Figure 2-2 Submit Data Steps
mrp-wf-overview.jpg

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.

Figure 2-3 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 operation
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.

Example

Scenario

Provider X acting in the role of the Producer requests data requirements for the MRP measure from Payer Z which is acting in the role of Consumer. A 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",
  "id": "library-mrp-example",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: library-mrp-example</p><p><b>url</b>: <a href=\"http://hl7.org/fhir/us/davinci-deqm/Library/library-mrp-example\">http://hl7.org/fhir/us/davinci-deqm/Library/library-mrp-example</a></p><p><b>version</b>: 1.1.1</p><p><b>name</b>: DEQMLibraryMRPExample</p><p><b>title</b>: DEQM Library MRP Example</p><p><b>status</b>: active</p><p><b>type</b>: module-definition <span style=\"background: LightGoldenRodYellow\">(Details : {[not stated] code 'module-definition' = 'module-definition)</span></p><p><b>date</b>: Feb 15, 2020, 1:42:10 AM</p><p><b>description</b>: Example Library resource to demonstrate the framework for MRP</p><p><b>jurisdiction</b>: United States of America <span style=\"background: LightGoldenRodYellow\">(Details : {urn:iso:std:iso:3166 code 'US' = 'United States of America', given as 'United States of America'})</span></p><p><b>dataRequirement</b>: , , , , , , </p></div>"
  },
  "url": "http://hl7.org/fhir/us/davinci-deqm/Library/library-mrp-example",
  "version": "1.1.1",
  "name": "DEQMLibraryMRPExample",
  "title": "DEQM Library MRP Example",
  "status": "active",
  "type": {
    "coding": [
      {
        "code": "module-definition"
      }
    ]
  },
  "date": "2020-02-15T01:42:10+00:00",
  "description": "Example Library resource to demonstrate the framework for MRP",
  "jurisdiction": [
    {
      "coding": [
        {
          "system": "urn:iso:std:iso:3166",
          "code": "US",
          "display": "United States of America"
        }
      ]
    }
  ],
  "dataRequirement": [
    {
      "type": "MeasureReport",
      "profile": [
        "http://hl7.org/fhir/us/davinci-deqm/StructureDefinition/datax-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://hl7.org/fhir/us/qicore/StructureDefinition/qicore-task"
      ]
    },
    {
      "type": "Organization",
      "profile": [
        "http://hl7.org/fhir/us/davinci-deqm/StructureDefinition/organization-deqm"
      ]
    },
    {
      "type": "Practitioner",
      "profile": [
        "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-practitioner"
      ]
    }
  ]
}

For another example see the COL Data Requirements Operation example.

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.

Figure 2-4 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
  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

Examples

Scenario:

Provider X acting in the role of Producer submits MRP data for Patient Y to Payer Z who is acting in the role of Consumer. 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]

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

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. It is assumed that the Producer knows the data requirements for 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.

Figure 2-5 Collect Data Steps
collect-data-steps.jpg

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.

Figure 2-6 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
  2. Various DEQM and QI Core Profiles depending on the specific Measure

Usage

Collect Data:

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

Examples

Scenario:

Payer Z acting in the role of the Consumer collect Patient Z’s MRP data from Provider X which is acting in role of the Producer

Request using GET Syntax

GET [base]/MeasureReport/measure-mrp/$collect-data?subject=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":"subject",
         "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",
        ...}
      },

    ]
 }

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

Submit Data and Collect Data for Multiple Patients

Submit Data Operation Request for Multiple Patients

The transaction bundle processing as defined by FHIR specification is used for transacting the body of Submit Data operation request for multiple patients in a single interaction.

  • The transaction bundle contains an entry for each patient as illustrated in the examples below:
    • The fullUrl is a UUID (urn:uuid:...).
    • The resource is a Parameters resource as defined in the operation.
    • The request method is POST
    • The request url is the operation endpoint Measure/$submit-data or Measure/[measure-id]/$submit-data.
  • When resolving references, references are never resolved outside the Parameters resource. Specifically, resolution stops at the elements Parameters.parameter.resource.”
  • The matching transaction response is returned by the operation endpoint server.
POST|[base]

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "urn:uuid:79378cb8-8f58-48e8-a5e8-60ac2755b674",
      "resource": {
        "resourceType": "Parameters",
        "parameter": [
          {
            "name": "measurereport",
            "resource": {
              "resourceType": "MeasureReport",
              ...,
            "name": "resource",
            "resource": {
              "resourceType": "Patient",
              ...,
            [other "resource" parameters]
          ]
        },
        "request": {
          "method": "POST",
          "url": "Measure/[measure-id]/$submit-data"
            }
            ....

Collect Data Operation Response for Multiple Patients

Because operations are typically executed synchronously, a collect data request to a server returns a Parameter resource for a single patient as defined by the $collect-data operation. Execution of this operation and returning multiple patients in a single asynchronous transaction is outside the scope of this guide.