Stream: implementers
Topic: DocumentReference.Date
Drew Torres (Nov 21 2018 at 15:49):
What is the assumption around date? http://build.fhir.org/documentreference-definitions.html#DocumentReference.date Does this represent the date the DocumentReference was created? If that is the case, does that mean the actual content of document can have a different date for creation? I am trying to understand how how this maps to XDS where the registry may have 1 date vs the document having another date. @John Moehrke @Brett Marquard
John Moehrke (Nov 21 2018 at 15:50):
see the mapping http://build.fhir.org/documentreference-mappings.html#xds
Drew Torres (Nov 21 2018 at 15:52):
So it maps to DocumentEntry.creationTime. How does this map int eh onDemand world?
Drew Torres (Nov 21 2018 at 15:52):
On demand documents wouldn't have that date. Is my assumption correct?
John Moehrke (Nov 21 2018 at 15:54):
The DocumentReference resource is owned by FHIR community, so it has drifted away from pure XDS mapping. I would recommend that the document creation date/time is to be found in the attachment.creation element. The .date element seems to be about the DocumentReference resource itself.
John Moehrke (Nov 21 2018 at 15:55):
Correct, an on-demand document has not yet been created.
John Moehrke (Nov 21 2018 at 15:59):
as always... this resource in FHIR is STU, and the MHD profile is Trial Implementation... so please try it, and give feedback on how well it worked. Feedback is critical to "Trial" status...
Drew Torres (Nov 21 2018 at 16:01):
Thank you sir! This is the information I was looking for. The mapping was great!
John Moehrke (Nov 21 2018 at 16:08):
I have entered GF#19685 to correct the xds mapping for creationTime.
Drew Torres (Nov 21 2018 at 16:09):
With that change would date then be the submission date/time?
John Moehrke (Nov 21 2018 at 16:20):
with that change there would be no use for the .date element.
Drew Torres (Nov 21 2018 at 16:21):
At least for XDS maybe, but I feel like the .date would be be appropriate to represent when the pointer was created vs. when the content was create.
John Moehrke (Nov 21 2018 at 16:21):
I stopped short of recommending that the .date element be eliminated, although I might argue that during review and approval of the change request
Drew Torres (Nov 21 2018 at 16:22):
Please don't. :-D
John Moehrke (Nov 21 2018 at 16:23):
in STU3. The .indexed element existed for that purpose, and a .created element for the date of the document. But even at STU3 there was the duplicate attachment.created element.
Drew Torres (Nov 21 2018 at 16:23):
I still think it has a place. The example would be for system that support multiple representations of the same document.
Drew Torres (Nov 21 2018 at 16:23):
Like we have 1 pointer to multiple format of the same document. (PDF, RRTF, HTML, etc)
John Moehrke (Nov 21 2018 at 16:26):
the concern I would have is that in XDS a documentEntry can be registered in multiple submissionSets. It would be hard to determine which of those was the 'first'. So it would seem to me best to leave it empty in an XDS environment.
Drew Torres (Nov 21 2018 at 16:27):
Agreed on that point. In XDS it may not make sense anymore.
Drew Torres (Nov 21 2018 at 16:27):
I was advocating for support for the non-XDS flows.
John Moehrke (Nov 21 2018 at 16:27):
and it is unusual in a REST environment to have creation time, as everything in REST is based on lastUpdated
Drew Torres (Nov 21 2018 at 16:28):
Well that opens a new can of worms. Since, CCDs have their own concept of version.
John Moehrke (Nov 21 2018 at 16:28):
there are discussions of adding to the Domain resource a creationTime in addition to the lastUpdated. but that would be universal, not special for DocumentReference
Drew Torres (Nov 21 2018 at 16:28):
It defines a version as an incrementing number, where FHIR defines version completely differently.
John Moehrke (Nov 21 2018 at 16:30):
but the concept of versioned in CCD turns into simply an identifier in FHIR. It is just a method of creating unique identifiers for each version. right?
Drew Torres (Nov 21 2018 at 16:32):
That feels weird a little. The identifier should be the same since it is the same document, but just a newer version.
John Moehrke (Nov 21 2018 at 16:33):
in CDA, that is a new document. each revision is a new document.
Drew Torres (Nov 21 2018 at 16:34):
But XDS supported replace document set.
Drew Torres (Nov 21 2018 at 16:35):
At some level there was a "linking" between documents with the same "identifier"
John Moehrke (Nov 21 2018 at 16:37):
That linking is done at the metadata level. In XDS with associations. In DocumentReference with .relatesTo. Each instance is a unique document. The linkage is done in metadata so as to be content agnostic. This same revision tracking can be done regardless of the document format. It can be done even with simple text files, PDF, images, etc.
Last updated: Apr 12 2022 at 19:14 UTC
