search

LinuxForHealth / FHIR

The LinuxForHealth FHIR® Server and related projects
https://linuxforhealth.github.io/FHIR
Apache License 2.0
331 stars 157 forks source link

$everything operation should support listing of patients based on context when called with Patient/$everything #2402

Open prb112 opened 3 years ago

prb112 commented 3 years ago

Is your feature request related to a problem? Please describe. Per the specification, If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. In such cases, the server may choose to return an error rather than all the records.

Describe the solution you'd like $everything should list a patient's links based on the context.

Describe alternatives you've considered Do nothing, and leave feature as-is.

Acceptance Criteria

  1. GIVEN Patient/$everything operation is installed AND fhir-smart is installed WHEN Patient/$everything is executed with an access token that carries patient/* scopes and patient_id context for patients P and Q AND the number of resources being return is below our configured limit for the number of resources allowed on a $everything response THEN a Bundle containing resources related to both Patient P and Patient Q

  2. GIVEN $everything operation is installed AND fhir-smart is NOT installed WHEN Patient/$everything is executed AND the number of resources being return is above our configured limit for the number of resources allowed on a $everything response
    THEN return a 400 Bad Request with an OO error type of "not supported" (or too-costly?)

Note: Using fhir-smart is a good way to ensure the current patient only has access to a limited number of patients, making it more likely to stay below our configured limit. This should be tested as part of the integration tests for this feature.

Additional context The current "configured limit" is a hardcoded to 10,000 ...should this be lowered? Should it be configurable?

lmsurpre commented 3 years ago

If we do implement this one, we're thinking to continue failing the request if the total number of resources is above the configured limit.

One way to address that concern would be to support "id-only" results as per https://github.com/IBM/FHIR/issues/2027

However, we think bulk export (async) is a better way to handle this type of data request in general, so moving this to the icebox for now.