Transport Pattern Mapping

From IHE Wiki
Jump to navigation Jump to search

FHIR-MHD Transport Pattern Mapping Notes

HTTP verbs used for basic operations on a (single) resource in FHIR

  • POST - create
  • PUT - update
  • DELETE - delete
  • GET - read

There are some exceptions to this scheme: the "transaction" operation utilizes POST to create or update a set of resources (resource bundle) atomically.

HTTP headers

As with most REST based APIs, Content-Type and Accept headers are used to process or request a specific representation of a resource. Location can either identify a resource or be a symbolic endpoint in FHIR with specific semantics (Mailbox, Binary).

Mapping of FHIR operations to existing IHE transactions


This operation can facilitate Provide & Register Document Set-b (ITI-41, ITI-42), "Update Document Set" (ITI-57) and "Delete Document Set" (ITI-62) transactions. It can create and update a set of resources (authors, documents) in one transaction:

  • If entry.content is omitted, the resulting operation maps to Register Document Set-b (ITI-42).
  • If refers to an existing resource, it mimicks "Update Document Set" (ITI-57)
  • If entry.deleted specifies a date before now, the entry will be deleted, mimicking "Delete Document Set" (ITI-62). Note that entry.content will also be deleted.

The MHD "Put Document Dossier" (ITI-65) transaction could be mapped in a similar fashion. This would enrich the semantics of this transaction and add support for the creation of multiple resources.


This operation can be used for the current Retrieve Document Set (ITI-43) transaction, although it can only be used for a single resource. The "search" operation might be an alternative.


This operation can be mapped to Delete Document Set (ITI-62), but only works for a single resource.


This operation can be mapped to Update Document Set (ITI-57), but only works for a single resource.


This operation can be mapped to various query transactions.

Open issue: can it be used for Retrieve Document Set - the "Patient" compartment could be used to retrieve all document resources for a given patient (?)


Resources in FHIR can be represented in JSON, XML (application/xml+fhir) and as Binary. Binary content can be specified in JSON using the "data" attribute on "content" objects, containing Base64 encoded data. XHTML content can be conveyed through a "div" attribute on "text" objects. For the XML representation, these are both XML elements. In JSON, the "resourceType" attribute specifies the type of resource (Bundle, Patient,...).

Open issue: it is unclear whether data can be submitted as a separate multipart entry with a (cid) reference in the JSON representation to allow submission of large files and prevent the base64 encoding for inline data.


Operations on sets of resources are performed on resource bundles. In XML these bundles are represented as Atom Feeds (RFC 6721) (mime type: application/atom+xml). The JSON representation (mime type: application/json+fhir; "resourceType": "Bundle") is a custom format that honors logical order in entries, and tries to follow the XML representation where possible.

Symbolic endpoints


Models one way messaging in FHIR. Messages or bundles can be sent to this endpoint. Might be mapped to "Asynchronous Web Services Exchange".


Binary representations can be created, and fetched using a specific location on the resource. Search is not supported for such a resource. The mime type matches the binary content.