Stream: implementers
Topic: Upload attachment
Michael Albert (Nov 03 2020 at 12:45):
We have developed an application that stores it's data in the HAPI FHIR server. Right now, for development and testing purposes, we are storing images right in the 'data' field of an Attachment resource that is referenced by a Media resource. I read that the data field could also hold a link to the raw data of the attachment (the image in this case). How would the upload process be realized for the images? Is there already an API that stores the files in the filesystem and creates a link that can be stored in the resource?
Lin Zhang (Nov 03 2020 at 13:23):
Large object datatype supported by your db.
Lin Zhang (Nov 03 2020 at 13:28):
Store the image data (base64) and the containing resource instance in such a field?
John Moehrke (Nov 03 2020 at 14:00):
Put your object in a FHIR Binary resource, and point at that Binary using .attachment.url
John Moehrke (Nov 03 2020 at 14:00):
note, you should move away from Media and toward use of DocumentReference as Media is being retired in preference for DocumentReference.
Michael Albert (Nov 03 2020 at 17:00):
So .. if I store the image data inline (as base64) or as FHIR Binary would the backend store that efficient in the file system or would I slow down my database because it has to handle large amounts of data? We have a usecase where lots of images will be stored and in near future videos should also be stored. Is a FHIR Binary the way to do that?
Lloyd McKenzie (Nov 03 2020 at 19:41):
FHIR Binary stores and usually transmits the data as 'raw' - i.e. not base64 encoded. (And can be transmitted compressed if your HTTP request asks for it that way.)
Last updated: Apr 12 2022 at 19:14 UTC
