Stream: implementers
Topic: Media storage
Ephraim Kigamba (Oct 06 2021 at 07:02):
Hi
I just started using media and noticed that most of it is saved inline as base64 encoded string even when saved as a Binary resource. I believe we would want to avoid saving big binaries in the database. This applies for both server and client when downloading and uploading. Is there an alternative?
Daniel Venton (Oct 06 2021 at 12:07):
If you are in charge of the database, then you don't have to store the assets into the database. You can write middleware that pulls apart the media resource into database components and file components on ingestion and recomposes them on outgoing. FHIR doesn't dictate how you store information, it dictates how you exchange information.
John Silva (Oct 06 2021 at 12:32):
A related question to ask: "Who has custody of the media/documents that are being sent to your FHIR server?" For example, are these radiology reports whose "authoritative content" is stored in a PACs system or DMS (Document Management System) do you want to maintain a 'shadow copy" of them or not? If so, then maybe you might choose to store a reference to them in FHIR and let the external system manage the custody and life-cycle of them.
Daniel Venton (Oct 06 2021 at 13:50):
If I understand correctly: A user PUTs a media resource onto your FHIR server. That media resource contains a URL to a DMS.
-
Do you (the server) have credentials to access the file?
If No, the only choice you have is to maintain the url (see 2). If yes, do you "inline" the remote file in order to satisfy 2. -
Does another user of your system have permission to GET the media resource ALSO have access to retrieve the document from the DMS? Do they have to?
If you can't expect the user to have access to the DMS, does the server fetch the file JIT to inline it in the media resource or pass the URL and let the user deal with access to DMS? -
If the DMS decides to life-cycle them out (obsolete them) what happens to your media resource?
I can't answer these questions for you, you have to look at your solution and decide how you are going to handle each scenario. My suggestion is to make a shadow copy, that way you aren't reliant on another system to maintain the document on your schedule or your changing permissions, or your users access to DMS. If the DMS is the system is the one that PUT the resource onto you originally, perhaps the DMS should PATCH or DELETE your system as appropriate (if you so allow).
Ephraim Kigamba (Oct 07 2021 at 12:02):
Thanks @Daniel Venton
Last updated: Apr 12 2022 at 19:14 UTC
