FHIR Chat · DocumentReference dates · argonaut

Stream: argonaut

Topic: DocumentReference dates


view this post on Zulip Jay Lyle (Mar 06 2019 at 14:56):

I am slightly confused by doc ref dates.

DocumentReference.created - seems clear until you read the Comments:
"This is the creation time of the document, not the source material on which it is based."
Should "not the source material on which it is based" be deleted? It seems to blur an otherwise clear boundary.
DocumentReference.indexed - clear: when the reference resource was created.
DocumentReference.content.attachment.creation unclear: the attached document, or the attachment serialization? (not critical for me)
"The date that the attachment was first created."
DocumentReference.context.period clear: period of care documented
DocumentReference.context.encounter.period clear: period of care documented

I plan to use DocumentReference.created for the document reference date.

VistA: "This is the Date (and time) by which the clinician will reference the document. For Progress Notes, this will likely be the date of the provider's encounter with the patient. For Discharge Summaries, it will correspond to the Discharge Date of the Admission referenced in the document. (If there is no Discharge Date when dictated, it will correspond to the dictation date of the record instead.) In all cases, this is the date by which the document will be referenced and sorted."

view this post on Zulip John Moehrke (Mar 06 2019 at 15:04):

some of this has been fixed in later versions of FHIR. Not much we can do to older DSTU or STU.. they were just for trial use...

view this post on Zulip John Moehrke (Mar 06 2019 at 15:08):

that said... the .created was intended to track the lifecycle creation of the DocumentReference... which might be late than the document bits. However even today the attachment.creation is not queryable, so in IHE I have dictated that .created should be the same as attachment.creation; leaving a gap for those that want to know a difference in time between when the document bits were created and when it was published.

view this post on Zulip John Moehrke (Mar 06 2019 at 15:08):

this because document bits creation date is more important than publication date... at least that is the comments received at IHE on the topic.

view this post on Zulip John Moehrke (Mar 06 2019 at 16:56):

in DSTU2... yes there is two redundant places to hold the date that the document bits were created. this redundancy was noticed and corrected after DSTU2.

view this post on Zulip Brett Marquard (Mar 06 2019 at 17:34):

A similar item about querying using context.period GF#20123 will be discussed on Structured Documents tomorrow

view this post on Zulip John Moehrke (Mar 06 2019 at 21:49):

A similar item about querying using context.period GF#20123 will be discussed on Structured Documents tomorrow

That is already supported. look at the 'period' query parameter . Been there since DSTU2.

view this post on Zulip Brett Marquard (Mar 06 2019 at 22:41):

sure, question is about requiring in the profile.

view this post on Zulip John Moehrke (Mar 07 2019 at 13:45):

ah, right sorry to miss the scope. in IHE MHD, I had already included it and a large number given XDS basic query. Much more, but specific use-case drove this: patient, status, identifier, date, author, category, type, setting, period, facility, event, security-label, format, and related.

view this post on Zulip Brett Marquard (Mar 07 2019 at 14:11):

how well supported are all those searches? In US core we have added very minimal based on feedback

view this post on Zulip John Moehrke (Mar 07 2019 at 14:33):

well, the IHE target audience is slightly different. MHD is primarily used as an API to an XDS or XCA environment; where those all map to one query type. In that context they are thus well supported. MHD can be used as simply an API to an EHR, where for historic documents these query parameters are not hard to support, and where the dominant result is just one onDemand entry for which the parameters are of little value.
Period is a common use-case, when looking only at a specific time-range in the past; usually done for coverage or business-rules based investigations. Sometimes for clinical use, when the patient can't recall where treatment happend, but does know when; so a nationwide search with a period is useful to find a discaharge summary from the one place that has documents during that time period.


Last updated: Apr 12 2022 at 19:14 UTC