HAPI FHIR $everything query does not support optional parameters

[michaelgriffithus]

HAPI FHIR does not support optional parameters of start end or type. Passing these parameters on the query string are ignored.

https://hapi.fhir.org/baseR4/Patient/1/$everything?_type=Observation Same behavior applies to start/end date parameters. It would be extremely helpful for our project to be able to bound $everything queries with start and end dates for clinical resources and filter by only resources we care about in our application (_type)

Expected behavior Respect the parameters being passed and limit the returned resource bundles based on these parameters.

Environment (please complete the following information):

• R4
• iOS/Linux
• Chrome Version 102.0.5005.61

[tadgh]

As I asked in the zulip thread, how would you like start and end translated? at the end of the day they must become search parameters. Does it make sense to you if we were to convert them to date= If not, do you know what defines the mapping between start/end and the actual resource search parameters?

[michaelgriffithus]

I'm not sure how the code is implemented, I do realize that each resource has a different name, which to me seems unfortunate. I would think it could be done something like this:

  switch (resourceType) {
        case 'Condition':
            result += `&date-recorded=ge${startDate}&date-recorded=le${endDate}`;
            break;
        case 'MedicationAdministration':
            result += `&effectivetime=ge${startDate}&effectivetime=le${endDate}`;
            break;
        case 'MedicationOrder':
            result += `&datewritten=ge${startDate}&datewritten=le${endDate}`;
            break;
        case 'Observation':
            result += `&dateissued=ge${startDate}&dateissued=le${endDate}`;
            break;
        default:
            result += `&date=ge${startDate}&date=le${endDate}`;
    }

[michaelgriffithus]

I'd like to point out (as I did on the ticket) that _type is not respected either. Try to limit query to a single or a few selected resourceTypes and you do get everything.

[tadgh]

Yup for sure, I've got that here 👍🏻. I'll have to go back to the group and do some noodling about how to perform the correct mapping for dates. I'll link a PR here when I get started on it

[michaelgriffithus]

Thank you! @tadgh

[tadgh]

OK, we're going to do the following:

1. Support _type.
2. kinda support start and end. We will be using _lastUpdated meta field to map from start and end. While this isn't ideal, this is all we can implement in short order.

[michaelgriffithus]

While the _type parameter will certainly help us, I don't think using _lastUpdated meets the spec. https://www.hl7.org/fhir/patient-operation-everything.html. The spec reads:

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.

I certainly think any other implementation would be confusing to other developers

[tadgh]

Heya Michael, thanks for the answer.

Sadly that just isn't tractable to implement quickly, and is rather non-trivial, especially based on our current db architecture.

If we were to implement the above mapping suggestion, we would effectively have to rewrite the entire everything operation, as it currently leverages _include:all. The requirement to support arbitrary SP filtering on a per-resource basis would require us to effectively execute n SQL queries, where n is the number of resource types involved.

Since you seem to have no interest in the _lastUpdated being used,(which would be a stopgap) I'll drop that for now, and just use this as an opportunity to add _type support.

If you are interested in submitting a pull request which makes start and end work the way you want them to, I would be happy to review it and push it through.

[michaelgriffithus]

@tadgh any idea on an ETA for the _type fix? That would be very beneficial for us. It looks like there might be another way to solve for this using "SearchParameter" https://chat.fhir.org/#narrow/stream/179167-hapi/topic/.24everything.20searches.20not.20respecting.20parameters

[tadgh]

No, I have no ETA. HAPI is only one of the things I work on, and I have more pressing work to do at the moment. There's a good chance I'll be able to get around to it this week though. If that doesn't work for you, HAPI-FHIR gladly accepts community PRs.

[michaelgriffithus]

@tadgh just looking for a rough idea, if it's something we can expect in a few weeks, I think that is helpful for our project. Thanks in advance, MG