Attachment | Medplum
Base StructureDefinition for Attachment Type
For referring to data content defined in other formats.
Elements
| Name | Required | Type | Description |
|---|---|---|---|
| id | string | Unique id for inter-element referencing Details Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. |
|
| extension | Extension[] | Additional content defined by implementations Details May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
|
| contentType | code | Mime type of the content, with charset etc. Details Identifies the type of the data in the attachment and allows a method to be chosen to interpret or render the data. Includes mime type parameters such as charset where appropriate. |
|
| language | code | Human language of the content (BCP-47) Details The human language of the content. The value can be any valid value according to BCP 47. |
|
| data | base64Binary | Data inline, base64ed Details The actual data of the attachment - a sequence of bytes, base64 encoded. The base64-encoded data SHALL be expressed in the same character set as the base resource XML or JSON. |
|
| url | url | Uri where the data can be found Details A location where the data can be accessed. If both data and url are provided, the url SHALL point to the same content as the data contains. Urls may be relative references or may reference transient locations such as a wrapping envelope using cid: though this has ramifications for using signatures. Relative URLs are interpreted relative to the service url, like a resource reference, rather than relative to the resource itself. If a URL is provided, it SHALL resolve to actual data. |
|
| size | unsignedInt | Number of bytes of content (if url provided) Details The number of bytes of data that make up this attachment (before base64 encoding, if that is done). The number of bytes is redundant if the data is provided as a base64binary, but is useful if the data is provided as a url reference. |
|
| hash | base64Binary | Hash of the data (sha-1, base64ed) Details The calculated hash of the data using SHA-1. Represented using base64. The hash is calculated on the data prior to base64 encoding, if the data is based64 encoded. The hash is not intended to support digital signatures. Where protection against malicious threats a digital signature should be considered, see Provenance.signature for mechanism to protect a resource with a digital signature. |
|
| title | string | Label to display in place of the data Details A label or set of text to display in place of the data. |
|
| creation | dateTime | Date attachment was first created Details The date that the attachment was first created. |