This issue asks for a clarification of the use of the field Attachment.creation and how it relates to the use of Attachment in the DocumentReference.content.attachment field. For background see, this FHIR Zulip topic: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Removal.20of.20DocumentReference.2Ecreated.20in.20R4

To illustrate the problem, consider the following sequence of events:

1. On Monday, a doctor in hospital A writes up a hospital discharge letter, prints it, and gives it to the patient

2. On Tuesday, the patient is admitted to hospital B and brings the discharge letter which is scanned and stored in a PDF file

3. On Wednesday, the IT system of hospital B internally creates an Attachment object including the PDF file as data

4. On Thursday, the IT system of hospital B creates a DocumentResource containing the attachment object (containing the PDF).

(3 and 4 may in practice rarely be separated, so 3 is mainly added to have "maximum separation").

To store these various dates, the following two fields are available (AFAIK): Attachment.created and DocumentReference.date. In STU3, there was additionally the field DocumentReference.created, but it was removed in R4. The following seems unclear:

1. Which of the four times above can be captured at all (in the context of a DocumentReference)?

2. In which fields should the various times be captured?

In case the conclusion is that the first time (Monday) - the time the information was first put down by a human being (or machine) - cannot be captured in a DocumentReference with an attachment (and no further resources): it might be worth considering (re)introducing a field to allow this (cf. DocumentReference,created in STU3). I see the following arguments:

1. This initial creation time could be important for users in order to judge the relevance of a given document. Hence, it would be valuable to be able to communicate it (if available) to the user without requiring her to download and inspect the attachment itself.

2. This initial creation date time may be very different from the other times and hence hard to infer from them (consider the case where old paper records are scanned and added to an electronic repository).

3. Although this information can perhaps be captured with a separate Provenance resource, it adds an extra burden on the clients (having to find a retreive another resource) and requires the client to know more about the system holding the information.

We are concretely dealing with a usecase (non-IHE) where the electronic artifacts may be created long after the information contained was first created and where such a field would therefore be very useful.