Stream: hapi
Topic: Lost tag?
Paul Lynch (Mar 19 2020 at 20:16):
When I POST an Observation with a tag to http://hapi.fhir.org/baseR4/Observation, the creation succeeds, but the tag is dropped. Are there some rules around what tags HAPI FHIR accepts? The WildFHIR server keeps the tag when I post it there. Here's an Observation for my test case:
{ "resourceType": "Observation", "status": "final", "code": { "coding": [ { "system": "http://loinc.org", "code": "29463-7", "display": "Weight" } ], "text": "Weight" }, "meta": { "tag": [ { "display": "lformsVersion: 22.0.0" } ] }, "valueQuantity": { "value": "42", "code": "kg", "system": "http://unitsofmeasure.org" }, "effectiveDateTime": "2020-03-19T15:12:25.585Z", "issued": "2020-03-19T15:12:25.585Z" }
James Agnew (Mar 19 2020 at 20:25):
HAPI requires tags to have at least a system or a value, so it ignores tags that are only a display name
Paul Lynch (Mar 19 2020 at 20:50):
Is that correct behavior? In a coding, "code" is not required, and I think the only use of coding without a code would be to have an uncoded "display".
James Agnew (Mar 19 2020 at 21:22):
It's definitely not behaviour that is mandated by the spec or anything like that.. but it is definitely how the current design works. Kind of like HAPI's requirement out of the box that client-assigned IDs be non-numbers
Paul Lynch (Mar 20 2020 at 13:06):
@James Agnew I am not sure if you are saying that this is a known issue with HAPI which, time permitting, will eventually be addressed (very understandable) or that you think it is okay for a server to place additional restrictions on resources beyond what FHIR specifies. The latter, unless done through profiling, causes problems for interoperability, doesn't it? (This is more of a theoretical question; it is not hard for me to add a code to my tag.)
James Agnew (Mar 20 2020 at 13:26):
I guess I'm characterizing it as "sub-optimal behaviour that will hopefully either be fixed completely or be made configurable in the future, but that isn't currently being worked on". I am sure that every FHIR server out there has a few gremlins like this one that are based on their particular design. :)
A bigger priority for me is that HAPI's tagging system does have some concurrency issues- creating a brand new (never before used) tag on two resources at the exact same time can lead to an optimistic lock failure, and this seems to burn a surprising number of people... Perhaps this issue would get fixed as a part of the fix for that one.
Paul Lynch (Mar 20 2020 at 13:29):
James Agnew said:
I am sure that every FHIR server out there has a few gremlins like this one that are based on their particular design. :)
And the clients, too. :slight_smile:
Last updated: Apr 12 2022 at 19:14 UTC