FHIR Chat · DocumentReference date on a write · argonaut

Stream: argonaut

Topic: DocumentReference date on a write


view this post on Zulip Drew Torres (Jul 01 2020 at 15:21):

I know we don't provide much guidance on writes, but how do you feel if DocumentReference.date was ignored on write and instead is defaulted by the system? Does that meet the spirit of must support?
cc: @John Moehrke

view this post on Zulip John Moehrke (Jul 01 2020 at 15:28):

if it is populated, it must be kept as the client filled it. right? If the client doesn't know it, then it should be allowed to be left empty. This would be the spirit of the IHE flavor of MS (aka R2 or RE)

view this post on Zulip Drew Torres (Jul 01 2020 at 15:46):

I mean the issue here is that the field is defined as the date the indexing system index the document.... Our indexing system date is different.

view this post on Zulip Drew Torres (Jul 01 2020 at 15:46):

I think FHIR does allow business rules allow us to overwrite the field. I believe @Grahame Grieve even said detecting that you don't support a value and rejecting the data meets the spirit of Must Support.

view this post on Zulip Drew Torres (Jul 01 2020 at 15:47):

I was more curious about the definition of the field.

view this post on Zulip Drew Torres (Jul 01 2020 at 15:47):

If someone tries to pass in a date it seems like we should be overwriting it.

view this post on Zulip Vassil Peytchev (Jul 01 2020 at 16:12):

My first thought was that since DocumentReference was created to match the IHE Document Entry metadata, it would seem that DocumentReference.date is supposed to match DocumentEntry.creationTime, which is the time stamp of the document, not the index. Looking at DocumentReference.content.attachment though, it is clear that attachment.creation is the equivalent of DocumentEntry.creationTime.

GIven the above, it seems to me that a RESTful CREATE of a DocumentReference must populate the DocumentReference.date with the instant when the resource was created (regardless of what was provided in the body of the POST) unless somehow there is a legitimate reason to leave it blank and still satisfy "must support".

view this post on Zulip John Moehrke (Jul 01 2020 at 18:48):

The .date element was not added for the XDS reason. And early revisions did imply that it was related to indexing. I think the intention of the value is to indicate when the DocumentReference was first available. I think the idea was that this would lead to an understanding that the DocumentReference may lag being created from the date that the content itself was created.

view this post on Zulip John Moehrke (Jul 01 2020 at 18:49):

when one is knowing that this is creating a first DocumentReference, then yes that is the instant of creation... but I wonder about where the client knows that this DocumentReference was created elsewhere and it is just now being imported into the new system. Thus it is not really being just now first created.

view this post on Zulip John Moehrke (Jul 01 2020 at 18:58):

in XDS the distinction is clear... there is different client compliance requirements for a new entry vs an import request


Last updated: Apr 12 2022 at 19:14 UTC