OperationDefinition
prepare
Prepare an unsigned FHIR prescription-order message into the data that needs to be electronically signed.
| Name | Url |
|---|---|
| prepare-message | https://fhir.nhs.uk/OperationDefinition/MessageHeader-prepare-message |
Invocations
URL: [base]/$prepare
This operation changes content
Parameters (In)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| content | 1..1 | Bundle | The prescription order message to process (without Provence resource) |
Return Values (Out)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| digest | 1..1 | string | Message Digest response containing the signed signature in XML format |
| algorithm | 1..1 | string | Algorithm used |
| timestamp | 1..1 | string | dateTime when the digest was created |
This operation does not use the parameters resource for input parameters, it does for the response. \n\n A server may return one of several status codes: \n\n * 200 OK: Indicates that the message has been fully processed.
{
],
"description": "Convert a prescription in FHIR format into the canonicalised HL7 V3 signature fragments which should be signed by the prescriber.",
"comment": "This operation does not use the parameters resource for input parameters, it does for the response. \\n\\n A server may return one of several status codes: \\n\\n * **200 OK**: Indicates that the message has been fully processed.",
{
},
{
},
{
},
{
}
]
}
</contact>
<description value="Convert a prescription in FHIR format into the canonicalised HL7 V3 signature fragments which should be signed by the prescriber." />
<comment value="This operation does not use the parameters resource for input parameters, it does for the response. \n\n A server may return one of several status codes: \n\n * **200 OK**: Indicates that the message has been fully processed." />
</parameter>
</parameter>
</parameter>
</parameter>
</OperationDefinition>
content
An unsigned (without Provenance resource) prescription-order message. See Prescription Prepare.
process-message
Used by prescribing systems to request to cancel a previously submitted prescription-order.
Used by dispensing systems to submit a medication dispensing record to the EPS with a dispense-notification message.
Invocations
URL: [base]/$process-message
This operation changes content
Parameters (In)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| content | 1..1 | Bundle | The message to process |
Return Values (Out)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| return | 0..1 | OperationOutcome | A response message |
This operation does not use the parameters resource; if they are used, and the "content" parameter is always the body of the HTTP message.
When processing messages, a server may return one of several status codes:
- 200 OK: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.
- 202 Accepted: Indicates that the receiving system has accepted custody of the message
- 204 No Content: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the messageheader-response-request extension), no response is being provided
- 300+: Indicates that the message was not successfully processed. The server MAY return an OperationOutcome with additional information, and SHOULD do so if the response code is 400 or greater.<br/> The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.
The following rules apply when using $process-message:
- The operation only accepts POST transactions - any other HTTP method will result in an HTTP error
- The request content type submitted is always Bundle with type "message" containing a Message Header resource as the first resource
- The response content type returned is always OperationOutcome or an HTTP error
- If the response is an error, the body SHOULD be an Errors ∓ Warning resource with full details
- The mailbox may be authenticated using standard HTTP authentication methods, including OAuth
The $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.
In order to ensure consistency of processing, the logical rules regarding processing of Bundle.id and message id SHALL be followed when messages are processed using this operation.
The $process-message operation may be used synchronously, or asynchronously.
The following rules apply when using the $process-message operation synchronously:
- The URL (http://server/base/$process-message) has no parameters
- It is an error if the sender POSTs a message that requires multiple response messages
- Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)
The following rules apply when using the $process-message operation asynchronously:
- The URL has at least one parameter: http://server/base/$process-message?async=true
- The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed
- Accepting the message means that the server has understood the message enough to know where to respond
- An OperationOutcome SHOULD be returned in either case
- By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]
- Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter "response-url": http://server/base/$process-message?async=true&response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)
- The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages
{
],
"description": "This operation accepts a message, processes it according to the definition of the event in the message header, and returns one or more response messages. \n\nIn addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.",
"comment": "This operation does not use the parameters resource; if they are used, and the \"content\" parameter is always the body of the HTTP message.\n\nWhen processing messages, a server may return one of several status codes:\n* **200 OK**: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.\n* **202 Accepted**: Indicates that the receiving system has accepted custody of the message\n* **204 No Content**: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the [messageheader-response-request](http://hl7.org/fhir/R4/extension-messageheader-response-request.html) extension), no response is being provided\n* **300+**: Indicates that the message was not successfully processed. The server MAY return an [OperationOutcome](http://hl7.org/fhir/R4/operationoutcome.html) with additional information, and SHOULD do so if the response code is 400 or greater.<br/>\n The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.\n\nThe following rules apply when using $process-message:\n\n* The operation only accepts POST transactions - any other HTTP method will result in an HTTP error\n* The request content type submitted is always [Bundle](http://hl7.org/fhir/R4/bundle.html) with type \"message\" containing a [Message Header](http://hl7.org/fhir/R4/messageheader.html) resource as the first resource\n* The response content type returned is always [OperationOutcome](http://hl7.org/fhir/R4/operationoutcome.html) or an HTTP error\n* If the response is an error, the body SHOULD be an [Errors ∓ Warning](http://hl7.org/fhir/R4/operationoutcome.html) resource with full details\n* The mailbox may be authenticated using standard HTTP authentication methods, including OAuth\n\nThe $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.\n\nIn order to ensure consistency of processing, the [logical rules regarding processing of Bundle.id and message id](http://hl7.org/fhir/R4/messaging.html#reliable) SHALL be followed when messages are processed using this operation.\n\nThe $process-message operation may be used synchronously, or asynchronously.\n\nThe following rules apply when using the $process-message operation synchronously:\n\n* The URL (http://server/base/$process-message) has no parameters\n* It is an error if the sender POSTs a message that requires multiple response messages\n* Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)\n\nThe following rules apply when using the $process-message operation asynchronously:\n\n* The URL has at least one parameter: http://server/base/$process-message?async=true\n* The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed\n* Accepting the message means that the server has understood the message enough to know where to respond\n* An [OperationOutcome](http://hl7.org/fhir/R4/operationoutcome.html) SHOULD be returned in either case\n* By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]\n* Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter \"response-url\": http://server/base/$process-message?async=true&response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)\n* The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages",
"MessageHeader"
],
{
},
{
}
]
}
</contact>
<description value="This operation accepts a message, processes it according to the definition of the event in the message header, and returns one or more response messages. \n\nIn addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so." />
<comment value="This operation does not use the parameters resource; if they are used, and the "content" parameter is always the body of the HTTP message.\n\nWhen processing messages, a server may return one of several status codes:\n* **200 OK**: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.\n* **202 Accepted**: Indicates that the receiving system has accepted custody of the message\n* **204 No Content**: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the [messageheader-response-request](http://hl7.org/fhir/R4/extension-messageheader-response-request.html) extension), no response is being provided\n* **300+**: Indicates that the message was not successfully processed. The server MAY return an [OperationOutcome](http://hl7.org/fhir/R4/operationoutcome.html) with additional information, and SHOULD do so if the response code is 400 or greater.<br/>\n The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.\n\nThe following rules apply when using $process-message:\n\n* The operation only accepts POST transactions - any other HTTP method will result in an HTTP error\n* The request content type submitted is always [Bundle](http://hl7.org/fhir/R4/bundle.html) with type "message" containing a [Message Header](http://hl7.org/fhir/R4/messageheader.html) resource as the first resource\n* The response content type returned is always [OperationOutcome](http://hl7.org/fhir/R4/operationoutcome.html) or an HTTP error\n* If the response is an error, the body SHOULD be an [Errors ∓ Warning](http://hl7.org/fhir/R4/operationoutcome.html) resource with full details\n* The mailbox may be authenticated using standard HTTP authentication methods, including OAuth\n\nThe $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.\n\nIn order to ensure consistency of processing, the [logical rules regarding processing of Bundle.id and message id](http://hl7.org/fhir/R4/messaging.html#reliable) SHALL be followed when messages are processed using this operation.\n\nThe $process-message operation may be used synchronously, or asynchronously.\n\nThe following rules apply when using the $process-message operation synchronously:\n\n* The URL (http://server/base/$process-message) has no parameters\n* It is an error if the sender POSTs a message that requires multiple response messages\n* Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)\n\nThe following rules apply when using the $process-message operation asynchronously:\n\n* The URL has at least one parameter: http://server/base/$process-message?async=true\n* The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed\n* Accepting the message means that the server has understood the message enough to know where to respond\n* An [OperationOutcome](http://hl7.org/fhir/R4/operationoutcome.html) SHOULD be returned in either case\n* By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]\n* Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter "response-url": http://server/base/$process-message?async=true&response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)\n* The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages" />
</parameter>
</parameter>
</OperationDefinition>
content
Prescription Submit
Submit an electronically signed prescription (signature within a Provenance resource) to the EPS with a prescription-order message. See Prescription Submit.
Dispense Notification
Submit a medication dispensing record to the EPS with a dispense-notification message. See Dispense Notification.
release
Release (download) a prescription by a dispensing system.
| Name | Url |
|---|---|
| Task-release | https://fhir.nhs.uk/OperationDefinition/Task-release-message |
Invocations
URL: [base]/Task/$release
This operation changes content
Parameters (In)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| group-identifier | 0..1 | Identifier | The short-form-prescription-id (token) of the prescription. Used for releasing Patient prescriptions |
| owner | 1..1 | Organization | The organization (pharmacy) downloading the prescriptions. Used for releasing Nominated Pharmacy prescriptions |
| status | 1..1 | code | Status from ValueSet http://hl7.org/fhir/valueset-task-status.html Use: accepted |
| agent | 1..1 | PractitionerRole | The professional submitting the release request |
Return Values (Out)
| Name | Cardinality | Type | Documentation |
|---|---|---|---|
| return | 1..1 | Bundle | A FHIR Bundle (type=searchset) which contains prescription-order FHIR Messages which match the search parameters. An empty search will still return a FHIR Bundle but with no entries. |
Only one of the parameters group-identifier and owner MUST be provided. This operation performs both a query on the message queue and updates the status of returned prescriptions.
{
},
],
"description": "Use this endpoint to download prescriptions from Spine before it is dispensed. You can download a single prescription using the prescription's ID, or download up to 25 prescriptions (per request) nominated to a dispenser using the dispenser's ODS code.",
"comment": "Only one of the parameters group-identifier and owner MUST be provided. This operation performs both a query on the message queue and updates the status of returned prescriptions.",
"Task"
],
{
"documentation": "The short-form-prescription-id (token) of the prescription. Used for releasing Patient prescriptions",
},
{
"documentation": "The organization (pharmacy) downloading the prescriptions. Used for releasing Nominated Pharmacy prescriptions",
},
{
"documentation": "Status from ValueSet http://hl7.org/fhir/valueset-task-status.html Use: accepted",
},
{
},
{
"documentation": "A FHIR Bundle (type=searchset) which contains prescription-order FHIR Messages which match the search parameters. An empty search will still return a FHIR Bundle but with no entries.",
}
]
}
</meta>
</contact>
<description value="Use this endpoint to download prescriptions from Spine before it is dispensed. You can download a single prescription using the prescription's ID, or download up to 25 prescriptions (per request) nominated to a dispenser using the dispenser's ODS code." />
<comment value="Only one of the parameters group-identifier and owner MUST be provided. This operation performs both a query on the message queue and updates the status of returned prescriptions." />
<documentation value="The short-form-prescription-id (token) of the prescription. Used for releasing Patient prescriptions" />
</parameter>
<documentation value="The organization (pharmacy) downloading the prescriptions. Used for releasing Nominated Pharmacy prescriptions" />
</parameter>
<documentation value="Status from ValueSet http://hl7.org/fhir/valueset-task-status.html Use: accepted" />
</parameter>
</parameter>
<documentation value="A FHIR Bundle (type=searchset) which contains prescription-order FHIR Messages which match the search parameters. An empty search will still return a FHIR Bundle but with no entries." />
</parameter>
</OperationDefinition>
Input Parameters
group-identifier
The group-identifier (also known as the prescription short form id) is used to download a single prescription. Omit when requesting nominated prescriptions for the dispensing site.
{
"name": "group-identifier",
"valueIdentifier": {
"system": "https://fhir.nhs.uk/Id/prescription-order-number",
"value": "82D996-C81010-11DB12"
}
}
owner
The owner is an Organization resource representing the dispensing site downloading the prescription(s). A valid contact telephone number must be provided as this is made visible to the prescribing system if a request to cancel the prescription is unsuccessful due to being downloaded by the dispenser.
{
"name": "owner",
"resource": {
"resourceType": "Organization",
"id": "organization",
"identifier": [
{
"system": "https://fhir.nhs.uk/Id/ods-organization-code",
"value": "VNE51"
}
],
"address": [
{
"city": "West Yorkshire",
"use": "work",
"line": [
"17 Austhorpe Road",
"Crossgates",
"Leeds"
],
"postalCode": "LS15 8BA"
}
],
"active": true,
"type": [
{
"coding": [
{
"system": "https://fhir.nhs.uk/CodeSystem/organisation-role",
"code": "182",
"display": "PHARMACY"
}
]
}
],
"name": "The Simple Pharmacy",
"telecom": [
{
"system": "phone",
"use": "work",
"value": "0113 3180277"
}
]
}
}
status
The status is a fixed value of accepted.
{
"name": "status",
"valueCode": "accepted"
}
agent
The agent must be a PractitionerRole resource, representing the end user triggering the release request. The Role Profile ID, User ID and Job Role Code are available from the CIS2 authenticated session.
{
"name": "agent",
"resource": {
"resourceType": "PractitionerRole",
"id": "16708936-6397-4e03-b84f-4aaa790633e0",
"identifier": [
{
"system": "https://fhir.nhs.uk/Id/sds-role-profile-id",
"value": "555086415105"
}
],
"practitioner": {
"identifier": {
"system": "https://fhir.nhs.uk/Id/sds-user-id",
"value": "3415870201"
},
"display": "Jackie Clark"
},
"code": [
{
"coding": [
{
"system": "https://fhir.nhs.uk/CodeSystem/NHSDigital-SDS-JobRoleCode",
"code": "S0030:G0100:R0620"
}
]
}
],
"telecom": [
{
"system": "phone",
"value": "02380798431",
"use": "work"
}
]
}
}