Electronic Prescription Service (EPS) integration walk through
A guide through the Electronic Prescription Service (EPS) integration resources available on this site
The Electronic Prescription Service (EPS) is one of the more complex NHS national services implemented within the NHS Spine infrastructure. There are a myriad of documents to read and understand but most are available on the Health Developer Network and this guide will present them in a logical order.
The EPS compliance process follows the NHS Digital “Common Assurance Process” (CAP). Software development is only part of this process. In parallel a series of documents has to be submitted to the NHS Digital Solutions Assurance team. First is to gain approval to develop an EPS compliant system. Subsequent steps allow access the various Spine infrastructure environments, followed by various stages of testing and assurance, all culminating in the granting of “Full Rollout Approval”. The remainder of this article is only going to cover software development activities.
1. The EPS page within “Systems and Services”
[Direct Link] This page lists nearly all the supplier-facing documentation required to make an existing GP prescribing system or community dispensing system EPS-compliant.
I say “nearly” as the two documents not listed are;
- Information Governance Functional Requirements – These apply to any Spine-connected system and we understand these are in the process of being updated
- Spine External Interface Specification (EIS) – This details how to talk to the various Spine services, including those for messaging, directory access and smartcard authentication.
2. Read the relevant EPS Compliance Specification
The prescribing specification is applicable for GP prescribing systems. A version suitable for non-GP systems like those used within Urgent and Emergency Care settings is in the process of being published.
The dispensing specification is applicable to either dispensing systems used in community pharmacy or by dispensing appliance contractors.
Most other documents are then referenced at the appropriate point within these specifications. The functional requirements are written as output-based requirements, supplemented by explanatory narrative and illustrations. Try to avoid just extracting the numbered functional requirements. Please read the narrative to fully understand how the EPS works within existing prescribing or dispensing processes.
3. Message Implementation Manual (MIM)
[Direct Link] Fairly soon a developer will want to see the EPS interoperability message definitions. The EPS uses the HL7v3 standard and current version of the MIM is v4.2.00, and yes, that’s correct, published way back in 2006. Jump to the “Medication Management” domain to see the EPS interactions and messages.
Please read the MIM in conjunction with the relevant EPS compliance specification. Some messaging requirements defined in the MIM are clarified within the EPS specification, especially with respect to the population of optional data attributes. HL7v3 schema’s are quite loose. A schema compliant message may not be an EPS compliant message.
Note. The following HL7v3 interactions are not implemented. Do not waste you time developing against any of these.
6.14 Dispense Notification with Claim Information – PORX_IN220102UK31
6.16 Dispense Reimbursement Claim Reject – PORX_IN150101UK31
6.17 Reimbursement Claim Resubmit – PORX_IN090102UK31
6.20 Forward Withdraw Notification – PORX_IN530101UK31
6.22 PSIS Cancellation Notification – PORX_IN000001UK01
Other than those above, you then work out which HL7v3 interactions you need to implement. The MIM interaction diagrams use the terms ‘Prescribing System’ and ‘Dispensing System’.
GP prescribing systems will also need to be fully Spine Demographics (known as “PDS” within the MIM) compliant to manage a patient’s demographic record. Dispensing systems may need to do that in the future but right now only need to be able to manage a patient’s nominated dispenser information, held within Spine Demographics, so need to implement the Demographics “PDS Trace Query”, “PDS Retreival Query” and “PDS General Update Request” interactions plus their relevant response interactions.
4. Get connected to a Spine environment
For this you need to contact NHS Digital Solutions Assurance. The NHS Digital OpenTest environment is a good starting point. It does not include all the Spine services required for complete EPS development, but most of them, and crucially has a low barrier for entry.
Switch to the formal development and integration testing environments when ready which are functionally like-for-like with live. You’ll need to be engaged and following the Common Assurance Process (CAP) to access these environments.
5. Get basic messaging working
The EPS specifications do not cover generic Spine connectivity. That’s all covered in the Spine External Interface Specification (EIS) for messaging, directory and smart card authentication services.
A point of frequent confusion is the assumed link between smart card authentication and messaging to Spine national services such as the EPS. Such a link does not exist. EPS messaging can flow between external systems and Spine regardless of smart cards. Messaging authentication is managed via end-points and certificates issued by NHS Digital to enable Transport Layer Security (TLS) between the connected systems. Smart card authentication only comes into play to control what access an end-user has to the information available within the clinical system, and crucially for the EPS, to enable the electronic signing of prescriptions using the content commitment certificate held within the user’s NHS smart card.
6. Work through the data requirements
An existing prescribing or dispensing system should already be capturing most of the business data required for the EPS.
New data attributes will include the patient’s (optional) nominated dispenser(s). Some new attributes may be required for electronic repeat dispensing prescriptions. EPS uses the professional codes issued to medics by professional bodies, e.g. GMC, NMC & GPhC, so if these are not currently available to your system they will need to be.
If your system is not already talking medications as per the NHS Dictionary of Medicines and Devices (dm+d) standard, then there may be a fair bit of work to do. All medication, prescribed or dispensed via the EPS must be represented using dm+d terms.
Now you can then start creating some business-valid HL7v3 messages and get them validated by the offline tools available from the NHS Digital Solutions Assurance team. Prescribing systems won’t yet be applying an electronic signature. I’ll cover that further in this article.
7. Smart Card Authentication and Role Based Access Control (RBAC)
All end-users of the EPS must be authenticated using NHS Digital credentials, currently only available through the use of NHS smart cards. Smart cards for live operations are managed by local Registration Authorities (RA’s). Smart cards for development environments are managed by the NHS Digital Solutions Assurance team.
The Spine External Interface Specification (EIS) includes a section on how to implement smart card authentication.
From the local system perspective, a successful end-user authentication results in a Security Assertion Markup Language (SAML) XML document that is used to implement Role Based Access Control (RBAC). RBAC is a topic requiring it’s own learning article so I’ll just say the local clinical system can now give the user access to system functionality that they have been authorised to access. The RBAC Implementation Guide for the EPS R2 is a good starting point.
8. Advanced Electronic Signatures
Electronic prescriptions are signed with an Advanced Electronic Signature using the content commitment certificate on the prescriber’s NHS smart card. Therefore prescribing systems need to develop the routine for signing and dispensing systems the routine for validating the signature.
The Digital Signature and Non Repudiation document provide guidance for the overall signing or validating process. Specific functional requirements for EPS signing and validating are in the ETP Message Signing Requirements document.
Signing or validating software is only a few lines of code, but it’s code that can be difficult to debug. To assist development a Digital Signature Toolkit Guidance package is available.
9. Iterate through the prescribing or dispensing business processes, working closely with your user/customer stakeholders and NHS Digital
It is impossible to switch from paper prescribing and dispensing processes to electronic without some level of business change. Development in isolation from key user/customer stakeholders may produce a functionally compliant system but may not produce one that your customers will embrace.
NHS Digital are here to support software suppliers through their design and development process. We won’t cut code with you but can help you understand the technical requirements and share the experiences from the past decade of EPS implementations of what makes a good EPS-compliant clinical system.
Was this article useful?13