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) |