FHIR Chat · 30 Day Med Rec Post-Discharge (MPR) - Resources · Da Vinci

Stream: Da Vinci

Topic: 30 Day Med Rec Post-Discharge (MPR) - Resources


view this post on Zulip Viet Nguyen (May 23 2018 at 17:47):

At our Cleveland technical working meeting, the MRP use case group identified the US-Core Procedure profile as an appropriate resource to use in the MRP attestation for the following reasons:

1. It supported references to other required information and resources - us-core Patient, Practitioner, Organization and Location
2. This resource was implemented by the major EHR which facilitates early adoption
3. Procedure's code element supports CPT from which the code 1111F which is used today as a billing code indicating that provider has performed the MRP. It could also support a code from Value Set for Medication Reconciliation from NCQA

There was a suggestion by @Hans Buitendijk to use the Observation resource.
There was also a suggestion by @Lloyd McKenzie that Task may be a better resource.

In this topic stream, we will discuss the pros and cons of each approach.

view this post on Zulip Lloyd McKenzie (May 23 2018 at 18:03):

My rationale for Task is as follows:
- the fact a reconciliation has occurred behaves like a checkbox on a task list. It's something that's assigned and eventually done. We're not dealing with the assigning/requesitng piece yet, but we may eventually
- this is not a procedure that was done on the patient. It's not something we'd want listed alongside their surgeries, training, physio-therapy, etc. It's an administrative action, not a Procedure as defined by the scope of the Procedure resource. (Nor would we want it listed beside vitals, lab results, assessments, etc. as an Observation)
- Task makes it easy to point to the original medication list (the discharge medications) and the resulting medication list using the input and output elements if we wanted to
- Task is the resource we would use to contain other "to dos" we'd want practitioners to look at - e.g. "please renew prescription XYZ", "please review lab result 123", "please cancel order abc"
- It's true that argonaut hasn't implemented Task yet, but that's because they've focused on resources that a primary part of the patient's clinical record. They haven't dealt with sharing administrative information. They'd be able to share the reconciled med list, but not that "reconciliation was requested" or "reconciliation occurred".
- Task captures the necessary elements including what was done, what encounter it was done for, who did it, when, etc.
- Task.code can capture CPT codes too if that's what we decide to standardize on. None of the resources have any constraints on what terminologies can be used
- We've indicated that we want to identify the "proper" resource for R4 and then back-track as necessary for previous versions or to reflect limitations of what systems are willing to do. It seems pretty clear to me that Task is the "proper" resource.

view this post on Zulip Linda (May 23 2018 at 18:18):

Your explanation makes perfect sense to me. A couple of questions a) Is there a way to reference location? Part of the discussion in Cleveland is that for audit, the payer would need to know the "location" of the medical record. b) If we have to support DSTU2 because that is the version the EMR's are implementation, how would we do that with Task since that resource didn't exist there?

view this post on Zulip Eric Haas (May 23 2018 at 18:19):

Agree with Lloyds comments and wanted to address the point that most EHRs support Argonaut (DSTU2) and USCore(STU3). These profiles were created to meet MU2015 Common Clinical Data Elements ( CCDS ) and so I think the approach of trying to limit ourselves to these resources for a totally separate Da Vinci use case is problematic.

view this post on Zulip Lloyd McKenzie (May 23 2018 at 18:24):

@Linda - Record location of what? The reconciled med list? We could point directly to the List (though argonaut hasn't chosen to go that route yet) or we could point to a DocumentReference that provided a more 'virtual' location. Or we could just have a named output parameter that was a URL or even a string description

view this post on Zulip Lloyd McKenzie (May 23 2018 at 18:25):

In terms of STU2 support, I think the intention is to nail down the specific requirements for R4 and then figure out the "best" way to implement in STU2 with advice from the EMRs on how they'd like to make it happen

view this post on Zulip Eric Haas (May 23 2018 at 18:25):

I think the question of versions is complicated and drives our ultimate approach. The analog of Task in DSTU2 is Order/OrderResponse which I have not looked at in while.

view this post on Zulip Viet Nguyen (May 23 2018 at 18:32):

@Lloyd McKenzie The location is used to designate that the reconciliation was done in the outpatient setting, as opposed to hospital, inpatient. A provider may work in both and in fact may be (but doesn't have to be) the same prescriber who wrote the discharge medication list and saw the patient at the outpatient follow-up and performs the reconciliation.

view this post on Zulip Lloyd McKenzie (May 23 2018 at 21:37):

When Task gets updated to reflect the current Event and Request patterns, it'll get a 'location' element to indicate where the Task occurred, so that'll be supported in R4

view this post on Zulip Hans Buitendijk (May 23 2018 at 21:55):

Based on discussions to date, the question to look not only at Procedure, but Observation as well/instead is effectively being expanded to Encounter and List as we define the framework discussed in Cologne. Different solutions/approaches may map best to Procedure (using CPT perhaps) or Observation (using SNOMED perhaps) or Encounter (using a flap perhaps) or a List (using status/presence perhaps). Others may have used an approach that uses another resource. Each of these can be aggregated towards a measure without having to first map everything to one resource (e.g., Procedure) as that would create unnatural/unnecessary transformations. I am looking forward to further discussion on how we address that further in the proposed framework.

view this post on Zulip Lloyd McKenzie (May 23 2018 at 22:11):

If we're looking at gathering arbitary information for arbitrary measures, then we could be bringing back absolutely any of the clinical resources, and potentially some of the others too. However, the answer to the specific question of "has medication reconciliation been done" should still be Task.

view this post on Zulip Eric Haas (May 23 2018 at 22:11):

Lloyd types quicker than I :-)

view this post on Zulip Gini McGlothin (May 24 2018 at 19:47):

The "location" I think Linda is referring to, and the location that matters to me as a payer/ measure SME is the physical location where a hard copy medical record that shows the medication reconciliation was done exists. So if this provider saw the member in the hospital but also outpatient, I need to know the location of the outpatient practice in the event my auditor wanted to see a hard copy record. He is not looking for any electronic trail of the discharge meds list, etc, he wants a hard copy medical record, so I need to know which location to call and get that record. The fact that the medication reconciliation was done in an inpatient setting doesn't necessarily disqualify it from meeting the measure specs for compliance, but the documentation it was done MUST be in the outpatient record. I know this sense of the "physical location of a hard copy medical record" gets fuzzy for our health systems that use the same EHR in the inpatient and outpatient settings, so I hope that was clear.

view this post on Zulip Josh Mandel (May 25 2018 at 14:56):

I think I may not have context on the overall use case here. Is there a write-up?

view this post on Zulip Lloyd McKenzie (May 25 2018 at 18:22):

Probably somewhere :) @Viet Nguyen ? The short version of the original use-case was "When a medication reconciliation has been completed, if the reconciliation is relevant under the "30 day medication reconciliation" rule based on past recent admission, the EMR will send a notification to the relevant provider. " That's since been broadened to "When information has been collected that's relevant to a particular quality measure, that information will be forwarded to the aggregator responsible for calculating that quality measure". The trick is that different EMRs (and even different instances of the same EMR) may have small or large differences in how they represent the measure information internally. My proposal is to use CDS Hooks to bridge that gap. The hooks would link into the workflow and query data as relevant for that EMR and would generate 'standard' notifications for the aggregators

view this post on Zulip Josh Mandel (May 26 2018 at 03:04):

How are any of the involved parties supposed to know which counterparties to notify for data pertinent to a specific measure on a specific patient?

view this post on Zulip Lloyd McKenzie (May 27 2018 at 05:13):

It would be through the association of the patient on whom the medrec was done with a particular Coverage which in turn was associated with a particular payor organization.

view this post on Zulip Eric Haas (Jun 06 2018 at 22:31):

There are two location that can be referenced in R4

The FHIR event pattern has a ref to Location "The principal physical location where the event was performed."
The PractitionerRole has a ref to Location "The location(s) at which this practitioner provides care."

I think that depending on the Event resource (Observation (as an extension)|Task|Procedure) both would answer the question "the physical location where a hard copy medical record that shows the medication reconciliation was done"

view this post on Zulip Lloyd McKenzie (Jun 06 2018 at 22:38):

Task.location would be 0..1. PractitionerRole.location could list 3 different clinics - and in some cases where they were when they actually did the work (e.g. as a locum) might not be any of those.


Last updated: Apr 12 2022 at 19:14 UTC