Prescribing
Process Overview
EPS only accepts prescriptions from prescribing systems signed with an Advanced Electronic Prescription (AES) that adheres to the EPS signing specification. The $prepare endpoint must be used to ensure the correct prescription data is signed.
It is recommended to use the NHS England Digital Signing Service to generate a valid signature. This will reduce development complexity, onboarding processes, and will protect the solution from future changes with underlying cryptographic standards such as encryption key lengths.
The signature is inclued within a Provenance resource to create a legally valid electronic prescription as a prescription-order FHIR Message.
The $process-message endpoint must be used to submit the signed prescription-order FHIR Message to the EPS. This message can contain between 1 to 4 medication item requests, as FHIR MedicationRequest resources.
If the need arises, a prescription submitted to the EPS can be requested to be cancelled with a prescription-order-update FHIR Message. Submitted prescriptions cannot be amended. If an error has been identified within a submitted prescription it must be cancelled and replaced with a new prescription.
Prescription Prepare
| FHIR Exchange | API endpoint | FHIR Definition |
|---|---|---|
| FHIR Messaging | POST /$prepare | prescription-order |
Post an unsigned prescription-order message to the prepare endpoint.
An HTTP 200 response will be a Base64 encoded digest of the data within the prescription that will be bound by an Advanced Electronic Signature. It is recommended that implementers use the returned digest with the NHS England Digital Signing Service to create a complete Base64 encoded signature.
An HTTP 4XX response will be an OperationOutcome resource for technical failures.
Prescription Submit
| FHIR Exchange | API endpoint | FHIR Definition |
|---|---|---|
| FHIR Messaging | POST /$process-message#prescription-order | prescription-order |
The prescription-order FHIR Message, now containing a Provenance resource including the Advanced Electronic Signature for the prescription is posted to the process-message endpoint. Refer to external guidance for How to embed a signature within a prescription.
The response will be an OperationOutcome resource which indicate success or failure.
Prescription Cancel
| FHIR Exchange | API endpoint | FHIR Definition |
|---|---|---|
| FHIR Messaging | POST /$process-message | prescription-order-update |
When needed, a submitted prescription can be requested to be cancelled by posting a prescription-order-update message. This message is a subset of the prescription-order message where the CommunicationRequest and Provenance resources are not required, and is posted to the process-message endpoint.
Only one MedicationRequest can be cancelled at a time. It is not possible to cancel all MedicationRequests from a prescription-order in a single operation. To cancel an entire prescription-order, multiple prescription-order-update messages are posted, one for each MedicationRequest in the prescription-order.
The MedicationRequest resource used within the prescription-order message is replayed with the following amendments:
| FHIR Data Element | Additional Conformance |
|---|---|
| authoredOn | Date of cancellation |
| status | MUST be cancelled |
| statusReason.coding.code | MUST be present and use a code from DM-MedicationRequest-Status-Reason |
| statusReason.text | SHOULD be present. If not present statusReason.coding.display will be used. |
| extension (ResponsiblePractitioner) NHSDigital-PractitionerRole | Person and their organization requesting cancellation of the prescription item. This MUST be present if the requestor is not the same as the author. |
An HTTP 200 response will be a prescription-order-response message that will identify if the prescribed medication item has been cancelled, or if not, the business reason it could not be cancelled, using an extension extension:prescriptionStatusHistory. This response message will identify the prescriber and prescribing organisation. If it has been processed by a dispenser, it will identify the dispenser and dispensing organisation.
An HTTP 4XX response will be an OperationOutcome resource for technical failures.
Subsequent Prescription Cancellation Response
Where a prescription cannot be cancelled because it has been downloaded by a dispenser, if agreed by both parties, the dispensing system can return the whole prescription to the EPS. This will trigger the EPS to send a subsequent cancellation response to the prescribing system. This is an unsolicited / asynchronous interaction as a prescription-order-response message delivered via the NHS England MESH service.
