FHIR Chat · MRP - Bundle vs. Operation · Da Vinci

Stream: Da Vinci

Topic: MRP - Bundle vs. Operation

Danielle Friend (Jun 22 2018 at 18:17):

We're working on how to exchange the data we need for 30 day med reconciliation.

The resources needed for 30 day medication reconciliation: 
- MeasureReport
- Patient (patient med rec is for)
- Task (Attestation that med rec occurred)
- Practitioner (provider who performed med rec)
- Coverage (patient's coverage, needed for subscriber ID)
- Organization (organization provider is attesting on behalf of)
- Encounter (Optional - Encounter med rec occurred during)
- Location (Location where med rec occurred)

Desired workflow: EHR POSTs all above resources (fully expanded - not references) to the Payer.

We're struggling to determine the best FHIR mechanism to do this with.

Danielle Friend (Jun 22 2018 at 18:18):

Option 1: POST Bundle (profiled for MRP)
Example: Bundle.json
Questions:
1. What is the type of bundle?
2. How do you denote that this is data to communicate to the payer, but we don't want them to POST/Create the resources themselves?

Option 2: POST $MRP (specific operation)
Example: Operation.json
Question:
1. Can you have relative URLs in a Operation?

Danielle Friend (Jun 22 2018 at 18:19):

This is coming from our discussion at the Da Vinci meeting. @Emma Jones @Kevin Lambert @Michelle (Moseman) Miller @Linda Michaelsen @Viet Nguyen @Michael Brady @Nikolai Schwertner @Tony Benson

Danielle Friend (Jun 22 2018 at 18:20):

@Lloyd McKenzie @Eric Haas help us :)

Lloyd McKenzie (Jun 22 2018 at 18:43):

You'd have to post a Bundle to an operation endpoint if you were going to post a Bundle. We can define a profile on the Bundle that describes what it should contain and I sort of like that a bit better, but it makes the behavior of the operation in terms of inbound arguments a bit more opaque and harder to evaluate differences between one payer's implementation and another. For example, if one payer says location is mandatory and one says it's optional, having that embedded in the Bundle cascade of profiles is going to be ugly to figure out at runtime. As a result, I'm going to say "Use parameters". We haven't talked about cross-parameter references. I'll ask Grahame in a sec.

Lloyd McKenzie (Jun 22 2018 at 18:46):

Only downside is that it would look different from how the data would come back if you were to do a subscription and then subsequently query for the task with includes - in that case, there'd be no parameters involved. You'd get back a bundle of Tasks and whatever other resources were referenced by that page worth of tasks.

Lloyd McKenzie (Jun 22 2018 at 18:46):

(If you want to send me an urgent ping in the future - use Skype :))

Danielle Friend (Jun 22 2018 at 18:54):

That makes sense - we were leaning operation/parameters as well, so good to hear we're on the right wave length. Let us know about the cross-parameter references.

Danielle Friend (Jun 22 2018 at 18:54):

And it wasn't too urgent.. you are pretty quick on here too!

Lloyd McKenzie (Jun 22 2018 at 18:57):

Cross-parameter references are legal. They'd need to be local references

Lloyd McKenzie (Jun 22 2018 at 19:09):

A couple of issues came up from the discussion. #GF17405, #GF17406

Eric Haas (Jun 22 2018 at 19:17):

I am unclear how this operation is different from a standard FHIR transaction? You Post to the fhir endpoint a bundle and store all the resources in there respective endpoints and return an operationOutcome. What value does the operation add?

Lloyd McKenzie (Jun 22 2018 at 19:24):

You're not asking to store information at a RESTful endpoint. With transaction, you'd be saying either "create" or "update" each resource

Lloyd McKenzie (Jun 22 2018 at 19:25):

And that won't make sense when, in most cases, the payor won't have exposed endpoints for any of these

Lloyd McKenzie (Jun 22 2018 at 19:27):

Also, we want the payors to be able to say "No, you didn't give us enough information to process this '30 MedRec confirmation'". That would be an odd thing to extract out of processing an "add task".

Eric Haas (Jun 22 2018 at 19:34):

I don't understand the use case then. How is the data exchanged?

actors: EHR, Payor
EHR has the data, Payor wants the data
EHR send an unsolicited data to the Payor

What is the EHR sending to if not a FHIR endpoint?
IF the Payer does not have the endpoints - send them a sms!

What are the preconditions and assumptions?

Eric Haas (Jun 22 2018 at 19:36):

I think that if the Payer has no fhir endpoints that is out of scope

Danielle Friend (Jun 22 2018 at 19:36):

The EHR knows when medication reconciliation happens. The EHR knows the patient, the latest coverage information the patient told us, etc. The Payer knows the patient (by subscriber ID), the payer knows the coverage information, etc. So the EHR isn't trying to create the patient or the coverage resources in the payer's system, they already have all the information they need. They just need those resources to find the right patient, etc in their system.

Danielle Friend (Jun 22 2018 at 19:37):

The payer ideally should expose one endpoint to which the EHR can say "med rec has occurred". Oh by the way in order to understand what "med rec has occurred" means, here is all the supporting information you care about (patient, coverage identifiers, where it happened, etc).

Eric Haas (Jun 22 2018 at 19:38):

Got it, thanks :-)

Eric Haas (Jun 22 2018 at 19:38):

But that doesn't not exclude the payer from storing the data on there end... right

Eric Haas (Jun 22 2018 at 19:39):

for logging and internal auditing purposes....

Lloyd McKenzie (Jun 22 2018 at 19:44):

EHR will post a Parameters instance to "[endpoint]/Task$medrec" or something like that. The payor will extract the specific data elements from the passed resources and throw away the rest.

Eric Haas (Jun 22 2018 at 19:45):

why Task and not MeasureReport or just the system?

Lloyd McKenzie (Jun 22 2018 at 19:55):

Hmmm. I have DevDays brain. I'm now re-thinking the choice of breaking everything into parameters. Because we don't want a Medrec-specific operation.

Lloyd McKenzie (Jun 22 2018 at 19:57):

MeasureReport/[id for medrec]/$submitData and just passing a Bundle might make more sense. I think we need a discussion about what's the best way for payors to describe their different expectations for data submission for various measures. @Bryn Rhodes, thoughts on how this should be done?

Bryn Rhodes (Jun 22 2018 at 20:33):

Measure/measure-mrp/$submit-data on the processing system, and passing a Bundle, yes, and it would be the same Bundle that you would get if you invoked Measure/measure-mrp/$collect-data on the provider system.

Lloyd McKenzie (Jun 22 2018 at 20:40):

@Bryn Rhodes, the question is "how does a payor expose through its conformance statement its expectations on data included in the Bundle - because my preseumption is that there will be a degree of variation between payers - at least for some measures.

Bryn Rhodes (Jun 22 2018 at 20:46):

The way that happens with Measures now is through the $data-requirements operation for a Measure.

Bryn Rhodes (Jun 22 2018 at 21:29):

So you'd have a profile for each resource, and then the data requirements would specify that profile. Those resource-specific profiles are derived from US-Core, though, right?

Lloyd McKenzie (Jun 22 2018 at 21:45):

You're referring to a number of operations in the present tense that I don't actually see in the spec...

Bryn Rhodes (Jun 22 2018 at 21:58):

$collect-data isn't defined yet (there's an approved tracker I need to apply) but it looks the same as $evaluate-measure. And $data-requirements is there, it's just on Measure, not MeasureReport.

Bryn Rhodes (Jun 22 2018 at 21:58):

$submit-data is then just the other direction of $collect-data

Nikolai Schwertner (Jun 25 2018 at 16:07):

If I understand correctly, we are back to a bundle based solution with a post to Measure/measure-mrp/$submit-data, correct? Does everyone agree with this approach?

Bryn Rhodes (Jun 25 2018 at 16:20):

That's my understanding, a Bundle with the first entry as the MeasureReport, referencing all the elements with the evaluatedResource element, and the rest of the Resources as entries in the Bundle.

Eric Haas (Jun 25 2018 at 16:33):

@Bryn Why must the bundle have order? Are we talking about a Document?

Eric Haas (Jun 25 2018 at 16:35):

Seems like extra profiling for minimal gain to me.

Bryn Rhodes (Jun 25 2018 at 17:02):

It's not order, it's just that the first entry is a MeasureReport

Eric Haas (Jun 25 2018 at 22:01):

in JSON there is no order so it could be the 1st or 5th right?

Bryn Rhodes (Jun 25 2018 at 22:09):

There is no order in JSON elements, but there is definitely order in JSON arrays.

Bryn Rhodes (Jun 25 2018 at 22:10):

I don't feel strongly about it, it just seems useful to be able to rely on the fact that the first entry in the bundle is a MeasureReport, for the same reason that it's useful to be able to rely on the fact that the first entry in a document bundle is a Composition. Also seems consistent with the approach to describing bundles like this within FHIR.

Bryn Rhodes (Jun 25 2018 at 22:11):

But if it's a significant pain for authors or implementers, it's probably fine to leave it unspecified.

Eric Haas (Jun 25 2018 at 22:40):

OK I'm trying to understand this a little better so we can document this in the IG:

• Operation for providers pushing the Bundle of resources from the payers
  * Measure/measure-mrp/$submit-data

• Operation for payers fetching the Bundle of resources from the providers

  • Measure/measure-mrp/$collect-data

Questions:

• Why is it to a Measure and not MeasureReport operation endpoint ?
• "it looks the same as $evaluate-measure." but this operation returns a MR resource and not a Bundle
• (here is me six steps behind Lloyd in getting it...) how do we define whats in the bundle?

The providers need to get the list of resources that they need to collect in the Bundle to POST to the payer:

• via operation parameters - Lloyd's first choice

• via another operation like $data-requirements
  * Bryn said "And $data-requirements is there, it's just on Measure, not MeasureReport." - but there is no mention of Measure in the operation only Library and ActivityDefinition. - did you mean instead of ActivityDefinition use MeasureReport
  * My preferred option: It would be as lot simpler to just return the list of required resources as output parameters directly instead of Libary - we already have the graph defined.

• How does this information get used by the providers (is this out of scope?)

Bryn Rhodes (Jun 25 2018 at 23:33):

The $data-requirements operation would be used if we wanted to determine the set of requirements at run-time.

Bryn Rhodes (Jun 25 2018 at 23:35):

$data-requirements are specified as an operation on the Measure so you can use them to get a list of what data is needed.

Bryn Rhodes (Jun 25 2018 at 23:35):

Based on the CQL in the measure.

Bryn Rhodes (Jun 25 2018 at 23:36):

We want to define how it works in the general case, but the actual implementation can be specific for this scenario.

Bryn Rhodes (Jun 25 2018 at 23:36):

So if you look at $data-requirements, it's just going to return a Library with a listing of DataRequirements.

Bryn Rhodes (Jun 25 2018 at 23:37):

So here's an example invocation:

Bryn Rhodes (Jun 25 2018 at 23:37):

http://measure.eval.kanvix.com/cqf-ruler/baseDstu3/Measure/measure-asf/$data-requirements

Bryn Rhodes (Jun 25 2018 at 23:40):

And actually, we have the one for mrp specified as well, though it's based on the old version of the MRP measure we used in Michigan:

Bryn Rhodes (Jun 25 2018 at 23:40):

http://measure.eval.kanvix.com/cqf-ruler/baseDstu3/Measure/measure-mrp/$data-requirements

Bryn Rhodes (Jun 25 2018 at 23:41):

So if we're ready to specify exactly what those data requirements are, we ought to be able to specify that pretty easily. Do we know what they are?

Eric Haas (Jun 26 2018 at 00:18):

They are a bunch of profiles

Bryn Rhodes (Jun 26 2018 at 00:31):

Will you send me a list?

Bryn Rhodes (Jun 26 2018 at 00:32):

Or point me to the draft build of the IG?

Eric Haas (Jun 26 2018 at 00:35):

working on it...

Bryn Rhodes (Jun 26 2018 at 01:28):

No worries, whenever is fine, thanks Eric!

Eric Haas (Jun 26 2018 at 06:09):

I don't get $submit-data:

• It does not seem much different than a RESTful batch transaction except the MeasureReport id triggers the payer about it.
• I guess we will need to create a bunch of error codes for the OO too.

Anyway here are the operations in the Draft IG

• There are two options for the get-measures - my simples get codes and the get-Library one.

@Nikolai Schwertner Are there notes from last week?

Bryn Rhodes (Jun 27 2018 at 09:44):

Okay, given that set of profiles, here's what the result of $data-requirements would look like: mrp-datarequirements.json

Eric Haas (Jun 27 2018 at 16:42):

We are trying to divine what is the general case and what is for only MRP.
I tried to profile and created operations for both use cases. MRP I think it clear. Need to know which of these are possible to create the general:

• MeasureReport Profile
  *Task Measure Profile ( assume that there is pattern to the MRP graph that can be reused)

• Observation Measure Profile ( assume that there is pattern to the MRP graph * that can be reused)

• Measure (leaving that to you anyway :-))

• $submit-data, $collect-data ( can we have a single operation for reuse among measure or need one per measure e.g. a MRP submit-data operation, an XYZ submit-data operation... they don't profile in the current tooling so I would not try to constrain them for each use case rather create de-novo)

I think we are not that interested in the data-req for MRP after talking to Viet. It looks like the intent is to lock them down in the IG. So focus should be on the $submit-data

Will talk later this week

Nikolai Schwertner (Jun 27 2018 at 21:33):

Here are a couple snaps from the meeting whiteboards:
IMG_7913.JPG IMG_7914.JPG IMG_7912.JPG IMG_7910.JPG

Last updated: Apr 12 2022 at 19:14 UTC