Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-25205

Unclear where to capture different creation times in DocumentReference/Attachment

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Applied (View Workflow)
    • Medium
    • Resolution: Not Persuasive with Modification
    • FHIR Core (FHIR)
    • STU3
    • Orders & Observations
    • DocumentReference
    • Hide

      The multiple instances of attachment are not intended for different versions of a document. They are intended only for different formats of the same content. Different versions would be represented by multiple DocumentReference, with relationships between the versions using DocumentReference.relatesTo

      Thus, add clarification in Implementation Notes to the use of multiple instances of DocumentReference and .relatesTo to support versions of a document.

      Add a note in .content definition that emphasizes that multiple instances are not to be used for different versions.

      Show
      The multiple instances of attachment are not intended for different versions of a document. They are intended only for different formats of the same content. Different versions would be represented by multiple DocumentReference, with relationships between the versions using DocumentReference.relatesTo Thus, add clarification in Implementation Notes to the use of multiple instances of DocumentReference and .relatesTo to support versions of a document. Add a note in .content definition that emphasizes that multiple instances are not to be used for different versions.
    • John Moehrke / Rob Hausam: 8-0-5
    • Clarification
    • Non-substantive

    Description

      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.

      Attachments

        Activity

          People

            john_moehrke John Moehrke
            morten Morten Ernebjerg
            John Moehrke
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: