Page Status: 2026-11-10
NLLReceipt
Page index
Definition
Invocations
URL: [base]/$nll-receipt
This operation does NOT change content
Parameters (In)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| logicalId | 1..1 | id | Logical identifier of an existing resource. SHOULD be used for verification following update requests (PUT) and for synchronization scenarios. |
Return Values (Out)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| exists | 1..1 | boolean | Indicates whether a matching resource was found. When exists=false, no resource-specific output parameters are returned. |
| logicalId | 0..1 | id | Logical identifier of the matching resource. |
| chainId | 0..1 | string | Chain identifier of the matching resource. |
| status | 0..1 | string | The response is filtered according to the value of the
|
| created | 0..1 | instant | Timestamp when the resource was originally created. |
| lastUpdated | 0..1 | instant | Timestamp when the resource was last updated. |
This operation is intended for recovery and synchronization scenarios and should not be used as a general-purpose resource query mechanism.
This operation SHOULD be used to verify the outcome of a previous update request before retransmission is attempted.
Invocation:POST [base]/$nll-receipt. A LogicalId SHALL be supplied.
This version of the operation supports MedicationRequest resources only and is intended primarily for update scenarios. Future versions may enable create scenarios and additional resource types using the same interaction pattern.
Recovery and Synchronization
The $nll-receipt operation supports recovery and synchronization scenarios where the processing outcome of a previously submitted request cannot be determined.
Rather than retransmitting a request immediately following a timeout, communication failure, or lost response, clients SHOULD use $nll-receipt to verify the current state of the affected resource.
$nll-receipt is intended solely for recovery and synchronization purposes and SHALL NOT be used as a general-purpose mechanism for querying MedicationRequest resources.
The following recommendations apply to ensure consistent correlation and traceability throughout the recovery flow:
Header parameters
Receipt requests are associated with a previously submitted operation. To ensure correct authorization, correlation and traceability throughout the recovery process, the following header requirements apply.
Standard request headers and validation rules for retrieval operations also apply to $nll-receipt. See HTTP Header for general requirements.
| Header | Recommendation |
|---|---|
authorization |
$nll-receipt requests SHALL be performed on behalf of the same authenticated user as the original operation. |
x-request-id |
Generate a new value for every request |
x-context-id |
Reuse the value from the original operation throughout the recovery flow. |
x-patientref |
Mandatory for patients with a personal identity number. For patients identified by date of birth, the element should not be provided. |
Typical Recovery Flow
- A client submits an update request.
- The client experiences a timeout, communication failure, or loses the response.
- The client waits a short period before issuing the first
$nll-receiptrequest. - NLL returns the current state of the resource.
- One of the following outcomes applies:
- If the response confirms the expected state change, the original operation can be considered successful.
- If the response does not confirm the expected state change, the result should normally be treated as inconclusive rather than failed. The client may issue additional receipt requests before determining whether retransmission is required..