Acknowledgement Framework

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

Design overview

Currently, the Acknowledgement Framework only provides guidance for the Messaging paradigm. However, the plan is to provide guidance and support for the Documents and RESTful paradigms in a future version.

Profiles and extension resources used within the Acknowledgement Framework are, by default, derived from UK Core. Where a FHIR asset does not exist in UK Core, then the Acknowledgement Framework will derive from the base International standard.

Response patterns (pre-agreed between two systems)

There is an expectation most use-cases will involve both the sending and receiving systems to be aware of the rules and circumstances that govern when, and how, acknowlegdements are sent and received. For example, System A and System B have been designed and built according to the agreed system rules that for any time a Message is received, then a positive or negative acknowlegdment is sent.



Sender Message Flow Action Receiver
1..1 → Send message payload Payload received
Acknowledgement(s) received Send acknowledgement(s) ← 1..*




Sender Message Flow Action Receiver
1..1 → Send message payload Payload received
Acknowledgement(s) received Send negative acknowledgement(s) ← 0..*




Sender Message Flow Action Receiver
1..1 → Send message payload Payload received
Acknowledgement(s) received Send positive acknowledgement(s) ← 0..*





Response patterns (NOT pre-agreed between two systems)

Although there would likely be very few use cases where both sending and receiving systems cannot agree beforehand their acknowledgement response patterns, the Acknowledgement Framework provides additional functionality to include an extension that states what type of acknowledgement a system expects to receive.



Sender Message Flow Action Receiver
1..1 → Send message payload Payload received
Acknowledgement(s) received Send acknowledgement(s) ← 1..*




Sender Message Flow Action Receiver
1..1 → Send message payload Payload received
Acknowledgement(s) received Send negative acknowledgement(s) ← 0..*




Sender Message Flow Action Receiver
1..1 → Send message payload Payload received
Acknowledgement(s) received Send positive acknowledgement(s) ← 0..*




Sender Message Flow Action Receiver
1..1 → Send message payload Payload received
No acknowledgement(s) received No acknowledgement(s) sent ← 0..0

Multiple acknowledgements

As illustrated in the response patterns diagrams, the Acknowledgement Framework facilitates the abilitity to send multiple acknowledgements.

Further guidance and diagrams will be added specifically for this in the future.


Technical and business acknowledgements

The Acknowledgement Framework provides the ability to return 'technical' and 'business' acknowledgements.

For a 'positive' business acknowledgement, code ok from CodeSystem ResponseType; code information from CodeSystem IssueSeverity; informational from CodeSystem IssueType; and (currently proposed) code BUSINESS_SUCCESS from CodeSystem operation-outcome can be used to specifically imply that the positive acknowledgement is a 'business' acknowledgement.

For a 'negative' business acknowledgement, code 'fatal-error' from CodeSystem ResponseType, code fatal-error from CodeSystem IssueSeverity; business-rule from CodeSystem IssueType; and (currently proposed) code BUSINESS_FAIL (or a more detailed business failure code) from CodeSystem operation-outcome can be used to specifically imply that the negative acknowledgement is a 'business' acknowledgement.





Describing errors

Where possible, additional information SHALL be included to describe errors. This will help receiving systems understanding the errors in more detail. Errors can be described by using OperationOutcome.issue.diagnostics and OperationOutcome.issue.expression.

An example below shows how this can be used.


Point-to-point and multi-hop

Further guidance and diagrams will be added specifically for this in the future.


Response codes

This guidance should be followed to determine what issue codes are most appropriate to be used for each response code.

ok

Element Code
MessageHeader.response.code ok
OperationOutcome.issue.severity information OR warning
OperationOutcome.issue.code informational

transient-error

Element Code
MessageHeader.response.code transient-error
OperationOutcome.issue.severity fatal
OperationOutcome.issue.code transient (and sub-errors)

fatal-error

Element Code
MessageHeader.response.code fatal-error
OperationOutcome.issue.severity fatal OR error
OperationOutcome.issue.code invalid (and sub-errors) OR security (and sub-errors) OR processing (and sub-errors)
back to top