Stream: implementers
Topic: Support for "Current Resource Lists" in real life?
Josh Mandel (May 07 2021 at 14:10):
The FHIR Safety checklist (http://hl7.org/fhir/safety.html) includes as part its very first item that a system needs to handle "currency issues". The details are at http://hl7.org/fhir/lifecycle.html#current, but briefly, these are "functional lists" like $current-problems, $current-medications, and $current-allergies, for use in queries like:
GET [base]/AllergyIntolerance?patient=42&_list=$current-allergies
I'd like to understand whether servers support this in real-world implementations. Can anyone weigh in (positive or negative, or share context/evaluation on why you do or don't)?
Grahame Grieve (May 09 2021 at 21:57):
I haven't seen it supported in the real world. And note that the safety check list doesn't say you have to solve the problem that way, just that you should solve it somehow.
Note that this is the aspect of the argonaut profiles that bothers me the most: the assertion that any problems available through the API are the current problem list; long term, this will be a problem
Josh Mandel (May 09 2021 at 23:12):
I agree, Grahame, re: Argonaut. We're just starting to feel a flavor of this with our "write API" project (#Argo Write) where we're asking questions like "do we just write data to the 'main EHR ' FHIR endpoint, or is there some kind of 'holding tank'?" and "How do you tell which items visible via search from the 'main EHR' FHIR endpoint are part of the official/curated/reconciled EHR?".
Grahame Grieve (May 09 2021 at 23:13):
yes these are the kind of problems I forecast back when the group chose simplicity at the time
Josh Mandel (May 09 2021 at 23:57):
I'd be interested in your thoughts @Grahame Grieve about writing Observations; it's the initial scope we are taking on in The Argonaut project but unlike problems or medications or allergies, there's no concept of a "curated Observations" set in FHIR. We've noodled about using tags, or extension, or distinct endpoints...
Grahame Grieve (May 10 2021 at 00:11):
what's the real world workflow? Are they differentiated by source, or is there a validation/approval process?
Josh Mandel (May 10 2021 at 00:34):
So far the closest we have is "often organizations want to validate/approve these incoming Observations, but they don't want to want to."
Josh Mandel (May 10 2021 at 00:35):
(I'm paraphrasing; @Eric Haas may have a more nuanced take.)
Grahame Grieve (May 10 2021 at 00:39):
I've also heard: the want to accept them into a holding bin, and use a mix of AI and human choice to create clinical observations based on chosen or aggregated data from the patient observations
Josh Mandel (May 10 2021 at 16:28):
I like that and agree it's useful; we haven't managed to find anyone working on this model though, so if you can make any intros that'd be helpful!
Grahame Grieve (May 10 2021 at 19:06):
I don't know anyone working on that model in FHIR in public.
Eric Haas (May 10 2021 at 19:20):
Grahame Grieve said:
I've also heard: the want to accept them into a holding bin, and use a mix of AI and human choice to create clinical observations based on chosen or aggregated data from the patient observations
This is the same place we are at for some writes ( not all ). But we have no answer of whether and how to update the status of the write request for the sender asynchonrously and as simply as possibly. (i.e., hiding all that pesky complexity).
Grahame Grieve (May 10 2021 at 19:22):
well, I think that this is a candidate for a separate end-point, since it's a separate store
Grahame Grieve (May 10 2021 at 19:23):
that patient software knows what it has committed and just commits; some of the data may be replicated into the patient record
Eric Haas (May 10 2021 at 19:30):
Grahame Grieve said:
well, I think that this is a candidate for a separate end-point, since it's a separate store
yeah, well nobody we polled is doing this...
Cooper Thompson (May 10 2021 at 19:35):
I'm still not sure I think we need to surface the different data stores in the API. In some ways, that is just an internal implementation detail. Having separate endpoints for holding tank vs. system of record will be increasingly undesirable for us, as we're actively working to blur the lines in our internal implementation.
Cooper Thompson (May 10 2021 at 19:36):
I still like the model of having one endpoint, one API, and then annotating data with information about what audiences (or purposes) the data qualifies for (e.g. will it be displayed in the chart, will it be used for CDS, health maintenance, etc.).
Cooper Thompson (May 10 2021 at 19:37):
Internally, if a resource is in the holding tank, that could just mean that the data doesn't qualify for use in CDS, but still might show in the chart. Or maybe it is sometimes used in CDS(depending on the source (e.g. Provenance)).
Josh Mandel (May 10 2021 at 20:08):
Having to annotate data with audience in direct/specific/materialized way makes it really hard to create policies over types/categories of data. There could be lots of these audiences or purpoess, and every time you change your policy, you need to update millions of annotations?
Josh Mandel (May 10 2021 at 20:09):
I wonder if there's something smaller / more stable / more targeted that we could use for such annotations (rather than "audience", which is going to to depend on context and won't be easy for diverse apps to interpret)
Cooper Thompson (May 10 2021 at 20:14):
Yeah, definitely open to making the annotation idea more generic. To be honest, I got a little too excited about the idea - we don't really have a way to annotate at the level of discreteness I described.
Lloyd McKenzie (May 10 2021 at 20:49):
FHIR-I is currently collecting agenda topics for the face-to-face. This seems like it might be an appropriate topic for a quarter?
Eric Haas (May 10 2021 at 23:50):
This is a topic we discuss every other Wednesday on the argo call and I doubt most of those on that call will participate in the WGM. So instead of forking it there, I suggest we continue to hash it out on the argo call.
Last updated: Apr 12 2022 at 19:14 UTC
