Stream: implementers
Topic: tagging anomalies in persisted resources
René Spronk (Jan 18 2021 at 15:15):
If a server receives a FHIR resource, and it detects anomalies, (but business rules require one to persist that resource anyway), how would one flag that resource and identify the issues found? meta I guess ..
John Moehrke (Jan 18 2021 at 15:53):
would most applications notice a meta tag? There is one for .meta.security = #UNCERTREL or #UNRELIABLE --- see this valueset http://hl7.org/fhir/v3/SecurityIntegrityObservationValue/vs.html
Vassil Peytchev (Jan 18 2021 at 15:56):
What do you mean by "anomalies" and "receive"? If you mean a POST of a resource, my understanding is that the server is responsible to create a valid instance of the resource, and if that is different than what was POSTed, it is perfectly fine.
Michele Mottini (Jan 18 2021 at 15:56):
_most servers do not store data as FHIR_
John Moehrke (Jan 18 2021 at 16:00):
Provenance can clearly be used to show any corrections of the anomalies that were fixed during import. But it would be a poor solution for pointing out anomalies that one left in the imported resource.
René Spronk (Jan 18 2021 at 16:31):
There may be very good business reasons for storing that that is known to be either unreliable or incomplete - would you for instance refuse a FHIR based set of resources from another hospital if the patient is currently in your ER department? Better to flag is as 'problematic data', one can always attempt to fix any issues at some later point in time.
Vassil Peytchev (Jan 18 2021 at 16:45):
I am not disagreeing that there are good business reasons to handle unreliable or incomplete resources. I think it is important to determine what is to best way to handle them in different situations. Again, if there is a POST of a resource to a valid endpoint, the server is expected to provide the resource for subsequent GETs, and insisting that it must be capable of providing invalid resource instances is not reasonable.
The use case you are providing, however, is unlikely to result in a POST. If the patient is currently in your ER department, the anomalous resource is most likely in a bundle of type "searchset". The question now becomes, what should I do if I get a searchset where one or more resources is "anomalous"?
Is this a valid reduction of your initial question?
René Spronk (Jan 18 2021 at 16:51):
effectively that's the same problem, but yes, it could also be a searchset. And one can support subsequent GETs, with label to indicate that ihe data doesn't follow normal quality guidelines. Servers are likely to receive data from clients that may, or may not, be conformant to one or more known/unknown profiles. (Yes one can agree to only support a limited set of profiles, but this severely limits ones options)
Vassil Peytchev (Jan 18 2021 at 17:18):
That is why I asked what the definition of "anomalous" is. If it means "non-conformant for a particular profile", but still a valid resource according to the base specification, then the question becomes, "how do I tag a resource as not conformant to my declared capability statement?"
Is that a fair description?
Even then, I think this can only go as far as an optional capability, and not the expectation that any particular FHIR server would serve resources that do not correspond to their capability statement. So you have the secondary question, if the server changes the data to fit their capability statement, how can they indicate what the original data was (John suggests provenance).
René Spronk (Jan 19 2021 at 07:35):
Definitely provenance. But that wasn't the focus of my question: if a server is bound to a specific set of business rules, and hence an x number of FHIR profiles, and it receives/ingests something that doesn't conform, and can't be automatically made to conform, how would on (as a FHIR server) identify that 'please note, fields x, y and z are non-conformant', so the data can be patched during a subsequent human review process? A security tag would indicate unreliability/incompleteness, but it wouldn't tag fields x, y and z.
John Moehrke (Jan 19 2021 at 13:26):
Given the conditions you have outlined, I would expect it to reject that data. I recommend Postel's Law be applied rather than rejecting.
Joel Schneider (Jan 19 2021 at 16:29):
It might be possible to express the human review and data patching process as a workflow.
Sean Mahoney (Jun 17 2021 at 13:34):
How to know if a code system (and resulting valueset) is case sensitive?
The valueset I am trying to use is the All-languages http://hl7.org/fhir/R4/valueset-all-languages.html.
https://www.hl7.org/fhir/valueset.html says to check the underlying code system. But I can find the underlying code system.
When I check https://www.rfc-editor.org/rfc/rfc5646.txt
it has the text: "Modified the text in Section 2.1 to place more emphasis on the
fact that language tags are not case sensitive."
Does that confirm it is not case sensitive?
Grahame Grieve (Jun 17 2021 at 19:03):
I'd treat that with caution - write language tags in the correct case, and be careful to do so, but not assume all systems will when reading tags
Last updated: Apr 12 2022 at 19:14 UTC
