Stream: implementers
Topic: changing resources
David Hay (Oct 03 2017 at 20:12):
What strategy are PMS/EHR vendors using when providing a FHIR interface to their data, where the backend data may change between invocations. For example, a Patient query endpoint where the demographic details may change? Are you using versions, some kind of tag to indicate that the resource may be different is invoked again or neither?
Jenni Syed (Oct 05 2017 at 17:52):
@David Hay Can you clarify the concern or use case?
Jenni Syed (Oct 05 2017 at 17:52):
In general, all data can change, FHIR or not, after you query/retrieve
Jenni Syed (Oct 05 2017 at 19:03):
We do use the meta.versionId in our FHIR resources. If it's different than the last time you queried, something has changed.
David Hay (Oct 05 2017 at 22:24):
Hi Jenni - I think you answered my question - ie it sounds like you track the changes specifically supporting versioning... The context of the question was what if you are generating resources off of a data store but not tracking versions explicitly? ie the the contents of a given resource could be different on subsequent invokations? How best to let the consumer know that subsequent calls mag give different results? a tag of some sort or a random version that can't subsequently be retrieved? Or maybe it doesn't matter as the consumer should just know that it could be different...
Rob Hausam (Oct 06 2017 at 00:36):
I think the latter ("the consumer should just know that it could be different") is what the thought is for servers that don't support versioning, David. At least that's my take.
Brian Postlethwaite (Nov 10 2017 at 11:47):
those that don't maintain version histories, but do track a last modified date can put that in the version id field, and get the same behaviour (they just can't retrieve the older versions)
Last updated: Apr 12 2022 at 19:14 UTC
