Stream: implementers
Topic: Quantity search and display units
Lee Surprenant (Apr 30 2019 at 16:51):
Last fall we ran into a case where our fhir server wasn't behaving as expected by a user...after digging in we found what we feel is ambiguous language in the spec and opened https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=19597 (Clarify expected behavior for system-less quantity search).
Lee Surprenant (Apr 30 2019 at 16:52):
Lloyd asked me to poll the implementer community to see how others are handling this...does anyone index the displayable unit and make that available via search? Does anyone not?
Lee Surprenant (Apr 30 2019 at 17:10):
For example, suppose you have an Observation with a quantity like
"valueQuantity": {
"value": 7,
"unit": "yrs",
"system": "http://unitsofmeasure.org",
"code": "a"
}
And you receive a search like Observation?value-quantity=7||yrs.
Lee Surprenant (Apr 30 2019 at 17:11):
/poll Does your server return the resource?
Lloyd McKenzie (Apr 30 2019 at 19:47):
@Grahame Grieve @James Agnew @Kenneth Myhra @nicola (RIO/SS) @Brian Postlethwaite
Kenneth Myhra (Apr 30 2019 at 21:13):
Spark will match for this search: http://spark.kufu.no/fhir/Observation?value-quantity=36||pg but internally it will make an assumption that the system is UCUM. Doing the same search with an unit it does not recognize as an UCUM unit, as the one above, it will ignore the search parameter. So the answer is both yes and no. I would need to do some refactoring and probably change the library that Spark uses for unit conversion.
Lee Surprenant (May 01 2019 at 00:12):
Thanks all. Hopefully its enough to inform the FHIR working group on the best way to clarify this behavior (if at all).
Michel Rutten (May 01 2019 at 09:31):
@Marco Visser @Christiaan Knaap ?
Christiaan Knaap (May 01 2019 at 11:51):
@Michel Rutten: I guess @Alexander Zautke 's vote is for Vonk.
Michel Rutten (May 01 2019 at 11:59):
Ah yes, never mind.
Alexander Zautke (May 01 2019 at 12:01):
Yes, the search request does work in Vonk :)
Richard Ettema (May 01 2019 at 18:45):
FYI - WildFHIR also supports this search.
Lee Surprenant (Nov 14 2019 at 13:56):
Does anyone know where we landed on this one?
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=19597 is marked as resolved, but I forget how to tell if the full change has been applied or not (is there a GForge field for that or resolved implies that?).
Was the text in the resolution (which I do see in the spec) the text that was added to address the question?
Lee Surprenant (Nov 14 2019 at 13:57):
If so, I don't think it actually clarifies the expected behavior in the case you search on just a unit (with no system). It only covers the case when the client searches with both system and unit. Safe to assume there will be no further clarification due to the existing implementation differences?
Lloyd McKenzie (Nov 14 2019 at 13:58):
Status changes to 'Applied' when made in the CI build, then 'Published' when an official release goes out.
Lloyd McKenzie (Nov 14 2019 at 13:59):
So nothing done yet
Lee Surprenant (Nov 14 2019 at 14:00):
thanks lloyd
Lee Surprenant (Nov 14 2019 at 14:01):
I also noticed some poor grammar in the existing text here: "In this case, it is inappropriate to search on the human display for the unit, which can be is uncontrolled and may unpredictable. "
Lee Surprenant (Nov 14 2019 at 14:02):
I'll just add that as a comment to this existing issue rather than open separate one
Lee Surprenant (Nov 14 2019 at 14:03):
and, more importantly, did the team actually resolve on what is the 'correct' behavior? or they just agree it needs clarification?
Lloyd McKenzie (Nov 14 2019 at 14:15):
My interpretation would be "if you specify both code + system, them match against Quantity.code + Quantity.system only. If you specify only code then match against Quantity.code or Quantity.unit". However, agree that's not super-clear in the disposition.
Last updated: Apr 12 2022 at 19:14 UTC
