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 (HL7® FHIR® Standard) R3. The current version which supersedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Medication Reconciliation Process

• Introduction
  • Summary MRP Technical Workflow
• FHIR Resource Overview
• MRP FHIR Transactions:
  • Gather Data Requirements From Payer
  • Submit Data to Payer

Introduction

The Medication Reconciliation Use Case defines the process by which a message can be sent from a provider EHR to a Payer attesting that a medication reconciliation post-discharge was performed on a covered member. This attestation message can then be used by the payer to show compliance for the HEDIS measure Medication Reconciliation Post-Discharge. (Any necessary documentation will also be put in the record)

In the case of medication reconciliation after discharge from the hospital, the patient’s discharge medication(s) is compared with the medication(s) the patient was taking prior to hospitalization. This can avoid medication errors such as omissions, duplications, dosing errors or drug interactions, and should be done at every transition of care in which new medications are ordered or existing orders are rewritten.

In the past, attestation to the reconciliation had been done by posting a CPT2 code on a claim typically for a small monetary amount that was then denied by the payer and had to be written off by the provider. This is a cumbersome process and most providers are no longer doing this.

Payers and providers need common standards to share the data required to complete medication reconciliation at all transitions of care, for care management plans, and during medication changes. Proof of 30 day medication reconciliations is increasingly required for value based care incentives.  Providers and care coordinators face the challenge of collecting accurate and complete patient medication records across care settings. Today’s manual and ad hoc processes are costly and will not scale. Vendors are actively leveraging FHIR resources to improve partner’s access to patient medication history by unlocking existing silos of this critical data from vendor systems, healthcare operations systems and provider EHRs.

As an HL7 FHIR Implementation Guide, changes to this specification are managed by the sponsoring workgroup, Clinical Quality Information, and incorporated as part of the standard balloting process. The current roadmap follows closely behind the base FHIR roadmap, and QI Core Implementation Guide.

Exchange of the reconciled medication list, indication of conversations with the patient, and notification of discharge from inpatient systems are out of scope for this version of the use case.

Summary MRP Technical Workflow

The technical Workflow is outlined in the following figure. The parts outlined in red are the actual FHIR transactions that are the focus of this Guide and are described in detail in the following sections:

Summary of FHIR Artifacts used for Medication Reconciliation

FHIR Resource Overview

Resources supported for this use case:

MRP FHIR Transactions:

Gather Data Requirements From Payer

In this optional step, the Provider queries the Payer(“Aggregator”) for which resources are needed for MRP measure reporting. Note that instead of using this API, the measure definition can be reviewed manually to determine what data needs to be submitted.

APIs

These 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

Using either the GET and POST Syntax the operation can be invoked as follows:

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

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 to Payer

Submit Data to a Payer’s Measure endpoint

Provider will use the Submit Data operation to submit a MeasureReport and the referenced resources required by the payers as supporting evidence to provide the MRP attestation to the payer. (Note that the Collect Data and Subscription Operations are not supported for this use case.) For MRP the Provider may submit either a Task resource or an Observation resource as the primary resource used to evaluate the measure.

Graph of MRP resources:

APIs

These 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. DEQM Coverage Profile
3. QI Core Encounter Profile
4. QI Core Location Profile
5. HEDIS MRP Measure Profile
6. DEQM MeasureReport Profile
7. DEQM Organization Profile
8. QI Core Patient Profile
9. DEQM Practitioner Profile
10. HEDIS MRP Task Profile or HEDIS MRP Observation Profile

Usage

A provider POSTs the MRP resources to the payer using:

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

Example Submit Data operation using Task option

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

Example Submit Data operation using Observation option

{
   "resourceType":"Parameters",
   "parameter":[
      {
         "name":"measurereport",
         "resource":"{"resourceType": "MeasureReport",
         ...}
      },
      {
        "name":"resource",
        "resource":"{"resourceType": "observation",
        ...}
      },
      {
        "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",
        ...}
      },

    ]
 }

HTTP/1.1 200 OK
[other headers]