Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

FHIR Receiver Requirements

Architectural Layers ensures that fault handling is handled in line with the layer that the fault occurs. This means that fault processing can halt and report at the appropriate point of “fault/error”, all errors are regarded as fatal and there will only be a maximum of 2 Message Responses, each containing a maximum of one Response Code.

Recipient – Header Validation

Receiving systems must apply basic header validation to check that the system is the intended recipient.

ID Description Sender Receiver
FHIR-RR-01 The system MUST validate 'recipient' information contained in the Document 'header' information to check that the identified recipient organisation, or person is supported by the system. N Y
1 The system MUST where requested either :
  • Reject the message with an appropriate response code.
  • Accept the message and pass it through to the clinical application for processing
NB The sending of responses is controlled using the appropriate flag in the ITK3 MessageHeader- ITKMessageHandling extension on the incoming FHIR document bundle.

Recipient – Patient Validation

ID Description Sender Receiver
FHIR-RR-02 Upon receipt of a FHIR document for a patient whose identifiers are not found in the receiving system, the system MUST send a response back to the sender with an appropriate response code. N Y
NB The sending of responses is controlled using the appropriate flag in the ITK3 MessageHeader- ITKMessageHandling extension on the incoming FHIR document bundle.

Coded Clinical Content

These are common, agreed structures for clinical data representation, and are the cornerstone of clinical data interoperability.

ID Description Sender Receiver
FHIR-RR-03 A system SHOULD process coded entries as defined in the Message Specification. N Y

Patient Transfer Specific Requirements

ID Description Sender Receiver
FHIR-RR-04 If the patient has been moved from this care setting (e.g. they have been 'deducted' or a GP2GP record transfer has recently taken place), the system SHOULD following clinical review of the document, notify the new care setting. N Y

Duplicate Documents

The receiving system must be able to check for duplicates.

ID Description Sender Receiver
FHIR-RR-05 The system SHOULD perform 'duplicate document' checks on all received messages N Y
1 If the document ID is a duplicate the system MUST:
  • NOT forward the document to the host clinical application
  • Log the fault in the system or application logs.
2 If a duplicate is found, the system MUST return a response with an appropriate code indicating 'Duplicate Document ID received'.
3 The system MUST flag the item in the audit log indicating that it is a duplicate.
Tags: fhir

All content is available under the Open Government Licence v3.0, except where otherwise stated