Stream: implementers
Topic: indicating error in enrichment service
David Hay (Sep 05 2017 at 02:33):
We have an environment where resources can be 'enriched' by means of an external service at read time. For example, a terminology lookup that 'normalizes' a condition.code, or lookup a provider details based on an identifier . If the service is unavailable at the time of querying, we want to indicate that to the client, while returning the data that we have. This could occur on both a search or read of a single resource. What's the best way to do this? A resource tag (like 'subsetted'?) . An operationOutcome would give more detail, but doesn't apply for a single resource read - and in any case, only some of the resources in the query may have been effected...
Richard Townley-O'Neill (Sep 05 2017 at 03:26):
a tag of "unenriched" ? 
Lloyd McKenzie (Sep 05 2017 at 03:29):
On a query response, I'd probably provide an OperationOutcome. Not sure about what to do with a Read though
David Hay (Sep 05 2017 at 05:31):
trouble is we still need something on each resource, as not all may have been effected. And we did think of a custom tag :)
John Moehrke (Sep 05 2017 at 12:08):
It does seem like a tag to indicate that the data was enhanced / enriched is possibly useful. How would you expect to represent this enrichment with Provenance? I would hope that this enrichment is represented by a version... and that version would have a Provenance. Even here, I don't see a good code for what type of Provenance activity or agent you have. This seems like an important gap. Might need FHIR-I, Vocab to give Security some guidance. Presumably some vocabulary value exists to indicate computer aided enrichment. It is just not in my known vocabulary.
Amit Cudykier (Jun 23 2021 at 19:59):
I see this post is kind of old but maybe FHIR has better ways to do it now :) . I am facing a similar task. We also thought of using a tag to indicate the resource was "enriched" . My question is, what is the proper way to indicate what elements were enriched by the external service?
For example, the response did not include the patient address, but my external service was able to fetch the address and add it to the FHIR response. I am not sure if a Provenance resource might be helpful, it does feel like an extension is a way to go.
Lloyd McKenzie (Jun 25 2021 at 16:44):
As an immediate response, you would echo back what was actually stored (allowing the client to see what had changed/been enriched) or an OperationOutcome with warning/information messages noting what changes were made.
After the fact, the only way to see where data came from is Provenance. I believe there are some standard extensions for allowing details to be tracked on a resource element level rather than a "resource as a whole" level. @John Moehrke?
John Moehrke (Jun 25 2021 at 16:58):
@Lloyd McKenzie there is a FHIR-I approved CR, but it has not yet been applied and not enough details in the CR for me to understand what the plan is. https://jira.hl7.org/browse/FHIR-21284
Amit Cudykier (Jun 25 2021 at 18:23):
Thank you @Lloyd McKenzie . How will you handle the case where the client is trying to READ a FHIR resource? and you want to enrich data
I am not really sure, is it appropriate to send back a bundle resource with the resource that the client wanted to read and the operation outcome resource (I do not think so)?
Amit Cudykier (Jun 25 2021 at 18:31):
@John Moehrke thank you for sharing the CR. I will monitor it. I am new to the CR process. What are the next steps to move this CR forward? We are happy to help however we can.
We would love to develop a solution for our use case endorsed and accepted by the community.
Lloyd McKenzie (Jun 25 2021 at 21:05):
FHIR presumes that if data changes, the _lastUpdated timestamp changes and the version changes. The 'version' and _lastUpdated are important to managing update collisions and having polling work. So either you need to update your stored copy at the time you receive the new information or at the time the original POST comes in. Doing it at time of read is likely to cause grief because every time someone looks at the data it's treated as if it's changed.
Last updated: Apr 12 2022 at 19:14 UTC
