$everything operation

[hrnagesh-zz]

Describe the bug A clear and concise description of what the bug is.

Get all resources for a patient using $everything operation fails and returns error.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

{baseURL}/Patient/{id}**/$everything

Expected behavior A clear and concise description of what you expected to happen.

It should return all associated resources for patient

Additional context returns below error

Add any other context about the problem here.
{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "fatal",
            "code": "exception",
            "details": {
                "text": "FHIROperationNotFoundException: Operation with name: 'everything:Patient' was not found"
            }
        }
    ]
}

[prb112]

@hrnagesh the conformance documentation and conformance statement elaborate on the supported FHIR Operations. https://ibm.github.io/FHIR/Conformance/#extended-operations. I'd kindly like to change this to a feature request rather than a bug.

[JohnTimm]

Agreed, this is an enhancement. Patient/$everything is an optional operation that has yet to be implemented.

[albertwang-ibm]

compartment search for one patient. a little bit similar to how we export patient resources of a size 1 group.

[JohnTimm]

@lmsurpre Can we reformat the operation name to something like Patient/$everything?

[lmsurpre]

I also think it would be good to add support for this operation. @hrnagesh, let us know if you'd like to try your hand at adding it.

We already have CompartmentUtil.getCompartmentResourceTypes and CompartmentUtil.getCompartmentResourceTypeInclusionCriteria, so I think it would be a matter of starting from one of the other fhir-operation-* modules and adapting it to:

1. get the resource types for the given compartment
2. for each resource type, get the "inclusion criteria" and invoke a corresponding search using FHIRRestHelper.doSearch (probably set a page size of 1000 first and either loop through all the pages or return a "too-costly" error if the total count exceeds this threshold)
3. put together all the results into one large result bundle

@lmsurpre Can we reformat the operation name to something like Patient/$everything?

we could, but then you'd need to change $validate to Resource/$validate or */$validate and then explain it actually applies to all resource types. in my opinion, the current approach of having a separate column for type is fine. and right above the table it says Type operations are invoked at [base]/[resourceType]/$[operation] ...seems pretty clear to me.

[JohnTimm]

everything:Patient is a non-standard, bi-product of our implementation and not as recognizable as $everything or Patient/$everything for someone looking back in the spec trying to figure out what went wrong. Resource/$validate or even */$validate doesn't bother me as much as everything:Patient. Perhaps we could use part of the original request URI instead of that short name.

[csandersdev]

@lmsurpre @JohnTimm The operation definition for patient-everything-operation has input parameters start and end that pertain to the dates that care was provided. Do you have any suggestions on how to generically identify the field that represents care date for each individual resource type? Some resources like Procedure have a date search parameter that is directly related to care. Some, like the Account resource, don't define a date, but have something that might be related such as the period search parameter. Some, like SupplyRequest have a date parameter, but I'm not sure it is care related. Then, you've got SupplyDelivery which has neither date nor period search param. Do we use just always use the date search parameter if it is available and otherwise ignore start/end date? Do we need some custom mapping for each resource for which parameter represents care date?

The spec is ambiguous about whether the start and end dates are inclusive or exclusive. Thoughts?

There is a _count input parameter that is expected to set page size for a scrolling resultset much like what is done in the search operation. I'm not clear how that would interact with the everything operation. If the operation builds a big bundle and returns it, will the server framework handle the paging? Does the operation need to handle its own paging? I can imagine it being expensive to page through an "everything" bundle.

[lmsurpre]

I'd probably recommend to start simple.

For the start and end dates, maybe just use date which maps to http://hl7.org/fhir/SearchParameter/clinical-date for all of the following resources:

      "AllergyIntolerance",
      "CarePlan",
      "CareTeam",
      "ClinicalImpression",
      "Composition",
      "Consent",
      "DiagnosticReport",
      "Encounter",
      "EpisodeOfCare",
      "FamilyMemberHistory",
      "Flag",
      "Immunization",
      "List",
      "Observation",
      "Procedure",
      "RiskAssessment",
      "SupplyRequest"

If the resource type doesn't have that, then either: A. do not include them in the response (and document that specifying start and end parameters will only yield resources with clinical dates); or B. include ALL such resources in the result (and document that specifying start and end will not reduce the number of resources that are retrieved for resource types with no clinical date)

As for paging, I think an initial implementation could simply leave that as Unsupported for now. If the total number of resources are beyond some threshold, then reject the request and maybe recommend the use of bulk export which is designed for transmitting lots of data.

And finally:

The spec is ambiguous about whether the start and end dates are inclusive or exclusive. Thoughts?

I'm not sure it matters much, but I'd probably err on the side of making them inclusive if its not well-defined. Or more specifically, I'd probably map them to our default search behavior for >= and <= on date range searches (because I recommended to use the search feature under the covers in order to select the resources)

[luisgarcc]

@lmsurpre I'd like to take a shot at implementing this operation, can you assign this issue to me please? Thanks

[prb112]

Go for it Luis... ping us with questions.

[punktilious]

@luisgarcc please ping me when you get chance so we can discuss the _since parameter.

[prb112]

Tests

Check with Patient that does not exist

curl --location --request GET 'https://localhost:9443/fhir-server/api/v4/Patient/1/$everything' \ --header 'Content-Type: application/fhir+json' \ --header 'Authorization: Basic ...'

{ "resourceType": "OperationOutcome", "id": "c0-a8-56-16-d3a145a8-6644-472e-93fa-9aa9dea8a503", "issue": [ { "severity": "fatal", "code": "not-found", "details": { "text": "Patient with ID '1' does not exist." }, "expression": [ "" ] } ] }

Check with patient that exists

curl --location --request GET 'https://localhost:9443/fhir-server/api/v4/Patient/1306279a-da55-465f-82b2-a5844cd15802/$everything' \ --header 'Content-Type: application/fhir+json' \ --header 'Authorization: Basic ...'

{ "resourceType": "Bundle", "id": "13e99802-819f-458e-9813-52ecf76050d6", "type": "searchset", "total": 1, "entry": [ { "fullUrl": "https://localhost:9443/fhir-server/api/v4/Patient/1306279a-da55-465f-82b2-a5844cd15802", "resource": { "resourceType": "Patient", "id": "1306279a-da55-465f-82b2-a5844cd15802", "meta": { "versionId": "5", "lastUpdated": "2021-03-19T13:18:46.257574Z" }, "name": [ { "family": "Doe", "given": [ "John" ] } ], "telecom": [ { "system": "phone", "value": "555-1122", "use": "home" } ], "birthDate": "1986-06-20" }, "search": { "mode": "match", "score": 1 } } ] }

curl --location --request GET 'https://localhost:9443/fhir-server/api/v4/Patient/1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca4/$everything?start=2010' \ --header 'Content-Type: application/fhir+json' \ --header 'Authorization: Basic ....'

curl --location --request GET 'https://localhost:9443/fhir-server/api/v4/Patient/1785facb357-2fa20d95-d828-4c60-a972-2707c82f4139/$everything?_type=CareTeam,CarePlan' \ --header 'Content-Type: application/fhir+json' \ --header 'Authorization: Basic ....'

{ "resourceType": "Bundle", "id": "856496e3-9994-4d43-870b-59cb7623abed", "type": "searchset", "total": 11, "entry": [ { "fullUrl": "https://localhost:9443/fhir-server/api/v4/Patient/1785facb357-2fa20d95-d828-4c60-a972-2707c82f4139", "resource": { "resourceType": "Patient", "id": "1785facb357-2fa20d95-d828-4c60-a972-2707c82f4139", "meta": { "versionId": "1", "lastUpdated": "2021-03-23T15:20:56.971716Z" }, "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Generated by <a href=\"https://github.com/synthetichealth/synthea\">Synthea.Version identifier: master-branch-latest-2-g8e7e92c\n . Person seed: 7105486291024734541 Population seed: 0

[prb112]

Opened an issue for the Deleted Patient

[prb112]

QA complete. issues identified will be treated in other issues