Stream: implementers
Topic: Patient search - active
John Moehrke (Apr 07 2017 at 17:20):
What is the Patient search behavior when the client does not include the 'active' query parameter? Does this imply only active Patient resources should be queried? It would seem otherwise all queries on Patient must most of the time indicate active as not false.
David Hay (Apr 07 2017 at 19:26):
I would assume that if not specified in the query, then both active & inactive Patients would be returned, and it would be up to the client to process them...
Lloyd McKenzie (Apr 08 2017 at 00:05):
In theory a server could "add" a default filter, but if they were doing so they'd have to declare it. And I would generally consider that poor practice
John Moehrke (Apr 09 2017 at 16:48):
well, there is a problem... I don't disagree with either of your answers... but, it is indeed a problem.... SO IHE PDQm would now need to specify the use of this query parameter... and everyone should be careful of the results they get back, as they might be getting back something that is not active.
John Moehrke (Apr 09 2017 at 16:49):
especially true if the server doesn't support the active query parameter....
Jens Villadsen (Apr 09 2017 at 21:49):
Well ... you always need to be careful. Regardless, the value of the attribute is reflected on each of the patient resources returned
John Moehrke (Apr 10 2017 at 12:54):
I think this is especially problematic when the element isModifier true.
Elliot Silver (Apr 10 2017 at 16:21):
Is this any different from other searches which could return entered-in-error or completed resources?
Jenni Syed (Apr 10 2017 at 17:18):
In our fhir implementation, we would NOT return inactive in any resource (this is logically different than "entered in error") since this is essentially resources that have been logically deleted
Jenni Syed (Apr 10 2017 at 17:19):
if you read by id, and it's inactive, we reference the record that replaced this patient
Jenni Syed (Apr 10 2017 at 17:20):
but wouldn't return any other data about that patient, since it should no longer be used anywhere
Jenni Syed (Apr 10 2017 at 17:23):
This is probably something that should be on the safety checklist? I know it applies to patient - and likely other resources that have the concept of active vs inactive
John Moehrke (Apr 10 2017 at 17:37):
@Jenni Syed so, then you interpret a missing query parameter for active, to be a request for those that are not inactive? I think this is logical, but not obvious. Coming from DSTU2, this active modifier is new, and now (STU3) seems the active parameter is about as close to a required query parameter as there is...
Jenni Syed (Apr 10 2017 at 17:38):
We do not support that query parameter at all
Jenni Syed (Apr 10 2017 at 17:39):
which is documented both on our readable doc and conformance/capability
Jenni Syed (Apr 10 2017 at 17:40):
Again, I think this is closer to what most systems would do when something is logically deleted - you wouldn't normally expect to get those items back when, say, the reg nurse queries by name
John Moehrke (Apr 10 2017 at 17:50):
deleted is different than active=false... deleted is a CRUD operation, and part of version lifecycle. active element is somehow different. I am confused on how it is different, but it has shown up in STU3.
John Moehrke (Apr 10 2017 at 17:50):
by 'not support', that would mean you would ignore gracefully if a client included the active parameter... right?
Jenni Syed (Apr 10 2017 at 17:52):
Correct, though in STU 3 there's also the Prefer header where someone could tell us to fail :)
Jenni Syed (Apr 10 2017 at 17:53):
Still feels like this is part of the safety checklist... @Grahame Grieve - Thoughts on above?
John Moehrke (Apr 10 2017 at 18:00):
wow, thanks for more lessons-learned... prefer header seems useful, but also seems rather dangerous...
John Moehrke (Apr 10 2017 at 18:00):
I do agree, safety checklist material
Grahame Grieve (Apr 15 2017 at 21:38):
well, the lifecycle page says that active = false *is* the same as entered-in-error.
Grahame Grieve (Apr 15 2017 at 21:40):
it's really problematic for clients when servers omit results by default - how do you get them not to be omitted? But it's also really problematic for clients when some servers don't support search parameters, and others do, and it matters.
I think this is more than a afety check list issue - we probably need special rules about search parameters on entered-in-error linked search parameters to enable safe consistency
John Moehrke (Apr 17 2017 at 12:00):
Yes, @Grahame Grieve you understand my concern...
Jenni Syed (Apr 17 2017 at 14:06):
To add some context: we're already finding that apps which don't search on status/aren't filtering on status are also often NOT handling entered-in-error
Jenni Syed (Apr 17 2017 at 14:06):
IE: they display an observation result or use it as if it's accurate even when the status is errored.
Jenni Syed (Apr 17 2017 at 14:07):
However, a physician seeing a result that was once active/valid and could have been used in clinical checking seems like a more necessary case than a physician needing to see an inactive/combined away patient that they can't use for anything, and shouldn't have any clinical data associated anymore
Jenni Syed (Apr 17 2017 at 14:08):
(again, if an app has the patient context already, and reads it by id, they will get the inactive patient with the link to the replacement)
Grahame Grieve (Apr 17 2017 at 19:03):
so these apps are non-conformant. But agree that we need to do more about this
John Moehrke (Apr 18 2017 at 12:14):
The example on the Search page includes
GET [base]/Patient?active=true
is that always going to work? What about when the active element is empty?
is it better to use
GET [base]/Patient?active:not=false
is that going to work where versioning is used and the DELETE operation has deleted it?
Lloyd McKenzie (Apr 18 2017 at 15:35):
@John Moehrke Patient.active has a default, so if it's empty, the presumed value is 'true'. It's not supported to have Patient.active be unknown
John Moehrke (Apr 18 2017 at 15:39):
@Lloyd McKenzie that is a valid point. putting much faith in servers implementation of ramifications of defaults... okay... It still seems active:not=false is more safe for a client.
Lloyd McKenzie (Apr 18 2017 at 15:40):
If the server supports the ":not" qualifier
John Moehrke (Apr 18 2017 at 15:41):
oh, great... 'not' good
John Moehrke (Apr 18 2017 at 15:42):
so.. more likely active=true will work then...
Lloyd McKenzie (Apr 18 2017 at 15:50):
Correct
Grahame Grieve (Apr 18 2017 at 21:01):
has someone created a task to make sure we address this?
Lloyd McKenzie (Apr 18 2017 at 21:13):
Address it how?
Grahame Grieve (Apr 18 2017 at 21:15):
at least document it well, including in the safety check list.. Possible introduce a conformance criteria on these search parameters that requires server implementers to do more safety related checking, and encourages clients to consider it
Lloyd McKenzie (Apr 19 2017 at 02:12):
GF#13216, though I think the real safety issue is about other "entered in error" issues. Accidentally retrieving a non-active patient is unlikely to result in any patient safety issues I can think of.
Yunwei Wang (Apr 19 2017 at 16:17):
Back to @John Moehrke original question about searching patient without "active" search parameter. From the discussion above, my understanding is that if "active" parameter is not present, server should treat the search as "active=true". Is my understanding correct?
John Moehrke (Apr 19 2017 at 16:47):
right... it is understood what the default of the element is... but what is the default of the parameter when it isn't included in a search...
Grahame Grieve (Apr 19 2017 at 20:20):
no. The active element defaults to false. But the active search parameter doesn't, and servers should treat search as search on any value of active if active is not specified
Elliot Silver (Apr 19 2017 at 20:41):
Actually, the Patient.active element defaults to true.
Grahame Grieve (Apr 19 2017 at 20:49):
sorry, typo - not paying quite enough attention there
Elliot Silver (Apr 19 2017 at 20:54):
By the way, how do defaults work in the presence of extensions? Is there a difference between:
<Patient>
...
<active>
<extension url="http://someURL..." >
<valueDate value="20171511" />
</extension>
</active>
</Patient>
and
<Patient>
...
<active value="true">
<extension url="http://someURL..." >
<valueDate value="20171511" />
</extension>
</active>
</Patient>
Do both match a search for active=true?
Lloyd McKenzie (Apr 19 2017 at 20:57):
My opinion is that both would be the same, but clarification would be good. Would you mind submitting a change request?
Grahame Grieve (Apr 19 2017 at 20:57):
those are different, but both match for search active=true
Elliot Silver (Apr 19 2017 at 20:59):
I can see rationale for either part of your statement, Grahame, but I'm not sure they make sense together.
Grahame Grieve (Apr 19 2017 at 21:06):
they are different in respects other than searching
Elliot Silver (Apr 19 2017 at 21:11):
GF#13224 filed.
John Moehrke (Apr 20 2017 at 11:52):
I understand the explanation for active. This means that for any real use of the Patient resource, the active=true will be a mandatory parameter, unless you really want inactive entries too (which is less likely).
Brian Postlethwaite (Apr 26 2017 at 03:49):
Wondering if the fhirpath data extraction expression should be updated for this also? Or is that some logic that need to know elsewhere.
Brian Postlethwaite (Apr 26 2017 at 03:50):
Was thinking something like (Patient.active | true).first() but that doesn't work if there is no value, and just an extension as the example given above has.
Brian Postlethwaite (Apr 26 2017 at 03:59):
I guess it could be iif(active.hasValue(), active, true)
Grahame Grieve (Apr 28 2017 at 00:49):
you could make a task for this; right now, there's no support for doing something like that in teh build
Elliot Silver (Oct 24 2017 at 17:31):
GF#13339 and GF#13224 are still open on this issue. Has there been any further discussion since Madrid? It seems this is something that will have to be nailed down for a normative release.
Last updated: Apr 12 2022 at 19:14 UTC
