Storage Service API
Introduction
The Storage Service is available for storing binary file material separately from the FHIR DocumentReference resource that registers the material.
The Storage Service is intended for storing material to be assigned to one or more Patient (citizens), including but not solely information material and guiding material. It is not meant as a general purpose storage facility.
The Storage Service persists material in object based storage but keeps few metadata in a database. Material categories are:
Material Category | Description | Discerned by |
|---|---|---|
citizen specific material content | May contain personal identifiable information and/or sensitive information such as personal health information. | Bound to Patient and EpisodeOfCare |
general material content | Must not contain personal identifiable information or sensitive information. | Not bound to Patient nor EpisodeOfCare |
Security Validation
All operations are protected by context and role validation as described in Access Control in eHealth Services .
Create Operation
When uploading content, values for the patientReference and episodeOfCareReference parameters shall be provided in accordance with the Material Category (see the table above). The service validates that either both or none are present. The references must be in a qualified-versionless format, that is they should have a base-url but not specifiy the resource version.
When values for the
patientReferenceandepisodeOfCareReferenceparameters are present, the content is considered citizen specific and sensitive. The content is therefore encrypted.When no values are present for the
patientReferenceandepisodeOfCareReferenceparameters, the content is considered general and will not be encrypted.
Update Operation
It is important to note that content does not have a history and that an update will effectively overwrite the content already at the URL.
When performing the update, values for the patientReference and episodeOfCareReferenceparameters shall be provided in accordance with the Material Category (see the table above). However, the request will be rejected if the supplied parameters do not match the ones already maintained by the service for the content.
Download Operation
When downloading content it is expected that the accept-header matches the contentType of the stored data. If not, the service will reject the request. This is to ensure that the consuming system (caller) can handle the format of the content to be downloaded.
The service will return the content as uploaded/updated, that is, any citizen specific content encrypted by the service on upload/update is decrypted by the service before being returned to the consuming system. If the material content was encrypted before upload, the service therefore will return it as received (encrypted).