Stream: bulk data
Topic: patient-everything
Caitlin Voegele (Mar 18 2021 at 03:18):
We are investigating the patient everything operation and had a couple questions on interpretation:
- Reviewing the _count parameter, it seems like it is most commonly used when calling /Patient/$everthing with no id specified. Are others using _count with a single patient as well.
- We are looking to add some resources that are referenced off of resources that are referenced from the patient. For example, CareTeam.participant.member and DignosticReport.encounter. If we specify _since, and CareTeam does not match the critiera, would you still pull the member? And if you set a start/end date, and the encounter matches, but the DiagnosticReport does not would you pull the encounter? What if the DiagnosticReport does, but the encounter doesn't? Our thought would be that you would start at the top resource (i.e. CareTeam or DiagnosticReport) and if it is satified you would pull the data and then go to the next level and validate if it satisfies. If you don't include the CareTeam, you wouldn't include any of the resource referenced from it.
bion howard (Mar 18 2021 at 18:26):
Really we gotta focus on the workflow. People want to get all the data for a given patient (themself, or a patient under their care) so the concept of backlinks is totally critical, and doesn't get enough attention in FHIR.
I suggest we return any resources which link to resources in the requested timeframe. For example, if an encounter leads to some new requests (for lab tests, imaging, etc), then you have a good idea to return the eventual outcome of those requests. Otherwise, a requester needs to [figure out how to] make yet more requests to find stuff which references stuff nested in the first request
Caitlin Voegele (Mar 18 2021 at 23:55):
@bion howard This point definitely makes sense. What about the flip side though? For example, if you were trying to see what was known about the customer on Jan 1 2021, would you want to include results that post on January 2 2021, even if they came from an encounter that was on December 31 2020? That's the scenario I was concerned about.
Cory G Stevenson (Mar 19 2021 at 14:50):
@Caitlin Voegele - I was under the impression the flip side question is why the support for _since is required. After reading multiple view point I have come to the conclusion new payer may need to request information from old payer multiple times. Each time the request is made the new payer will only want information updated since the last time the request was made. This conclusion is based the knowing that a claim can take time to process.
bion howard (Mar 19 2021 at 15:54):
as long as the data is timestamped, it feels easier to send requests with their results, and filter them on the client side, than to not send the results, and force the client to figure out how to find them. For example, Dr. Alice needs to know about some lab test she ordered on a certain day. If that lab request also returns the result of the lab test, she's done.
Auditors who need only data on file at a certain time, are indeed critical to consider, but they're not practicing medicine, they could just filter out the results data on their end as they wish. The specific (possibly urgent) needs of the Practitioner <-> Patient relationship ought to outweigh administrative.
Just one man's opinion. What do you think?
Paul Church (Mar 19 2021 at 17:26):
- Yes, we are - the single patient could hypothetically have 100,000 Observations and we try to be consistent about supporting _count and pagination on any method that might return a large bundle (_history, etc.).
- For _since I lean towards assembling the entire set of candidate resources and then filtering (and that is what we implemented) because the use case is a client trying to get the incremental changes. For start/end date....I have no idea.
Ranvijay Kumar (Mar 19 2021 at 21:40):
It makes practical sense to assemble the complete set of resources and then filter based on the date time. There is a side effect of this approach: depending on the filter criteria, the response may contain some 'disconnected' resource that cannot be linked to the patient directly. However, this is side effect is not too bad. The other approach of filtering out the child resource if the parent resource does not meet the filter criteria is more problematic. In that case, if the parent resource is not modified since a particular day, it will not be picked in the _since call even if its children have been modified.
Last updated: Apr 12 2022 at 19:14 UTC
