Element & Attribute Descriptions
The following table documents all the elements and attributes of the Distribution Envelope.
| Name | Cardinality | Data Type |
Description |
|---|---|---|---|
| header | 1..1 | Distribution envelope header | |
| @service | 1..1 | URI | The service under which this transmission is sent. |
| @trackingid | 1..1 | UUID | A unique identifier for this transmission. This is a UUID generated by the sender that is used as a tracking identifier for the transmission. |
| addresslist | 0..1 | A list of recipient addresses, which indicate the end-to-end business destination of the distribution. | |
| address | 1..* | A business delivery address URI. | |
| @type | 0..1 | String | The format of address used. (default= "2.16.840.1.113883.2.1.3.2.4.18.22", which indicates an ITK address format). Other addressing formats are supported, but these are generally used by local agreement. For sending an inter-organisational transmission, the default ITK address format should be used. |
| @uri | 1..1 | URI | The actual business delivery address for this transmission. Further addressing guidance is given in the latest version of the "Interoperability Toolkit Addressing and Routing Requirements" |
| auditIdentity | 0..1 | An auditable reference for the sender. Examples could include an ITK format address, a spine smart-card authentication etc..This attribute is used by middleware to audit the sending of transmissions. | |
| id | 1..4 | Up to 4 levels of identity are allowed to identify the sender. For example the 1st identity could be a person, 2nd their role, and 3rd the responsible organisation. | |
| @type | 0..1 | String | The format of identity used. (default= "2.16.840.1.113883.2.1.3.2.4.18.27", which indicates an ITK identity format). Other auditIdentity formats are supported, but these are generally used by local agreement. For sending an inter-organisational transmission, the default ITK identity format should be used. |
| @uri | 1..1 | URI | The actual audit identification |
| manifest | 1..1 | Technical details of each payload. It is mandatory that each payload has a Manifest entry in the distribution envelope. | |
| @count | 1..1 | Integer | A count of the number of payloads being described. This must match attribute payloads.count |
| manifestitem | 1..* | There must be one manifestitem per payload. | |
| @id | 1..1 | IDREF | The id of the payload being described. This must match the payload.id attribute. |
| @mimetype | 1..1 | String | The mime type of the payload. For example, a CDA document will be of type text/xml |
| @profileid | 0..1 | URI | The identification of a description of the versionable artefacts of a payload. Not all payloads will have a profileId – for example an image may not have any versionable artefacts. For more structured payloads such as a CDA document, this will document versionable payload artefacts such as vocabularies and templates. |
| @metadata | 0..1 | Boolean | A flag to indicate whether the payload being described is the metadata content payload (default=”false”). Metadata will be in an IHE conformant format. |
| @compressed | 0..1 | Boolean | A flag to indicate whether the payload is compressed (default=”false”). The only supported compression routine is gZip |
| @base64 | 0..1 | Boolean | A flag to indicate whether the payload is in base64 format (default=”false”). |
| @encrypted | 0..1 | Boolean | A flag to indicate whether the payload is encrypted (default=”false”). |
| senderAddress | 0..1 | The sender’s address. This provides an address for acknowledgements | |
| @type | 0..1 | String | The format of address used. (default= "2.16.840.1.113883.2.1.3.2.4.18.22", which indicates an ITK address format). Other addressing formats are supported, but these are generally used by local agreement. For sending an inter-organisational transmission, the default ITK address format should be used. |
| @uri | 1..1 | URI | The actual delivery address for the acknowledgement. This is the return address for infrastructural acknowledgements for example. |
| handlingSpecifications | 0..1 | An extensible list of handling requirements – such as send business ACK, interaction IDs etc.. This list is expected to grow over time. Each specification and the values it can take will be documented outside this document. | |
| spec | 1..* | A set of key / value pair to represent a handling specification | |
| @key | 1..1 | URI | Specification Key (such as send business ACK). For example, to request a Business Acknowledgement “urn:nhs:itk:ns:201005:ackrequested” |
| @value | 1..1 | String | Value for the key (such as “true”) |
| payloads | 1..1 | The actual payloads. A variety of content types can be carried, as described by the manifest. | |
| @count | 1..1 | Integer | A count of the number of payloads (must match manifest.count) |
| payload | 1..* | Payloads | |
| @id | 1..1 | ID | The unique identifier of a payload (must match manifestItem.id) |
| @filename | 0..1 | String | The file name under which the extracted payload should be saved |