NCPI FHIR Implementation Guide
0.1.0 - ci-build

NCPI FHIR Implementation Guide - Local Development build (v0.1.0). See the Directory of published versions

Data Type Profile: DRSAttachment - Detailed Descriptions

Draft as of 2022-08-16

Definitions for the ncpi-drs-attachment data type profile.

1. Attachment
Definition

For referring to data content defined in other formats.

Control0..* This element is affected by the following invariants: ele-1
Comments

When providing a summary view (for example with Observation.value[x]) Attachment should be represented with a brief display text such as "Signed Procedure Consent".

InvariantsDefined on this element
att-1: If the Attachment has data, it SHALL have a contentType (: data.empty() or contentType.exists())
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
must-be-drs-uri: attachment.url must start with ^drs://. A drs:// hostname-based URI, as defined in the DRS documentation, that tells clients how to access this object. The intent of this field is to make DRS objects self-contained, and therefore easier for clients to store and pass around. For example, if you arrive at this DRS JSON by resolving a compact identifier-based DRS URI, the `self_uri` presents you with a hostname and properly encoded DRS ID for use in subsequent `access` endpoint calls. (: $this.url.matches('^drs://.*'))
2. Attachment.id
Definition

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

Control0..1
Typestring
3. Attachment.extension
Definition

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.

Control0..*
TypeExtension
Alternate Namesextensions, user content
Comments

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.

InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
ext-1: Must have either extensions or value[x], not both (: extension.exists() != value.exists())
SlicingThis element introduces a set of slices on Attachment.extension. The slices are unordered and Open, and can be differentiated using the following discriminators:
  • value @ url
4. Attachment.contentType
Definition

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.

Control0..1
BindingThe codes SHALL be taken from Mime Types The mime type of an attachment. Any valid mime type is allowed.

Typecode
Requirements

Processors of the data need to be able to know how to interpret the data.

Example
General:text/plain; charset=UTF-8, image/png
InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
5. Attachment.language
Definition

The human language of the content. The value can be any valid value according to BCP 47.

Control0..1
BindingThe codes SHOULD be taken from CommonLanguages A human language.

Additional BindingsPurpose
AllLanguagesMax Binding
Typecode
Requirements

Users need to be able to choose between the languages in a set of attachments.

Example
General:en-AU
InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
6. Attachment.data
Definition

The actual data of the attachment - a sequence of bytes, base64 encoded.

Control0..1
Typebase64Binary
Requirements

The data needs to able to be transmitted inline.

Comments

The base64-encoded data SHALL be expressed in the same character set as the base resource XML or JSON.

InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
7. Attachment.url
Definition

A location where the data can be accessed.

Control0..1
Typeurl
Requirements

The data needs to be transmitted by reference.

Comments

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.

Example
General:http://www.acme.com/logo-small.png
InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
8. Attachment.size
Definition

The number of bytes of data that make up this attachment (before base64 encoding, if that is done).

Control0..1
TypeunsignedInt
Requirements

Representing the size allows applications to determine whether they should fetch the content automatically in advance, or refuse to fetch it at all.

Comments

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.

InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
9. Attachment.hash
Definition

The calculated hash of the data using SHA-1. Represented using base64.

Control0..1
Typebase64Binary
Requirements

Included so that applications can verify that the contents of a location have not changed due to technical failures (e.g., storage rot, transport glitch, incorrect version).

Comments

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.

InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
10. Attachment.title
Definition

A label or set of text to display in place of the data.

Control0..1
Typestring
Requirements

Applications need a label to display to a human user in place of the actual data if the data cannot be rendered or perceived by the viewer.

Example
General:Official Corporate Logo
InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))
11. Attachment.creation
Definition

The date that the attachment was first created.

Control0..1
TypedateTime
Requirements

This is often tracked as an integrity issue for use of the attachment.

InvariantsDefined on this element
ele-1: All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))