FHIR Chat · Recording resource creation date and lastUpdated · implementers

Stream: implementers

Topic: Recording resource creation date and lastUpdated


view this post on Zulip Muhammad Abubakar Ikram (Nov 15 2018 at 12:23):

If someone has to store the resource creation date without implementing versioning then how to store?

by reading lastUpdated gives the meaning that when a resource was last updated using the "Update" FHIR operation but it actually refers to when the version of a resource lastly updated.

using lastUpdated as creation date could be a workaround! but I am surprised why we don't have creation date in "Meta" datatype ?

1. The lastUpdated might be changed to lastVersionUpdated

2. "Meta" datatype might also have creation date

view this post on Zulip Lloyd McKenzie (Nov 15 2018 at 13:03):

Is creation date the creation date on this server or the creation of the original record? Have you considered using Provenance?

view this post on Zulip Muhammad Abubakar Ikram (Nov 15 2018 at 13:48):

The creation date of a resource when a resource was created in a server.

view this post on Zulip Lloyd McKenzie (Nov 15 2018 at 14:45):

If you don't support _history, then you're looking at either Provenance or an extension

view this post on Zulip Jose Costa Teixeira (Nov 19 2018 at 12:18):

Has this been / would this be discussed in Infrastructure as a core optional element?

view this post on Zulip John Moehrke (Nov 19 2018 at 14:04):

This is why we have Provenance... I don't think we should duplicate the function of Provenance bluntly in all Resources.

view this post on Zulip Muhammad Abubakar Ikram (Nov 19 2018 at 15:26):

So for just storing the creation date of a resource, creating another resource! isn't it too complex for a small operation?

Provenance is very good to have granular record of activities about the resources. But I think a resource should have basic metadata as every resource already have some fields so why can't we have creation date in Meta datatype?

view this post on Zulip John Moehrke (Nov 19 2018 at 15:47):

so it is okay to duplicate some elements of Provenance... This is a decision each Resource makes. Some resources do need the creation time, and they have an element for that. See the W5 report http://build.fhir.org/fivews.html#mappings

view this post on Zulip Muhammad Abubakar Ikram (Nov 19 2018 at 16:23):

Awesome! exactly what I need in some resources especially in Patient. the recorded element

I think which resource needs the creation time is the requirement and decision of the consumer, so what I would say that recorded element may move to the Meta datatype

view this post on Zulip Lloyd McKenzie (Nov 19 2018 at 20:22):

Whether it gets added to core depends on whether we think it's something that most systems will support for all resources. So far, the answer to that has been "no". But it's probably reasonable to define an extension.

view this post on Zulip Brian Postlethwaite (Dec 03 2018 at 11:15):

I am also stuck between these 2 extremes, the cases where you just have minimal data, then it keeps going till you have all the data of a provenance or auditevent resource. My use cases has the user that created the original resource, and then the current update user.

view this post on Zulip Tim Berezny (Dec 10 2018 at 17:00):

Same boat here (nice and simple with meta vs. more complicated with provenance). The other use case that i think might justify having created in the meta is that search by "lastUpdated" and "Created" (and... comparing if the last update was in fact a create), are fairly common use case for us.

Once i need to get into "last updated by", "created by", etc... then provenance starts becoming justified.


Last updated: Apr 12 2022 at 19:14 UTC