UKCore Hackathon Supporting Guide

This guidance is under active development by NHS England and content may be added or updated on a regular basis.

Traditional Document Exchange

Pattern

The document and document metadata is sent directly to the recipient.

send-document

Pros

  • Simple to establish
  • Mimics traditional transfer of care processes
  • Like for like replacement of fax and email with more automation support.
  • Independent of http or MESH transports
  • Compatibility with NHS England projects including Virtual Wards, Transfer of Care and GP Connect Send Document

Cons

  • Concurrency Issues (document is correct at point of creation, corrections or updates can make interaction complex)
  • No UK standards. Future work on UKCore-DocumentReference (document metadata) should answer part of this.
  • Document duplication, which one is correct?
  • Suited for point to point sharing only

FHIR Technical Framework Options

This pattern may be sent in several ways in FHIR. They overlap especially around the content of the FHIR resources. They should have low technical overhead with only minor amendments required.

RESTful API

The document metadata and document are individually to the recipient. This would involve the following interactions.

It is likely this would need to be complemented with patient demographic interactions, such as searching for an existing patient record or adding a new record.

Transactions

This contains the same interactions listed in the previous section and is sent in a single interaction using the FHIR Bundle resource.

  • POST / to send a collection of the RESTful interactions. See demonstration POST /

This is the recommended option in IHE-MHD ITI-65

Messaging

This has a defined set of resources and for Sending Documents, this is likely to include FHIR DocumentReference, Binary and Patient. In FHIR this is defined in a FHIR MessageDefinition i.e. documents

It is sent via the following interaction.

back to top