FHIR Chat · data type of "created" element in Basic · implementers

Stream: implementers

Topic: data type of "created" element in Basic


view this post on Zulip Hedrie Cid Díaz (Nov 27 2018 at 21:05):

We are using Basic resource type to support Notes. But we are surprised because created element isn't a datetime. It is expecting a date. Why?

view this post on Zulip Lloyd McKenzie (Nov 27 2018 at 23:21):

That's the level of detail most other resources use

view this post on Zulip Lloyd McKenzie (Nov 27 2018 at 23:21):

The consensus in the community seems to be around using DocumentReference for notes, with small notes captured using Observation.

view this post on Zulip Hedrie Cid Díaz (Nov 28 2018 at 18:44):

Thanks for your answer. We will use the resource type you are suggesting.

view this post on Zulip Hedrie Cid Díaz (Nov 29 2018 at 21:03):

We were reviewing DocumentReference but we are not sure if it's the best resource to represent our notes since they are plain text and don't have a hard copy stored elsewhere. About the Observations, as you say they can only be used in very specific cases for small notes. So, what is the best way to represent these more extensive plain text notes?

view this post on Zulip Lloyd McKenzie (Dec 11 2018 at 00:09):

DocumentReference can point to a "contained" attachment. @Brett Marquard can you provide more guidance?

view this post on Zulip Brett Marquard (Dec 11 2018 at 13:03):

The best place to read up on storing retrieving clinical notes is in the Argonaut Clinical Notes implementation guide. We didn't end up using observation, and I am not aware of using observation for notes unless it's for a specific observation.

view this post on Zulip John Moehrke (Dec 11 2018 at 14:00):

DocumetReference uses the datatype Attachment. Attachment has two methods: .url which usually points at a Binary (but could be anything), and .data that holds base64ed copy of the attachment. For the reader of a DocumentReference, the .data will need to be expanded; where as the url can be retrieved and that retrieve supports http negotiation. Thus you have options.
As with all FHIR resources the degenerate minimal form is very small. The metadata elements are there for when that functionality is needed.

view this post on Zulip John Moehrke (Dec 11 2018 at 14:47):

We were reviewing DocumentReference but we are not sure if it's the best resource to represent our notes since they are plain text and don't have a hard copy stored elsewhere. About the Observations, as you say they can only be used in very specific cases for small notes. So, what is the best way to represent these more extensive plain text notes?

There is no expectation that a DocumentReference has anything to do with hard copy stored elsewhere. A Binary can hold very small or very large amount of data. So it seems reasonable to use of DocumentReference to minimally describe (metadata) your clinical note, like the Argonaut spec describes, and a Binary holding the note.


Last updated: Apr 12 2022 at 19:14 UTC