NHS Digital has developed a set of generic FHIR messaging components to allow a standard approach to FHIR MessageHeaders and responses across NHS message and document flows in England. These components, along with NHS Digital payload specifications, are part of the ITK3 solution.
The message specification and implementation guide has been published.
These ITK3 payloads will be sent via MESH from sender to recipient and to ensure that senders are clear on the successful receipt or otherwise of their messages, a piece of software, a Test Harness, has been built. Currently, the ITK3 Test Harness simulates the ITK3 responses of a receiving primary care system, but it is intended in future to replicate this for a hospital sending system and multiple other sender and receiver types.
Purpose of the ITK3 Test Harness
The Test Harness is intended to allow FHIR message senders to confirm, for example, whether:
- a message is formatted in valid xml
- a message conforms to the FHIR schemas
- a message payload is valid against the FHIR profiles for the payload
- the message payload conforms to the technical and business rules stated in the payload specification
- the ITK3 header components are valid against the FHIR profiles for the ITK3 Messaging distribution specification
- the ITK3 Header components conforms to the technical and business rules stated in the ITK3 distribution specification
The sender can populate a business and/or technical (infrastructure) response request flag in the message to be sent and, depending on the population of the flag(s) and the nature of the sent message, will receive an appropriate response back from the Test Harness.
The response of the Test Harness will vary from:
- a technical (infrastructure) level response confirming that the message has been successfully received and processed and is valid at the technical level
- a technical (infrastructure) level response confirming that the message has not been successfully processed - the response message will also return an error code stating the problem with the message, for example the xml is invalid
- a business level response confirming that the message has been successful at the business level and the patient has been located on the system of the receiving GP practice
- a business response confirming that the patient is either not known on or is no longer present on the system of the receiving GP practice