Stream: implementers
Topic: Empty lists
David Hay (Mar 01 2019 at 21:18):
There doesn’t seem to be a consistently applied way of representing an empty list of things (like Allergies, Medications or Conditions).
The spec itself seems to take a ‘dollar each way’ approach – eg in AllergyIntolerance it recommends using List, but then states to use an instance of AllergyIntolerance.code with the value of code to be ‘no known allergies’ during STU.
Looking at IG’s like IPS (International Patient Summary) it uses a Composition – but instead of using the section.emptyReason for an empty list, you populate the section with a resource that states that there are no resources, and why. That seems – odd.
I’d like to propose that for IG’s that use Composition, section.emptyReason should be used for empty lists, and otherwise use List.emptyReason
Lloyd McKenzie (Mar 01 2019 at 21:25):
In Argonaut, they don't use List at all (and they're not using Composition). List.emptyReason only works well if the system is using List which involves having some sort of a curated list. So I think we need to allow for the notion of a record that says "no known allergies" or "no known medications". Agree that that approach should not be used together with Composition or List though.
David Hay (Mar 01 2019 at 21:31):
You could argue that an extraction from an EHR / EMR would generally be a curated list (ie the clinician has populated a List in the EHR/EMR - including 'no known allergies'. Perhaps argonaut should be looking at List also...
Lloyd McKenzie (Mar 01 2019 at 21:32):
List in argonaut was long debated. They just want to expose meds and allergies by direct query, not by first hitting a list and then grabbing all of the referenced resources.
Lloyd McKenzie (Mar 01 2019 at 21:33):
Essentially the "List" is everything that's available and thus is redundant, and having to hit the List resource only to find records of "none known" was deemed to be confusing/inefficient
Lloyd McKenzie (Mar 01 2019 at 21:34):
(Note: I'm not necessarily a fan of the decision, I'm just reflecting what was decided and why :))
Rob Hausam (Mar 01 2019 at 21:47):
Yes, that was pretty much the thought process for the Argonaut decision. In IPS, I think we landed on the current approach primarily because it was consistent with the way that we did it in CDA - using an explicit declaration of absence (and there isn't an equivalent of section.emptyReason in CDA, of course). It may be time, though, to reconsider adopting a more thoroughly "FHIR-like" approach for the FHIR IPS IG. I guess it would have been nice to have suggestions like this (and others that we've recently gotten related to the Argonaut comparison) in ballot comments, but we all know it doesn't necessarily go that way.
John Silva (Mar 01 2019 at 22:38):
Not directly related but this 'empty list', especially of Allergies reminds me of the notion of 'state' in V2 AL1 vs IAM --- that is, snapshot mode vs update mode. If I remember right, FHIR only supports 'snapshot' mode. So, the question then becomes, how would a system 'clear out' a previously documented Allergy (AllergyIntollerance resource) for a patient?
Lloyd McKenzie (Mar 02 2019 at 02:43):
Delete
Grahame Grieve (Mar 02 2019 at 05:15):
I am not a fan of Argonaut's decision on this at all. I think it will turn out to be problematic. But it's made, and so I think it's best to stick with it. For that reason, we should document best practice for various negation statement variants for medication, allergy, problem and history list, and have them in the relevant resources, and IPS should follow argonaut practice
Grahame Grieve (Mar 02 2019 at 05:17):
I agre ewith @Rob Hausam that this is the kind of feedback that should come through ballot, but it hasn't - I'm working on driving alignment here and will hopefully be closer to balloting this stuff in the future. (And thanks to @Michele Mottini for doing a formal review which has driven dsicussion on the #argonaut channel)
Eric Haas (Mar 02 2019 at 17:02):
Reflects disconnect between perception and reality of hl7 ballot.
David Hay (Mar 02 2019 at 20:14):
really? A potentially problematic decision that can't be re-addressed just because people are using it? Why then, have Composition.section.emptyReason at all? ie when would that be used, if the pattern is to populate empty sections with a representative resource with a code set to 'no data' (and any required fields set to some pre-determined value)?
David Hay (Mar 02 2019 at 20:23):
btw - to be clear, I'm talking about when Composition is present - ie a record summary rather than a direct request for a resource like AllergyIntolerance (where the code approach seems reasonable)...
Cooper Thompson (Mar 05 2019 at 16:16):
I may have missed the initial debate, but if we represent NKA-type scenarios using List or Composition, how does that work with AllergyIntolerance.search? Or are we suggesting that folks not use AllergyIntolerance.search at all, and instead use List/Composition instead?
Lloyd McKenzie (Mar 05 2019 at 16:27):
The notion is that you'd query the List to return the patient's list of allergies - because there are reasons for servers to store AllergyIntolerance records that aren't necessarily part of a currated list - data received from elsewhere that's duplicate/outdated, etc.
Cooper Thompson (Mar 05 2019 at 16:35):
I feel like if we took that approach, I'd have to constantly explain the how and why to every app developer, even if we have good doco around it. Since AllergyIntolerance.search is the intuitive way to get patient allergies, it seems better to annotate the resources with their status with respect to a being part of the curated chart vs. being duplicate/outdated.
Lloyd McKenzie (Mar 05 2019 at 16:46):
The problem is that there are times when you need to take in external data and leave it "as is" - no annotation - or at least no annotation other than tags, which most systems wouldn't pay attention to.
Lloyd McKenzie (Mar 05 2019 at 16:47):
The EHRs bury all of that stuff elsewhere right now - allergies coming in from CDA documents, etc. don't get exposed in their allergy interfaces. However if they had a FHIR-based repository, they'd have to be.
Lloyd McKenzie (Mar 05 2019 at 16:48):
That's why they went with the easy/intuitive route. Even though it may eventually cause pain/problems.
Grahame Grieve (Mar 05 2019 at 17:39):
we defined $list so you could stick to the search interface, but it doesn't deal with NKA.
Cooper Thompson (Mar 05 2019 at 18:17):
Maybe my worldview is a little EHR-centric, but do we expect many non-EHRs to implement Argonaut?
Grahame Grieve (Mar 05 2019 at 18:19):
yes. all consumers. But argonaut decisions have a power of their own. I think it's wrong even for EHRs - eventually Argonaut vendors will find that the decisions they've made will make it impossible to share information across the argonaut interface.
Cooper Thompson (Mar 05 2019 at 18:36):
@Lloyd McKenzie regarding the issue of keeping external data "as is" - if systems do actually need to do that, doesn't that same problem apply to all resources in the spec, and not just for what is included in Argonaut? Doesn't that suggest we'd have to abandon the idea of a search interaction completely?
Grahame Grieve (Mar 05 2019 at 18:36):
that seems like a big jump
Cooper Thompson (Mar 05 2019 at 18:38):
Right. I can't really understand how a system can really expose "as-is" resources without massive side effects. That would push data de-duplication to the client, which is a huge lift. I guess I'm basically just saying I don't buy (or don't fully understand) the "as-is" issue.
Grahame Grieve (Mar 05 2019 at 18:39):
why would it create a de-duplication problem? I think you're imagining that the EHR would stop doing list management... but no.
Cooper Thompson (Mar 05 2019 at 18:47):
Sort of spit-balling here, but another way to solve this is to put the annotation within the Bundle entry on the search response rather than in the resource. Obviously would need updates/extensions to Bundle, and I'm sure there are all sorts of reasons I'm not considering regarding the impact to Bundle.
Jenni Syed (Mar 05 2019 at 18:56):
I do want to call out that at least for allergies (and yes, this goes back to all the negation talks) that NKA and NKMA can be represented by search. Those are codes that are included in the value set for the Allergy.code
Jenni Syed (Mar 05 2019 at 18:57):
For eg, our documentation for our FHIR allergy search calls these out: https://fhir.cerner.com/millennium/dstu2/general-clinical/allergy-intolerance/#overview
Lloyd McKenzie (Mar 05 2019 at 18:57):
That's true, but they don't work if the AllergyIntolerance repository is a conglomeration of data from all over - because you might have 5 NKAs from different times plus a bunch of allergies that conflict with the NKA assertion. NKA only works if you're "generating" that from a currated flag in a repository.
Jenni Syed (Mar 05 2019 at 18:58):
As to CCDA not showing in the list... for our implementation the goal is to show the same list the clinician can see and make decisions on. If they chose to bring an allergy into the formal clinical record, then I would expect it to show in the allergy list (and ideally have provenance stating where it came from)
Lloyd McKenzie (Mar 05 2019 at 18:59):
Contrast this with how Observations work where we accept that there's a grab-bag of observations from all over the place, some of which will say conflicting things because they're from different sources and different timestamps. If you do a query and get back two different blood types for the same patient, you're going to ask questions, but it's certainly a possibility.
Jenni Syed (Mar 05 2019 at 18:59):
If you don't limit an allergy by status, you're also likely to see older allergies that are no longer active and could be conflicting as well
Jenni Syed (Mar 05 2019 at 19:00):
but yes, I think there are definitely going to be challenges with representing the "full document store" type approach vs. a system that is representing the full legal record/known record.
Peter Jordan (Mar 05 2019 at 19:00):
An allergy/intolerance collection/list/group is basically a set of risk assessments made at specific points in time. It's perfectly feasible to have several NKA, NKDA records in that collection, particularly if derived from multiple sources.
Jenni Syed (Mar 05 2019 at 19:01):
I'm not sure that eliminates search as an option, but it does start to ask questions around: how does the server take on de-duping or allow the client to ask the server to take on that effort
Jenni Syed (Mar 05 2019 at 19:01):
and I think that's where you all are saying list is the formal way to do that?
Jenni Syed (Mar 05 2019 at 19:02):
but I'm not sure I'm there yet... I agree it's a challenge, I wonder if it's solvable another way (for the "active" list - absolutely agree that other types of controlled and curated lists may need special consideration)
Grahame Grieve (Mar 05 2019 at 19:02):
that's what the $list parameter is for.
Grahame Grieve (Mar 05 2019 at 19:02):
because the client can't and shouldn't take on de-duplication but that's irrelevant. What it needs to take on is understanding the context of the information
Grahame Grieve (Mar 05 2019 at 19:03):
the argonaut interface simplifies matters because there is no context- it's just the current list. That is great until it's no longer true
Peter Jordan (Mar 05 2019 at 19:05):
Static lists v a dynamic, real-time, event-driven health & wellness record.
Jay Lyle (Sep 24 2020 at 22:36):
Grahame Grieve said:
that's what the $list parameter is for.
The $list parameter ? I see _list, and I see $find. Not connecting the dots.
Seems like the list could have a useful empty reason if it's curated, with a shelf life.
Grahame Grieve (Sep 24 2020 at 23:38):
_list - you're right
Last updated: Apr 12 2022 at 19:14 UTC
