FHIR Chat · Call Recaps · CARIN IG for Blue Button®

Stream: CARIN IG for Blue Button®

Topic: Call Recaps

Mark Roberts (Feb 25 2020 at 21:07):

CARIN Health Plan 021720 Call Recap: http://bit.ly/021720CARIN

Mark Roberts (Mar 02 2020 at 18:41):

Hi all, CARIN Health Plan call recaps will be located in this thread. These recaps capture discussions that occur during our Monday 2:30-3:30 pm ET calls. These calls have been focused on the development and refinement of the CPCDS IG. Now that the IG has been approved, these calls will convert to Ballot Reconciliation calls for the CARIN CPCDS IG. These calls will continue to take place on Monday between 2:30-3:30 pm ET.

If you are interested in participating, please join from PC, Mac, Linux, iOS or Android: https://leavittpartners.zoom.us/j/461256971 or Dial: 1 646 876 9923 // Meeting ID: 461 256 971

Mark Roberts (Mar 02 2020 at 18:42):

CARIN Health Plan 022420 Call Recap: http://bit.ly/022420CARIN

Michele Mottini (Jun 18 2020 at 23:14):

A server will always treat an EOB search request as if a client indicated "_include=*" and SHALL return all EOB & reference resources in the response bundle

Seriously? Server should always return data that the client did not request? What for?

Josh Mandel (Jun 18 2020 at 23:16):

Yeah, rules like this are not an appropriate practice in my view.

Josh Mandel (Jun 18 2020 at 23:17):

Clients can be expected to provide queries reflecting their needs; implicitly inferring more is 1) risking over-share, and 2) gratuitously breaking interoperability with standard server behavior

MaryKay McDaniel (Jun 19 2020 at 00:20):

Simply put, it's better for the patient/beneficiary/caregiver receiving and viewing the informtion and cuts down on FWA calls when the information is out of sync.

Josh Mandel (Jun 19 2020 at 00:22):

Help me understand this though: clients can pass along these parameters if needed, so I'm not sure I understand how this implicit behavior improves things.

MaryKay McDaniel (Jun 19 2020 at 16:05):

An EOB is created by the Payer, it is a document that includes ALL the pieces - FHIR happens to break it into separate resources. Anytime someone wants an EOB - they should get all the pieces together.

Michele Mottini (Jun 19 2020 at 16:26):

. . . this is not the way FHIR is designed to work (as any other REST API) : the server makes data available and the client gets what it wants / needs

Michele Mottini (Jun 19 2020 at 16:27):

for example clients in most cases would not be interested in the patient demographics - so no point in returning that all the time

Josh Mandel (Jun 19 2020 at 17:31):

Precisely!

MaryKay McDaniel (Jun 19 2020 at 19:14):

Again, all the pieces (resources) constitute the EOB. Interestingly enough, many FWA cases are identified by the patient/beneficiary/caregiver by looking at information returned in the EOB that they don't recognize. The only way to ensure all the information for the EOB is all about that particular EOB on the day the EOB/claim was created is to send them all. This is how the business works today, and it works this way for a reason.

Josh Mandel (Jun 19 2020 at 19:53):

if this is a requirement, then we should be defining a custom operation that does the job ($assemle-eob or whatever). Bending the semantics of the existing fhir rest API is going to cause confusion and incompatibility.

Michele Mottini (Jun 19 2020 at 20:03):

And the actual existing Blue Button (the CMS one) for sure does not work like that - it works the normal way - you ask for ExplanationOfBennefit, you get only that resource

Paul Church (Jun 19 2020 at 20:12):

This IG has gone back and forth between
option A: the client makes a series of calls to FHIR standard REST APIs retrieving individual resources, offering a complex variety of search parameters, to interactively get what they want
option B: we define ExplanationOfBenefit/$everything, with support for _since and _type, and the client calls it once

I'd be fine with either (it's really the payors who are driving the discussion of what is feasible for them) but after so many iterations we now have a draft that tries to have it both ways at the same time.

MaryKay McDaniel (Jun 19 2020 at 20:26):

That sounds reasonable to me - but I hasten to add, I'm from the business side. @Amol Vyas @Pat Taylor @Paul Knapp Can we bring this to an FM call to discuss. I'm not sure it will be this Tuesday, we already have a fun-filled packed agenda.

Lee Surprenant (Jun 22 2020 at 14:19):

A tad off-topic but reading this great thread gave me this question: by _include=* we mean _include=<resourceType>:*, right?
So, for a search on the ExplanationOfBenefit endpoint that would be _include=ExplanationOfBenefit:*, and not _include=*, right?

Paul Knapp (Jun 22 2020 at 21:09):

Agree that: IGs should not be redefining standard FHIR operations, such as GET, for a specified resource or all resources; agree a custom operation is an efficient and appropriate means to ensure the server returns all of the time context appropriate supporting resources otherwise the server must deliver resources with correct versioning, which is tough without having the EOB-time context, and places additional burden on the server to support more endpoints and the client to query for teh right time-context versions of supporting resources; and, agree this should be discussed on an FM call, this or next week is this week is already full to overflowing.

Paul Knapp (Jun 22 2020 at 21:11):

@Lee Surprenant It would be "_include=*" but still doesn't identify the depth to which the resolution goes nor the reality that all references would need to be versioned or filtered to the correct time contexts.

Lee Surprenant (Jun 22 2020 at 21:17):

Paul Knapp said:

Lee Surprenant It would be "_include=*"...

Interesting, that doesn't match my reading of https://www.hl7.org/fhir/search.html#revinclude which says it should be 2 or 3 parts:

The name of the source resource from which the join comes
The name of the search parameter which must be of type reference
(Optional) A specific of type of target resource (for when the search parameter refers to multiple possible target types)

and that _include and _revinclude use the wild card "*" for the search parameter name (which I interpreted to be just the second part)

Lee Surprenant (Jun 22 2020 at 21:18):

I'll open jira for base spec on that

Paul Church (Jun 22 2020 at 21:18):

I'd never thought about it before, had always seen it referred to as _include=* but your reading makes more sense

Lee Surprenant (Jun 22 2020 at 21:19):

the first part is kind of dumb for _include values because its always the name of the resource type being searched...just dumb boilerplate

Lee Surprenant (Jun 22 2020 at 21:19):

but currently our server requires it

Paul Knapp (Jun 22 2020 at 21:19):

@Lee Surprenant Given that you don't know which resources are referenced in the EOB or supporting resources if you want ANY returned then you'd specify *.

Lee Surprenant (Jun 22 2020 at 21:22):

yeah, I think thats a good point for _revinclude

Lee Surprenant (Jun 22 2020 at 21:22):

you couldn't possibly populate the first component correctly if you wanted to say "all references to this resource from all resources types that reference it"

Paul Knapp (Jun 22 2020 at 21:23):

@Lee Surprenant For the include to return the correct data all of your resource references would need to be versioned, are they? - if not the automatic server behavior will eventually give the wrong data for this use case.

Lee Surprenant (Jun 22 2020 at 21:23):

but for _include, i think the spec is clear that it should match the resource type being searched. for example, consider this example from the spec:
GET [base]/MedicationRequest?_include=MedicationRequest:patient

Lee Surprenant (Jun 22 2020 at 21:27):

Paul Knapp said:

Lee Surprenant For the include to return the correct data all of your resource references would need to be versioned, are they? - if not the automatic server behavior will eventually give the wrong data for this use case.

I could probably use a deeper explanation of what you mean by this, but I'm not sure if this is the right thread...

Lee Surprenant (Jun 22 2020 at 21:35):

OK, I opened FHIR#27861 on the base spec for this

Paul Knapp (Jun 22 2020 at 21:35):

@Lee Surprenant Ignoring how one correctly specifies 'include all', the behavior of include follows the references in the resources - they will refer to and get the CURRENT resource versions not the ones in force at the time of the EOB, so your references would need to be versioned for the behavior to work, are yours always versioned?

Lee Surprenant (Jun 22 2020 at 21:38):

ok, that seems totally different to me. base spec says this about it: https://www.hl7.org/fhir/search.html#versions

If a resource has a reference that is versioned, and chaining is performed, the criteria should ideally be evaluated against the version referenced, but most systems will not be capable of this because search is only defined to function against the current version of a resource