Following section provides a high level understanding of the SCAL headers and how they fit into EPS. Please refer to the SCAL document for detailed requirements.
Patient data from PDS
The Personal Demographic Service (PDS) is a centrally maintained database of patient information, which is used by a range of NHS services and service providers to identify and match patients to their health record (PDS-001). The EPS is no exception to this and before a prescription can be sent electronically, the patient's record must be matched on PDS, and any discrepancies should be corrected (PDS-002, PDS-008).
PDS holds a wealth of information that is useful for clinicians. When prescribing, one of the most useful information is the patient’s nomination status in which they have a nominated a community pharmacy or a distance selling pharmacy, an appliance contractor or a dispensing doctor. Having this information presented straight away to the clinician enables them to have an informed conversation with the patient around the dispensary which they intend to use for their medication (PDS-005).
PDS has a separate assurance and SCAL process. You need to engage with the PDS team and complete assurance before you are able to go live with EPS. To begin onboarding with the PDS FHIR API see the PDS - FHIR API spec.
Nomination
Nomination is one of the core feature of the EPS and is used to identify which dispensing organisation the patient would like their medication to be dispensed from, therefore it is crucial that the system has access to the latest information regarding nomination for both the patient (as per PDS above) and for the dispensing organisations themselves. There are four types of prescription nomination
Primary care systems should be able to set, change and remove nominations to the patient PDS record and use “One off” nomination, allowing the clinician to choose the most appropriate route for the prescription in discussion with the patient. This will ensure that regularly issued medication via electronic repeat prescribing, or electronic repeat dispensing will go to the patient's chosen dispensary and that acute medication can go to the same dispensary or a more convenient one for the patient.
For secondary care systems, please refer to section 1.3 and 1.10 of the Supplier Conformance Assessment List (SCAL).
In any case, no system should maintain a local record of nominated dispensaries to avoid confusion or the use of incorrect data when generating prescriptions. Only the most up to date information should be used either from the DOS API or PDS depending on the type of prescription being generated and in which setting (Nom-004, Nom-007).
The ODS code of a patient's P1, P2 and P3 nominated dispenser can be retrieved from PDS and used to set a nomination within the prescription message alongside the correct prescription nomination type.
When setting a one off nomination, the prescription nomination type of P1 should be used alongside the ODS code of the pharmacy selected by the patient via the DOS API.
When setting a non nominated prescription, use the prescription nomination type of 0004 and do not include a nominated pharmacy ODS code.
Medication request
A medication request can have between 1 to 4 medication items. This contains the medication on the prescription itself. If prescribing more than 4 medication items in a single session, multiple prescriptions should be created with a maximum of 4 medication requests per prescription.
When a medication request is being prepared, either by the administration staff on behalf of a clinician prior to signing, or during a consultation event by the clinician for their direct signing, the system must adhere to the standards that the staff are expecting to use.
EPS can only work where items are being prescribed that are in the dictionary of medicines and devices (dm+d) and according to the VMPP concept where the generic title for a generic or proprietary product pack which is known to have been available. The description includes the pack size, for example ‘Atenolol 100mg tablets 28 tablet' (MED-001). Because of the wide range of medicines, pack sizes and dosages there must never be a default value for the item dosage. This must always be completed by the user (MED-002).
During the process of handling the request or the consultation, the prescriber may have cause (and indeed this will be common) to issue more than 4 items to the patient in order to treat existing or new conditions. Although one of the constraints of the EPS message is that only 4 items can be issued per prescription message (MED-002), the user experience should always be that the system will in the background generate separate messages for each multiple of up to 4 items and that at the point of signing they be asked to confirm their electronic signature for each message.
Dose Syntax
Dose syntax requires prescribing systems to send a dose with structure to the API rather than a text string containing the dose. Dose syntax is part of the dosageInstruction which forms part of the medication request.
Dictionary of Medicines and Devices (dm+d)
The dm+d is the standard dictionary used in the NHS for all medicines that are licensed in the UK and as such any prescription that is being issued and transmitted using the EPS must adhere to the standards for the medication set out in the dm+d. As the dm+d is constantly being updated, clinicians will expect the data to be as up to date as possible in their system (DMD-002), so they are confident that they are only issuing the correct approved formulations of medication and that dispensary clinicians will be able to dispense for patients.
Prescribing the required medication consistently is one of the key benefits of using dm+d and as such all entries mapped to the software product should be done so according to the correct VMP or AMP descriptors. No dm+d content should ever be truncated and should be used in all parts of the UI including patient records (DMD-003, DMD-005).
In the event that an item being prescribed is not available in dm+d, or has not been matched to dm+d then the user should be presented with the option to correct the entry (usually in the case where prior to activation of the EPS a manually entered option was locally available for prescribing) or more usually reverted to a paper prescription until the correct mapping has been achieved at system level (DMD-006).
Controlled Drugs
Ever since the introduction of the EPS the prescribing of Controlled Drugs (CDs) was always seen as a key benefit and since this functionality has been enabled within the EPS, it has been welcomed by clinicians on all sides of the prescribing journey.
Although Schedule 1 CDs cannot be prescribed using the EPS, all Schedule 2 and 3 CDs can be prescribed for Acute and Repeat Prescribing and Schedule 4 CDs can be prescribed for Acute, Repeat Prescribing and added to Repeat Dispensing regimes where the prescribing clinical wishes to. Adding CDs to these prescription types saves an enormous amount of time and effort in the prescribing unit, and often reduces the need for patients to physically attend the prescriber meeting every time they have requested one of these medication types which improves the patient experience (CD-001, CD-002, CD-003).
All CDs that are prescribed via the EPS must have the quantity in figures and words to meet the legal requirements for prescribing of these drug types. To minimise the chance of error when writing these prescriptions, the user should only be able to change the number of the quantity that is being prescribed, the system should automatically define the words that are used to express this, e.g. when the user keys in 28 then the system should express “twenty eight” in words (CD-004).
Electronic Acute Prescribing
An acute prescription is a “one off” prescription and is generated after a consultation between a prescriber and a patient. An electronic “Parent Prescription” message is created by the prescribing system and sent to the EPS, which is a sub-system within Spine, to be made available for “download” by a dispenser. The Spine may respond with a rejection message, see Rejection for further details. Details of the reason for rejection will be contained within the message codes, see Errors and Responses for further details. After a successful receipt of the prescription by the Spine, it is available to be requested by a dispenser.
Electronic Repeat Prescribing
Repeat prescribing is valid for an authorised number of repeats or for a defined period. Prescription initiation is controlled by the prescriber. Each prescription issue is separately authorised by a prescribing clinician using their local prescribing system supported by any workflows or rules implemented for the repeat prescribing process. The prescription authorisation results in an electronic prescription are sent to EPS within the Spine. EPS sub-system, treats the repeat prescription in the same way as that of an “Acute” prescription.
Ordering repeat medication is not a feature of EPS. If your system requires the ability to integrate with the repeat prescribing please see the Im1 pairing integration.
Electronic Repeat Dispensing
The EPS “repeat dispensing” model was designed to initially work alongside the paper-based repeat dispensing model, thus allowing either model to be adopted by the prescribers. For the purposes of this specification, it is assumed that the reader has the knowledge of paper-based repeat dispensing model. For further details, see here.
Rejection
Prescription rejection will occur where the validation performed on the prescription fails and the prescription is automatically returned to the prescribing unit. Your system should allow the user to amend or correct the reason for the rejection and then resend the prescription, rather than the prescription being rejected and the user having to create a new prescription (REJ-001).
RBAC and Authorisation
Role Based Access Control (RBAC) is a centralised method for the NHS to ensure that appropriate users are able to only perform the actions that they are authorised to do. All users are assigned to a predefined role, and that role is linked to a number of predefined activities. The most common way of accessing RBAC is through a smartcard issued by a local Registration Authority (RA). The RA will create the user profile on the card with the relevant defined Role codes. Users may have more than one role, for instance a Pharmacist Prescriber working in a Secondary care provider may also work as a Community Pharmacist, therefore will have one smartcard but separate roles for each.
For the EPS to be operational the user must be given authorised access and the most common method for this is by using a smartcard. The user will log on to the clinical system with their smartcard and the system should pick up the RBAC roles from this smartcard session token. Although the user may not always require their smartcard to access the system (e.g. for accessing reporting functionality) all Spine functionality can only be accessed using a smartcard with the correct RBAC roles (RBAC-001, AUTH-002).
Non repudiation
The non repudiation screen is where the clinician that is taking responsibility for the signing of the prescription can check the patient information, medication that is being prescribed and the information that the clinician wants to present with the medication is correct prior to their signing of the message. The minimum information listed should always be presented to the signing clinician and they should not be able to sign the message until they have reviewed all of the information within that message (NR-002, NR-003).
Before signing a message, the system must prompt the user to affirm that they wish to proceed. If required, a compliant system may implement a batch signing process to streamline workflow.
Immediately before a signature is applied to a message, a compliant system must confirm that the current user of the system is the owner of the Smartcard that will be used. To do this the system must prompt the user for entry of a PIN, and pass the entered PIN to the Smartcard for authentication.
There is an example of non-repudiation screen, which highlights information required for download.
Prescription Tokens
Tokens allow patients to collect non nominated electronic prescriptions. These can either be printed paper tokens or electronic tokens, suppliers must have the ability to provide both. Electronic token requirements are within the SCAL, printable tokens will be assured by GPIT Futures.
Signature Creation
Signatures are created by using the /FHIR/R4/$prepare endpoint or by the software provider assembling it. You can also use NHS Digital Signing Service API, to digitally sign a prescription from an application that cannot communicate directly with an NHS smartcard reader.
Cancellation
An electronic prescription can be cancelled after submission to the Spine, provided the prescription has not been downloaded or processed by a dispenser. To cancel an item on a prescription, the prescribing system is required to send a prescription-order-update message. To cancel an entire prescription, the prescribing system is required to cancel all items on the prescription via the prescription-order-update.
Cancellation can be performed at several stages during the life cycle of the prescription message and this may not always be initiated by a clinical user but an admin user. However this should be governed by the relevant RBAC role of that user as to the exact cancellation request that can be performed (CAN-002).
When a cancellation is requested and the message has already been signed, any response back should always include the dispensary information so that the prescribing unit can take the correct action. This could be to contact the dispensary to ask them to return the script or to contact the patient to ask them not to use that medication and to return to the dispensary for the correct medication (CAN-005, CAN-006, CAN-007).
When a cancellation is requested, it is critical that the local record for the patient is updated with the response message from the spine (and any subsequent responses should further cancellation interaction be required) so that the latest information for that patient is held on the local record and to prevent any miscommunication of the prescription journey to the patient or dispensary making enquiries (CAN-003).
If a prescription response confirms that a prescription is with a dispenser, the prescribing system must be able to handle a subsequent cancellation response which will be sent to you via Mesh. As part of the EPS setup, prescribing systems must have access to these subsequent cancellation messages via Mesh.
Errors and Responses
Errors provided by both the Apigee platform and EPS must be handled by the prescribing software. Where a massage and/or dispenser details are included within the error/response they should be displayed to the prescriber.
Reporting
The reporting requirements of organisations may be different depending on the organisation, their local or regional contractual status or per the clinical services that they provide.
Suppliers should liaise with their users regularly around their requirements and ensure that the information is presented with the regularity and granularity that the users require. Components of the reporting from messages generated using the EPS should always be searchable using the prescription ID generated for that message. Users should always be able to set a start and end date range when searching for messages so that they can review historical records or for the support of their business continuity activity (REP-002).
