Output Based Specification

For the procurement of a

Trust-wide

Electronic Prescribing and Medicines Administration (ePMA) Solution

Table of Contents1.Purpose of this document32.Introduction63.Business Context64.Trust Infrastructure and Standards65.Functional Requirements75.1Drug Allergies and Interactions75.2Alerts95.3Controlled Drugs115.4Clinical Decision Support135.5Depot175.6Clozapine185.7Prescribe Medication195.8Pharmacy Communication285.9Medicines Management305.10Medicine Administration335.11Simple Medicines Policy and Patient Group Directions (PGDs)385.12Discharge Prescribing395.13Reports435.14Technical476.Abbreviations56

m:\teamshare\hacw_epma\specification\epma draft specification_v4.0.docxPage 10 of 56

1. Purpose of this document

The purpose of this document is to define the Worcester Health and Care NHS Trust’s (WHCT) requirements for an Electronic Prescribing and Medicines Administration (ePMA) system in order to inform potential suppliers and aid the procurement and evaluation process. The development of the document can be seen in the below table.

Status

Version

Date

Actioned By

Description

Draft

1.0

25/01/2018

Nilam Bola and Katie Balu

Draft ePMA Specification for Comment.

Prepared for distribution to Trust personnel.

Draft

1.1

29/01/2018

Nilam Bola

Draft ePMA Specification for Comment.

Re-ordered for distribution to medics:-

· Dr Simon Challand

· Dr Martin Curtice

· Dr Ian Douglas

· Dr Charlotte Hull

· Dr Louisa James

· Dr Hannah Liu

· Dr Sangram Pathania

· Dr Kirsty Protherough

· Dr Tara Walker

· Dr Anna Wilkin

Draft

1.2

29/01/2018

Nilam Bola

Draft ePMA Specification for Comment.

Re-ordered for distribution to nurses and therapists:-

· Mandy Anderson

· Phil Bell

· Naomi Develin

· Chelsea Elcocks

· Dan Fisher

· Rachel Gibbons

· Kathy Hankins

· Helen Istifan

· Simon Kerslake

· Claire Lees

· Andy McKee

· Naomi Morgan

· Alex Patrick

· Karen Remmington

· Poppy Tranter

· Kerry Wykes

Draft

1.3

29/01/2018

Nilam Bola

Draft ePMA Specification for Comment.

Re-ordered for distribution to Pharmacists:-

· Jaswinder Dhap

· Andy Down

· Siriosha Gopalan

· Shelley Palmer

Draft

1.4

29/01/2018

Nilam Bola

Draft ePMA Specification for Comment.

Re-ordered for distribution to Matrons:-

· Jo Roberts

· Phil Shakeshaft

· Jo Whitehouse

Draft

1.5

29/01/2018

Nilam Bola

Draft ePMA Specification for Comment.

Re-ordered for distribution to IT, Support and Reporting:-

· David Brown

· Ken Hadley

· Mark Gallagher

· Darren Hulbert

· Sam Munday

· Richard Pamment

· Dawn Pattison

· Vanessa Roberts

· Steve Sidwell

· Tim Windsor

Draft

2.0

05/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Returned comments added:-

· Vanessa Roberts

· Kirsty Protherough

Draft

2.1

07/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Returned comments added:-

· Martin Curtice

· Claire Lees

· Tara Walker

(NB Dawn Pattison returned email with no comments)

Draft

2.2

08/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Returned comments added:-

· Tim Windsor

· Ken Hadley

Draft

2.3

09/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Returned comments added:-

· Darren Hulbert

· Kathy Hankins

· Jas Dhap

· Shelley Palmer

Draft

2.4

12/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Returned comments added:-

· Shelley Palmer (continued)

· Mark Gallagher

· Andrew Down

· Ian Douglas

· Poppy Tranter

· Richard Pamment

(NB Simon Challand, Karen Remmington, Jo Whitehouse and Jo Roberts returned email with no comments)

Draft

3.0

20/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Review of comments by John Morrison, Katie Balu and Nilam Bola

Draft

3.1

23/01/2018

Katie Balu

Review of comments by John Morrison, Katie Balu

Draft

3.2

26/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Amendments to document made by Nilam Bola

Draft

3.3

28/02/2018

Nilam Bola

Draft ePMA Specification for Comment.

Amendments to document made by Nilam Bola to reports section

Draft

4.0

28/02/2018

Nilam Bola

Draft ePMA Specification.

Renamed document and re-formatted in preparation for sending

2. Introduction

3. Business Context

4. Trust Infrastructure and Standards

5. Functional Requirements

5.1 Drug Allergies and Interactions

No.

Drug Allergies and Interactions Specification Item

A&I-1

The solution MUST allow for the recording of drug allergies, intolerances and adverse drug reactions (ADRs), whether the reaction is historical or observed and reported while under Trust care. The timescale of the reaction against each drug for all newly occurring allergies must be recorded as per policy.

A&I-2

The solution MUST allow for the update and discontinuation of allergies and it MUST be mandatory to record reasons.

A&I-3

Using a locally configurable drop down list, it MUST be possible to record the service user’s allergy status by a selecting response such as ‘No Known Drug Allergies’ in the solution.

A&I-4

It MUST be possible to locally configure the types of interactions (e.g. inpatient admission, outpatient appointment, community contacts) where an end user is required to confirm the allergy status of the service user. In the case of a telephone contact it may not be necessary to confirm the allergy status of a service user and this must be locally configurable.

A&I-5

The solution MUST have the ability or functionality to automatically trigger locally configurable drug interaction alerts that can be grouped into severity levels (e.g. severe and moderate).

A&I-6

The solution MUST allow a medication to be prescribed despite alerts for interactions and/or allergies being present and it MUST be mandatory to record the reason why that decision has been taken. Warning MUST be triggered at the point of medication prescribing.

A&I-7

The solution MUST allow the local administrator to display, enter, modify, deactivate, “delete”, update and print the severity level at which drug interaction warnings will be displayed.The initial record being “deleted”/corrected will remain available for access within an audit trail with all the original details available plus the detail of the person undertaking the update.

A&I-8

The solution MUST allow the local administrator to enter, modify, deactivate, “delete”, update, display, and print rationale(s) for triggering a drug interaction alert.

A&I-9

The solution MUST trigger proactive alerts that require action for service users on a given medication (e.g. lithium and clozapine and annual bloods for patients prescribed antipsychotics) when they are due for scheduled laboratory tests or other diagnostic studies to monitor for therapeutic or adverse effects of the drug.

A&I-10

The solution MUST display, on demand, potential interactions on a service user’s medication list, whether the medication is prescribed or even if a medication is not being prescribed at the time.

A&I-11

The solution MUST support the local configurability and accessibility of drug specific education materials (e.g. Choice and Medication website, Trust leaflets, other service user information leaflets), including updates from third party databases.

A&I-12

The solution MUST be able to support the “Yellow Card” scheme and send messages or notifications to the MHRA.

A&I-13

The solution MUST provide the ability to check for potential interactions between a current medication and a newly entered allergy. An alert MUST be automatically presented at the point the information is added to the solution.

A&I-14

The solution MUST provide a prompt on the cumulative combination of drugs (e.g. high dosages of anti-psychotic drugs and also the different routes of same medication e.g. oral and IM).

A&I-15

Prior to administration the solution MUST provide a prompt to prescribers where medication is only licensed for administration via a specified route (e.g. IV, IM, orally, etc.). However, the end user MUST have the ability to override this with a reason where prescribing outside of licensed indications/routes is justified.

A&I-16

The allergy information added to the solution MUST update other systems.

5.2 Alerts

No.

Alerts Specification Item

A-1

The solution MUST continue to alert the end user accessing the medicines pathways until a service user's allergy information is recorded. The end user's actions following the alert SHOULD be recorded.

A-2

Where an end user tries to prescribe a drug where there is a drug interaction, the solution MUST allow the end user to record any discussion with a pharmacist and MUST record the reason for the override before allowing the prescription. The ability to group alerts into severe and moderate with each classification requiring a different level of action MUST be locally configurable.

A-3

The solution MUST prompt the end user where they try to prescribe a drug that was previously prescribed or discontinued.

A-4

The solution MUST prompt the end user if they try to prescribe the same drug twice, including when present in compound drugs.

A-5

The solution MUST display if a service user is pregnant or breast feeding each time a new medicine is prescribed.

A-6

Medications which have NICE or other guidelines attached to them SHOULD prompt or initiate activities (e.g. booking an ECG).

A-7

The solution MUST be able to provide a prompt to the end user when physical health monitoring is required for particular drugs (e.g. blood monitoring), but this is to be locally configurable.

A-8

The solution SHOULD provide the ability to suspend a medication and provide an alert where received results indicate cessation of that medication.

A-9

The solution MUST be able to record and support a drug incident/error process.

A-10

The solution will prompt prescribers when specific information MUST be supplied to the service user.

A-11

The solution MUST display a warning if there is a service user who has a same or similar surname to another service user in an inpatient ward or an outpatient clinic.

A-12

The solution SHOULD display a warning where non formulary or a high cost medication (e.g. those requiring Commissioner approval) is prescribed and suggest alternatives. Where the medication is prescribed a reason SHOULD be recorded.

A-13

The solution MUST provide an alert to review certain medication (e.g. antibiotics) and either convert drugs from IV to oral route or stop if clinically appropriate with reasoning recorded.

A-14

The solution SHOULD allow alerting to appropriate staff when an action that is deemed unsafe (e.g. over use of a PRN medication) is undertaken by an end user. An unsafe action SHOULD be configurable based on Trust recommendations.

A-15

It MUST be possible to define alerts that cannot be overridden.

A-16

End users MUST be able to see all alerts, historical and active, generated for a service user.

A-17

Alerts which are consistently overridden MUST be reportable, so that a review can be undertaken. The solution SHOULD also allow for feedback to be generated for individual prescribers and their supervisors about their alert override pattern over a period of time.

A-18

Alerts SHOULD be reserved for high level warnings that require action to ensure service user safety, but there SHOULD also be local flexibility to manage alerts according to local clinical governance procedures.

A-19

Display of alerts SHOULD be linked to more complex information if required (e.g. if an interaction is displayed, a link to the interaction via a suitable source is shown).

A-20

Where more than one strength of a formulation is available, a locally configurable alert MUST be in place to help avoid miss selection when a formulation is to be selected (e.g. depot injections commonly utilise the lowest volume injection but may not display first in a list).

5.3 Controlled Drugs

No.

Controlled Drugs Specification Item

CD-1

The solution MUST meet or conform to all legal requirements regarding controlled drugs.

CD-2

The solution MUST produce routine reports detailing the prescription and where required, the supply of controlled drugs within specific locations, specialties, by prescriber and over selected periods of time.

CD-3

The solution MUST have an electronic CD register facility for both wards/departments and pharmacy.

CD-4

The solution MUST provide drug registers accessible for each ward to record drugs received (including the service user’s own controlled drugs), administered and destroyed/returned to pharmacy or wasted. All entries MUST be attributable to an individual staff member with mandatory witness recording and be visible to all.

CD-5

The solution MUST support the CD balance check on drugs remaining following each transaction type and the ability to be ‘signed off’ by an appropriate member of staff. Local alerting procedures MUST be supported by the solution to ensure escalation alerts are forwarded to a locally configured list of named individuals/teams the longer the balance remains unchecked.

CD-6

The solution MUST be locally configurable to define the minimum number of times a balance will be checked on a local basis and to vary this according to the location. For example a daily check and record of balances with an accompanying signature MUST be possible using electronic records. However, to allow for continued care, it MUST be possible to postpone or set the reminder to snooze for a defined period of time.

CD-7

The solution MUST ensure information on the running balance is recorded for each drug. This MUST be visible at all times when the solution is accessed to manage controlled drugs.

CD-8

The solution MUST provide the ability for running balances to be adjusted to allow for overage, measuring loss, error or other reason by authorised individuals with a mandatory entry to indicate the reason for alteration. Witnessing SHOULD also be required for this.

CD-9

The solution MUST comply with clinical validation procedures, MHRA guidelines and legal requirements as within the Medicines Act 1968 and the Misuse of Drugs Regulations 1971.

CD-10

When administering controlled drugs, the solution MUST support an additional signature other than the logged in staff member, without the need for the first person to log out and the second person to log in. After capturing the additional signature, the staff member MUST be able to smoothly continue their work.

CD-11

The solution MUST support advanced electronic signatures to enable OPD and CD processes (when legislation available).

5.4 Clinical Decision Support

No.

Clinical Decision Support Specification Item

CDS-1

The solution MUST provide decision support which is appropriate and applicable to UK practice.

CDS-2

The solution MUST link decision support to medicines administration in order to ensure that all information, warnings and notes are available at the time the medicine is to be given. Alerts that have been overridden by the prescriber SHOULD be highlighted and be available for acknowledgement by staff administering medicines.

CDS-3

Decision support MUST include alerts on:-• Allergies, adverse reactions, intolerances• Contraindications• Dose range checking• Therapeutic duplication • Drug interactions.

CDS-4

The solution MUST provide decision support, including checking against service user demographics, diagnoses, dose calculation and other results captured in the solution.

CDS-5

The Trust MUST have the ability to locally determine which alerts and warnings may be overridden (e.g. severe allergy prevents a drug being prescribed). It SHOULD be possible to navigate back to the original data recorded (e.g. allergy) to establish context.

CDS-6

The solution’s decision support MUST distinguish service user specific from non-specific warnings and allow these to behave differently (e.g. a warning about the service user’s age will behave differently to a general warning about prescribing to a pregnant service user).

CDS-7

The solution MUST provide access to information via:-• Information entered by pharmacy• British National Formulary (BNF) and British National Formulary for Children (BNFC)• Links to the local formulary• Links to local or national prescribing guidelines • Links to external websites/online resources.

CDS-8

Decision support SHOULD include checks on pathology results.

CDS-9

Decision support MUST include the following alerts:-• Interactions of drugs with food, alcohol, smoking, or street drugs• Alerts in pregnancy• Alerts in service users who are breastfeeding• Drugs that should only be given once in a lifetime (e.g. Streptokinase) • Alerts for blood monitoring• Alerts of drug related deterioration in renal/hepatic function• Alerts of monitoring test results• Alerts associated with religious or personal preferences.

CDS-10

When alerts are generated they MUST display as soon as possible during the act of prescribing (i.e. they SHOULD NOT be triggered at the final stage of ordering if the initial selection of the medicine could have been a trigger).

CDS-11

The solution MUST facilitate the identification of those medicines that need regular blood or other tests to be performed, including baseline line monitoring. Reminders as to which tests are to be performed SHOULD be generated at the time of prescribing. An alert SHOULD be generated if the test results fall outside the recommended limits for any given drug. This alert should be sent to both the prescriber and pharmacy.

CDS-12

The solution MUST support dose checking against national dosing recommendations (including those for age), with appropriate tolerances or additional rules being allowed where there is flexibility around dosing (e.g. Diamorphine 100mg is appropriate for opiate tolerant service users but may not be for opiate naïve service users). If doses are inappropriate or outside of the parameters, then alerts MUST be generated. It MUST be possible to override these alerts, provided that a record is kept for audit purposes.

CDS-13

The solution MUST facilitate and display information to support dose conversions from one drug to another. It SHOULD suggest equivalent doses of different preparations for drugs such as opiates and steroids.

CDS-14

Information on pregnancy or breast feeding MUST be linked to decision support and updated as required. The solution SHOULD generate reminders to check/counsel about pregnancy when drugs are prescribed to women of child bearing age that could be dangerous to the foetus (e.g. Methotrexate, sodium valproate). The solution MUST facilitate the selection of medicines for an individual based on their pregnancy status.

CDS-15

The solution MUST support the implementation of action plans to respond to NPSA safety notices and recommendations.

CDS-16

The solution MUST support dose reductions in the elderly and service users with hepatic or renal impairment. This support SHOULD include a link to a renal function calculator.

CDS-17

The solution MUST identify and alert to drug disease and drug age contraindications (e.g. beta blockers in asthma, Aspirin in under 16 year olds, etc.). It MUST be possible to override these warnings with reasons.

CDS-18

The solution SHOULD offer guidance on dosage adjustment for service users on different types of dialysis.

CDS-19

The solution MUST facilitate the checking of IV fluids for drug/fluid, fluid/fluid and drug/drug incompatibilities. Warnings and alternatives SHOULD be displayed in line with local guidelines.

CDS-20

The solution SHOULD support the calculation of cardio vascular risk factors and other scores for other conditions (e.g. CHADSVASC) so that these can be used to outline which locally defined medicines may be considered for individual service users.

CDS-21

For service users on IV Aminophylline, Vancomycin and other drugs with a narrow therapeutic index that require individual dosing, decision support SHOULD provide dosage guidance and prompts reminding when drug levels are to be taken. The solution SHOULD also offer guidance on the conversion of IV Aminophylline to oral Theophylline.

CDS-22

The solution SHOULD remind prescribers of routes that may not be recommended for individuals due to specific concurrent conditions (e.g. IM (Intramuscular) injection in a service user with haemophilia).

CDS-23

More information SHOULD be offered to prescribers and people administering a medicine if the medicine is not one that is prescribed frequently. The solution SHOULD have the ability to learn what is and what is not prescribed regularly.

CDS-24

It SHOULD be possible to check the algorithms used in the solution at regular intervals so that parameters can be adjusted as necessary to meet changes in practice etc.

CDS-25

Decision support SHOULD be re-run whenever new information is added to a service user’s record.

CDS-26

The solution MUST identify who is responsible for maintaining the information that drives the decision support and its continual update.

5.5 Depot

No.

Depot Specification Item

D-1

The solution MUST allow regular, periodic prescribing (e.g. depot injections) when required/PRN, once only, and continuous intravenous prescribing.

D-2

Support for depot prescribing MUST allow the end user to define tolerances for administration.

D-3

The solution MUST be able to prescribe IM depot medication (monthly or weekly) and it MUST be possible for the end user to locally amend the frequencies.

D-4

The solution MUST enable the end user to record specific details about the site of administration in both the prescription (i.e. by the prescriber) and the administration record (i.e. by the nurse per dose).

5.6 Clozapine

No.

Clozapine Specification Item

C-1

The solution MUST provide a prompt to ensure that the service user is registered with the Clozapine monitoring service and blood test results are received prior to prescribing Clozapine. The solution will also notify locally configured specified HCPs when follow-up blood tests are required.

C-2

The solution SHOULD provide a prompt to prescribers when a clozapine assay is due.

5.7 Prescribe Medication

No.

Prescribe Medication Specification Item

PM-1

The solution MUST provide the ability to prescribe.

PM-2

The solution MUST be able to record end user and date/time stamp for prescription related events.

PM-3

The solution MUST ensure that prescribers are easily identifiable for every prescription written.

PM-4

The solution MUST provide the prescriber’s contact details and job role/prescribing team. This MUST be readily available so if there is a query with the prescription the prescriber can be contacted. This will include non-medical prescribers (e.g. nurses who prescribe, order TTO's, review medication in both inpatient and community teams).

PM-5

The solution MUST support the minimum requirements for a comprehensive prescription:-Drug name (generic and propriety if locally required) Drug form and strengthRoute and site where appropriateDoseFrequencyDose instructionsStart date and timeDuration with review date if applicableIndication where appropriateStop date and timeReason for treatment stoppingAdditional instructions (including monitoring requirements, infusion times for IVs and diluents etc.)Full name and details of prescriber (as signatory of prescription).

PM-6

The solution SHOULD prompt the end user to verify that the service user selected is the correct one. This SHOULD be supported by the availability on the screen of basic demographic details and for example a photograph of the service user or use of finger print technology.

PM-7

The solution MUST be able to select a drug by BNF/BNFC therapeutic class.

PM-8

The solution MUST allow medication to be searched by medication name or active ingredient. The medication name can be the approved name or brand name.

PM-9

The solution MUST provide links to general prescribing information at the point of prescribing such as medicines.org.uk.

PM-10

The solution MUST be able to display service user specific dosing recommendations based on age and weight.

PM-11

The solution MUST allow checking against other service user specific parameters (e.g. BMI (Body Mass Index), gender and ethnic background, renal function, genetic phenotype).

PM-12

The solution MUST be able to display service user specific dosing recommendations based on results (e.g. renal function, INR and blood sugars). These recommendations MUST be locally configurable.

PM-13

The solution MUST be able to prescribe fractional amounts of medication (e.g. 1/2 tablet).

PM-14

The solution MUST be able to prescribe pharmacy compounded preparations.

PM-15

The solution MUST be able to associate a diagnosis or symptom with a prescription. It MUST however be possible to prescribe medications without this association.

PM-16

The solution MUST be able to display the associated problem, diagnosis or indication on the printed prescription. It MUST be able to include multiple indications for each medication.

PM-17

The solution MUST be able to create user-defined specific medication lists of the most commonly prescribed drugs with a default dose, frequency and quantity.

PM-18

The solution MUST provide the ability to add comments to a prescription (e.g. why medication is being prescribed, amended or stopped).

PM-19

The solution MUST provide the capability to support non-prescribers to record the administration of a medicine without a prescription (e.g. under a “Patient Group Direction” or Simple Medicines Policy (nurse discretion list)).

PM-20

The solution MUST allow authorised individuals to sign and countersign medication orders.

PM-21

The solution MUST be able to record the service user’s previous medication (e.g. prior to admission, and reconcile that with any new regime, issuing an alert to the prescriber). This SHOULD include the use of local templates and allow this list to be refreshed easily, on a regular basis, by allowing the new list to be repopulated with the existing list.

PM-22

The solution MUST be able to display the service user’s prescription history for the current admission.

PM-23

The solution MUST be able to maintain a coded list of medications.

PM-24

The solution MUST be able to check and alert the prescriber if they try to prescribe outside of the formulary and BNF/BNFC recommended range for the service user’s age and weight (e.g. off-label dosing). The solution will allow the override and MUST mandate the prescriber to record the reason why. Reasons MUST be available in an accessible drop down list e.g. “prescribed with national / local guidelines”

PM-25

The solution MUST be able to accommodate the prescribing of variable doses (e.g. every 72hrs/ weekly/ alternate day prescribing/ warfarin dosing).

PM-26

The solution MUST be able to electronically verify a service user's prescription eligibility.

PM-27

The solution MUST enable repeat prescription management.

PM-28

The solution MUST allow an end user to reorder a prescription without re-entering previous data (e.g. administration schedule, quantity).

PM-29

The solution MUST be able to send prescriptions electronically, including the ability to document the source of prescription order.

PM-30

The solution MUST be able to identify any medication dispensed documenting the lot number and the expiration date.

PM-31

The solution MUST provide secure prescription printing and the ability to electronically fax prescriptions.

PM-32

The solution MUST be able to re-print, prompting the end user to record the reason why.

PM-33

The solution MUST allow the end user to configure prescriptions to incorporate fixed text according to the end user's specifications and to customise the printed output of the prescription.

PM-34

The solution MUST enable printing and reprinting of medication onto all FP10s with each prescription adhering to the appropriate legal requirements per page.

PM-35

The solution MUST be able to add reminders for necessary follow up tests based on the medication prescribed and SHOULD include record of acknowledgement and any action taken (e.g. ‘tests ordered’/’no action taken’).

PM-36

The solution MUST provide the ability, for an individual medication request, to define a validity time period.

PM-37

The solution MUST allow automatic stops to be applied to certain drugs and provide a notification to end users when an order is approaching its stop time.

PM-38

The solution MUST provide the use of a dosage calculation tool for service user specific dosing based on weight and age. This MUST be appropriate for both paediatric and adult and elderly service users, where dose variations are common.

PM-39

The solution MUST provide options for prescribers to decide whether to treat adolescents with paediatric or adult doses/regimens and record the reason why.

PM-40

The solution MUST allow the prescription of dressings and allow the specification of the size and quantity required.

PM-41

The solution MUST provide the ability to prescribe and administer blood products.

PM-42

The solution MUST provide an integrated HOCF (Home Oxygen Consent Form) which can also be printed-off and signed by the service user to give their consent for their details to be released to the outside oxygen supplier. The solution MUST be able to handle updates to the HOCF form.

PM-43

The solution MUST allow for the prescribing of nebulised medicines including any diluents.

PM-44

The solution MUST ensure that there is a logical workflow for continued prescription and administration of medicines in cases where medicines had been started in other clinical areas when a service user is transferred between wards and departments within the trust.

PM-45

The solution MUST allow the prescription and administration of medicines as one action (i.e. able to prescribe and administer in one transaction) in real time or after the event with each event being date/time and end user stamped.

PM-46

The solution MUST support formulary management, including a local formulary and NICE guidance, based upon a standard drugs directory reflecting the BNF/BNFC.

PM-47

The solution MUST support the ability to define a limited formulary for particular roles supported by Role-Based Access Control (e.g. dental formulary).

PM-48

The solution MUST support prescribing by medical and non-medical healthcare professionals as defined within the RBAC or by Patient Group Direction.

PM-49

The solution MUST allow prescribing by the relevant units of issue.

PM-50

It SHOULD be possible for an end user to select ‘do not show me this warning again for this service user/drug’, though these preferences SHOULD be confirmed (by notification & action) on a regular basis (e.g. monthly).

PM-51

The solution MUST allow prescribing of asymmetric doses (titrations) that can be amended as required. These SHOULD also be presented as an entire summary covering the titration period.

PM-52

The solution MUST cater for non-standard frequencies with end users able to select these without difficulty (e.g. 1000mg twice a day on two days of the week, no doses on the remaining days of the week etc.). It MUST be possible to set such frequencies as the default for a medicine.

PM-53

The solution MUST allow the set-up and use of commonly used medication regimes. These SHOULD be managed locally.

PM-54

The solution MUST allow the set-up of groups of commonly prescribed drugs.

PM-55

The solution’s prescribing functionality MUST interact with the Mental Health Act functionality to support Consent to Treatment.

PM-56

The solution MUST support prescribing of emergency medication (stat). Medication prescribed this way SHOULD be highlighted until administered.

PM-57

The solution MUST support prescribing of ‘as required’ medication (PRN) with the ability to limit the number of doses that can be administered on either a dose and/or timeframe basis (SHOULD be able to specify the minimum dose interval). It SHOULD also be possible to view the history of administration. Limitation SHOULD be based on 24 hours rather than by day.

PM-58

The solution SHOULD provide a pictorial view of the prescription, which can be scrolled forwards and backwards, with shift/day/week/month views. A timeline view for an individual service user with text or medication pictures being present would assist concordance and education interventions.

PM-59

The solution MUST allow identical actions to be performed on multiple items at once (e.g. discontinue all drugs prescribed to the service user). The reason for this MUST be recorded.

PM-60

The solution MUST allow the prescribing of medication to reflect the timing of medication administration.

PM-61

The solution MUST allow end users to search and view medication by BNF/BNFC section.

PM-62

The solution SHOULD enable BNF/BNFC maximum dose warnings during prescribing.

PM-63

The solution MUST support the routine recording of a VTE risk assessment for all inpatients. This SHOULD be linked to specific CDS support around VTE prescribing based on local guidelines.

It SHOULD be compulsory to complete this assessment before prescribing non-emergency drugs.

PM-64

The solution MUST be DM+D and SNOMED compliant.

PM-65

The solution SHOULD provide the ability to prescribe and administer medications when the service user is temporarily away from their admitted location.

PM-66

The solution MUST allow prescribing for service users who are registered with a PMI number only (e.g. an unconscious service user).

PM-67

The solution MUST allow the recording of weight and height, which SHOULD be date, time and user stamped. It MUST prompt the end user to state whether the recordings are actual or estimated and SHOULD be able to automatically calculate body mass index (BMI) and body surface area (BSA). Prompts SHOULD be given for this information to be updated at locally defined intervals.

PM-68

The solution MUST allow the service user's preference for formulation and route of medications to be recorded.

PM-69

The solution MUST support community prescribing and administration (inc. different supply routes and publication of administration charts).

PM-70

The solution SHOULD suggest a standard duration of supply for outpatient prescriptions. It SHOULD however be possible for this to be over written by the prescriber.

PM-71

Outpatient prescribing MUST support either electronic supply requests to a specified pharmacy (Acute hospital pharmacy, Lloyds pharmacy and other commercial pharmacies) or a paper copy that can be taken to another approved supplier.

PM-72

The solution MUST allow medications that were given on a previous admission or discharge to be re-prescribed in, for example an outpatient setting, without necessarily having to complete a new prescription.

PM-73

The solution MUST allow advanced prescribing of a planned episode of care, where the date of an admission in the future can be added. The prescription would only become active from the time of admission.

PM-74

The selected drug MUST be displayed as its generic name. Brand name is only to be included if clinically indicated and agreed by local policy.

PM-75

After selection of drug, the next step SHOULD be selecting the route which will subsequently narrow the range of options available for a particular drug.

PM-76

On medication selection, the drug name, form, route and strength MUST stay on screen throughout the prescribing and medication administration.

PM-77

The solution MUST support the prescribing and administration of medications administered by syringe drivers and pumps.

PM-78

The solution MUST allow parts of the prescription to be mandated so that a prescriber cannot complete a prescription until this part has been completed. This MUST be configurable by the local administrator.

PM-79

The solution MUST allow the prescriber to state multiple routes of administration for a medication when clinically indicated (e.g. SC/PO cyclizine). The administrator MUST then be able to select the route used during administration.

PM-80

The solution MUST allow free text prescribing (with controls) in the case of unlicensed medications or routes and clinical trials medications. The clinical reason for prescribing in this way MUST be recorded.

PM-81

The solution MUST allow the prescribing of dietetic products and thickeners.

PM-82

The solution MUST support safe prescribing of insulin and other high risk medications as determined by a locally configurable list (Methotrexate etc.) This will include the ability to have a variable insulin prescription.

PM-83

The solution MUST allow the specific scheduling for particular drugs (e.g. Methotrexate, transdermal CD patches)

PM-84

The solution MUST allow the prescription of certain medications to be restricted to inpatients only. This definition SHOULD be set-up locally so that it can be applied to individual medicines or groups of medicines and can be active for an individual specialty, ward, department, or location.

PM-85

The solution SHOULD highlight medications not allowable under payment by results or not available on NHS prescription and restrict prescribing of these medications to authorised personnel.

PM-86

The solution MUST support the prescription of dose loading.

PM-87

The solution MUST allow dose tapering (e.g. steroids – based on number of doses or days) and cross tapering, dose rounding, and prescription according to age, gestational age, weight, body surface area, renal or hepatic function etc.

PM-88

The solution MUST mandate the duration of treatment for some drugs (e.g. antibiotics).

PM-89

The solution MUST allow prescribing of antibiotic prophylaxis.

PM-90

The solution MUST allow the prescribing of the final infusion as a single entity.

PM-91

The solution MUST allow the end user to specify the duration of treatment. The following SHOULD be supported:-• A fixed duration of treatment• length of duration by doses, days, weeks, months• A review date and time• Long-term therapy without a fixed duration (i.e. dependent on monitoring or investigation results).

PM-92

The solution SHOULD support the appropriate management of black triangle medicines (i.e. newer medicines that are subject to more intense monitoring by the MHRA). The solution SHOULD allow black triangle medicines to be flagged by the Trust and display a reminder about black triangle medicines to prescribers using the solution (i.e. a black triangle MUST be displayed against the name, plus words to the effect that “All adverse drug reactions associated with these medicines SHOULD be reported to MHRA via the Yellow Card Scheme”).

PM-93

It SHOULD be possible for the solution to prompt the end user to assign a level of urgency or priority when the medication is dispensed. This SHOULD be locally flexible to allow for authorised end users to be granted access (or not) to this facility.

PM-94

It MUST be possible to prevent the prescribing of a non-formulary drug completely or to limit certain drugs to specific end users, grades, specialties or locations, or a combination of these, on a local basis (CD stock lists based upon site/location i.e. palliative care). Where this is the case, there MUST be the facility to display information to support this restriction, and this information SHOULD be customisable on a local basis.

PM-95

It SHOULD be possible to locally define specific medicines (or groups of medicines) and doses where their initial prescription is limited to certain specialties only (e.g. steroid eye drops may only be prescribed by ophthalmologists).

PM-96

The solution MUST support restrictions (by end user, user type, specialty and/or location) on who can prescribe cytotoxics in non-oncology specialties.

PM-97

The solution MUST highlight during prescribing, administration and the pharmacy clinical check those medicines selected that are unavailable on NHS prescriptions.

PM-98

The solution MUST warn end users of therapeutic duplication but allow this under certain circumstances, with a reason for prescribing despite warning.

PM-99

Suppliers MUST indicate how their solution supports paediatrics.

The solution SHOULD have the ability to have weight based BMI, BSA and aged based dosing.

The solution SHOULD have flexibility in terms of drug administrations.

The solution MUST support unlicensed/off label use of medicines.

The solution MUST support Paediatrician only prescribing for some medications.

PM-100

The solution MUST avoid the unnecessary use of decimal points (e.g. 3 mg not 3.0 mg/ 500mcg not 0.5mg).

5.8 Pharmacy Communication

No.

Pharmacy Communication Specification Item

PC-1

The solution MUST allow the end user to input, modify, inactivate, delete, update, display, print, transmit and receive electronic information between prescribers and pharmacies or other intended recipients (e.g. other care agencies or other healthcare providers) of the medication order.

PC-2

The solution MUST support the recording of pharmacy verification. This process may warn end users if verification has not occurred in a given timeframe (e.g. 2 days), but the absence of verification will not be a barrier to administration.

PC-3

The solution MUST allow the pharmacist to send messages to the prescriber for further checks or requests for information on prescribed medications.

PC-4

The solution MUST provide the pharmacist with the ability to modify medication request details within certain parameters without the need for prescriber verification.

PC-5

The solution MUST provide the ability to add pharmacist comments to the medication request during verification.

PC-6

The solution MUST provide the ability to specify service user appropriate directions that could appear on a medication label.

PC-7

The solution MUST provide the ability to locally configure warnings that apply to a specific prescription where some warnings may not be cancelled but instead require acknowledgement.

PC-8

The solution MUST be able to integrate with stock control and other systems as required to minimise duplicate data entry.

PC-9

The solution SHOULD support the electronic transmission of prescriptions to a selected community pharmacy.

PC-11

Once the prescription is completed it SHOULD be available electronically at a pharmacy/dispensary used by the Trust

PC-12

The solution SHOULD allow alerts to pharmacy on the prescribing of certain medications (e.g. urgent or medications that take a long time to prepare) and automatically send to pharmacy medications that need to be authorised.

PC-13

The solution MUST allow the ability to prepopulate some medications/medication classes with relevant pharmacist instructed comments.

PC-14

The solution MUST be able to generate ward work lists with sort and filter functions to show service users who have medications that have not been clinically checked by a pharmacist.

PC-15

It MUST be possible to query or report on non-clinically checked orders per ward. This SHOULD be in real time for work lists but historical for audit and service evaluation purposes.

PC-16

The solution MUST allow/permit a pharmacist to add, amend/edit and cancel prescriptions with reasons recorded, without replacing the original prescriber details.

PC-17

The solution MUST be able to record and indicate against each prescribed medication whether or not it has been clinically checked by a pharmacist and MUST be able to indicate the level of the check (e.g. ‘checked and authorised’, ‘checked and NOT authorised’).

PC-18

The clinically checked status of an order MUST be consistent and visible throughout all areas of the solution (i.e. prescribing, administration etc.).

PC-19

The solution MUST be able to support addition of ward stock lists to prompt the pharmacy or nursing team to what medication are kept in stock.

PC-20

It MUST be possible to highlight which medicines need specific counselling. This SHOULD be locally configurable.

PC-21

The solution MUST support the facility to display and update information about specific medicines or groups of medicines based on national announcements (e.g. drug withdrawals, MHRA announcements, warnings, CAS alerts etc.). The importance of this information to be locally determined.

5.9 Medicines Management

No.

Medicines Management Specification Item

MM-1

Supply requests MUST be generated within the prescribing solution for transfer to the dispensing solution, provided that the item is not identified as a service user's own medication or ward stock. Supply requests MUST NOT be actioned in the dispensing solution until the script has been clinically checked (minimum basic check) by a pharmacist.

MM-2

The solution SHOULD facilitate the setting of a local budget for a specific medicine or a group of medicines, for a number of service users or for an individual service user and specialty or location if required. When requested, information SHOULD be generated to screen outlining the budget remaining and/or committed. This SHOULD display passively when a budget limit is approaching (as defined locally). When the budget is limited for a specific number of service users, information SHOULD be passively available on screen during the prescribing process to indicate the current status. Alerts SHOULD only be generated if limits or targets are reached.

MM-3

It MUST be possible to identify the source, using a locally configurable drop down list, of the medicine that a service user is utilising during an inpatient stay, with this information transferring to the discharge prescription to inform the source of supply. These categories may include:-• Ward stock

• Service user’s own stock on ward

• Service user’s medication at home

MM-4

It MUST be possible for the solution to support the recording of the number of tablets a service user has of their own on admission. This information SHOULD then be available within the discharge prescription information, together with the date when the record was made so that the pharmacy can identify which medicines may not require supply.

MM-5

The solution SHOULD aim to move towards full ward stock reconciliation so that an order can automatically be sent to the appropriate supply source when the stock levels are low.

MM-6

The solution SHOULD support interfacing/integration with the main stock control solution in order to inform the wards and/or prescribers if stocks of a certain drug are low or have a manufacturing problem. This SHOULD generate information during the process of prescribing and administration or be available as a lookup facility. It SHOULD also be possible to attach information to identify alternatives available.

MM-7

The solution SHOULD support interfacing to electronic supply cabinets or cupboards which allow access to the correct medicines once they have been prescribed and/or are due to be given.

MM-8

The solution MUST distinguish between a NHS service user and a private service user for both prescribing and costing purposes.

MM-9

The solution MUST be able to upload and print medication history received electronically and for the end user to enter, modify, deactivate, update and display that information in the service user’s record.

MM-10

The solution MUST be able to allow the end user to enter, modify, deactivate, “delete”, update, display, copy and print medication lists.

MM-11

The solution MUST provide the ability to set medication reviews with appropriate notifications and be able to indicate that a medication list has been reviewed/screened.

MM-12

The solution MUST be able to allow the end user to enter, modify, deactivate, "delete", update, display, copy, and print all prescribed medication related information.

MM-13

The solution MUST allow the medication record to be produced in a printable format. This will include medication history, current medication and administration record.

MM-14

The solution MUST provide the ability to enter certain medical devices and non-prescription medications including over the counter and complementary medications such as clinical trial drugs, vitamins and supplements.

MM-15

The solution MUST allow authorised end users to exclude a medication from the current medication list and document the reason for such action.

MM-16

The solution SHOULD be able to notify locally determined healthcare providers that a service user’s prescribed medication might be running out.

MM-17

The solution MUST allow the local administrator to input, modify, inactivate, “delete”, update, display, copy, and print medication information in any medication formulary list.

MM-18

The solution MUST allow the local administrator to input, modify, inactivate, “delete”, update, display, copy, and print medication formulary rules and guidelines.

MM-19

The solution MUST provide online access to the BNF/BNFC. The Service provider may also wish to have online access to other systems (e.g. First Light).

MM-20

The solution MUST allow the local administrator to input, modify, inactivate, “delete”, update, display, copy, and print locally defined prescription templates.

MM-21

The solution MUST provide the designation of a medication item as a service user’s own medication.

MM-22

The solution MUST enable the management of suspended medication.

MM-23

The solution MUST enable medication history to be recorded, or imported, where the solution does not maintain the service user's prescription.

MM-24

The solution SHOULD be able to maintain previous service user medications history, including where medications have been stopped and reasons, who provided the information for recording (e.g. service user, carer, GP etc.) allowing it to be incorporated into an Electronic Discharge Summary.

MM-25

The solution MUST be able to record that a service user has no medication history.

MM-26

The solution MUST be able to record illicit drugs use/frequency, smoking quantity/ frequency and alcohol consumption quantity/frequency.

MM-27

The solution MUST be able to record nebulised medications and home oxygen together with the dose/concentration and device.

MM-28

When viewing the prescription chart, it MUST be clear which medications are newly started and which medications were started prior to the service user's admission.

5.10 Medicine Administration

No.

Medicine Administration Specification Item

MA-1

The solution MUST display clearly the identification of the service user (to include first and last name, date of birth, address, Trust’s EPR number, NHS number, and the possibility to include a photograph of the service user) for whom medicine(s) are being prescribed and/or administered to prevent errors. The service user's identification MUST be visible at all times.

MA-2

The solution MUST record and date stamp when medication is administered to a service user for each medication administered. The solution will automatically record who administered the medication through the access control process. The solution will also be able to record who verified the administration (where required) and details such as route, dosage administered etc.

MA-3

The default time stamp for administration of medicines MUST be the actual time of administration rather than the time the medication was due.

MA-4

Via a locally configured drop down list, the solution MUST be able to record where medication has not been administered (e.g. medication not available, service user refused etc.). The solution MUST also allow the end user to easily record where previously non-administered medication was subsequently administered (e.g. where previously refused or previously unavailable medication was administered at a later time).

MA-4b

It MUST be possible to record multiple attempts made to administer a single dose (e.g. a single dose could have 5 records of attempted administration associated with it).

MA-5

It MUST be mandatory to record reasons for non-administration or deferred administration from a locally configured list of reasons (e.g. as per the reason codes 1 to 8 on the current administration chart), augmented by clinical notes if necessary.

MA-6

The prescribed dose must appear as the default dose, but it MUST be possible to record the actual dose administered (e.g. a partial dose) and a reason for this, if different from that prescribed.

MA-7

It MUST be possible to administer a medicine earlier than the prescribed/scheduled time but within a specified timeframe that is locally configurable.

MA-9

The solution MUST provide the ability for a prescriber to insert customisable and generic administration instructions which are easily visible and accessible from the eMAR.

MA-10

The solution MUST provide the ability to record batch numbers for administered medications using administration comments.

MA-11

In line with the Trust’s Self Administration policy, the solution MUST provide a locally defined assessment, of a service user’s ability, including mental capacity, to self-administer a medication and to record their consent or otherwise with a built in review/expiry date.

MA-12

The solution MUST allow the eMAR to be printed and the ability to scan the printed copy in such a way that it can be read by a computer to create an electronic record rather than just a scanned picture of a medications chart.

MA-13

The solution MUST provide ability to record "who" (e.g. carer/parent/guardian, nurse etc.) is/would be responsible for administering medication.

MA-14

The solution MUST provide the ability to document all required medication reconciliation events for a service user and provide a prompt where a reconciliation event has not occurred.

MA-15

The solution MUST enable drug administration times, in a numerical format, to be set per prescription, per service user and the solution MUST allow for the recording of additional instructions such as before meals.

MA-16

In line with the Trust’s Self Administration policy, the solution SHOULD enable self-administration periods to occur without a warning being displayed to staff (e.g. where leave is recorded and confirmed).

MA-17

The solution MUST be able to amend administration settings automatically when an inpatient is on leave.

MA-18

After securing the service user’s consent, the solution SHOULD be able to send mobile telephone text messages to a service user to remind them to take their prescribed medication. Where the service user replies to the text message, it SHOULD be recorded in the solution (e.g. a 'YES' reply could update the service user's record as having self-administered).

MA-19

The solution MUST allow prescribed and/or administered medications to be viewed over a variety of time frames (e.g. daily, weekly, monthly, three months at a time) with the default view being set to the current day.

MA-20

A warning MUST be triggered by the solution when maximum doses of PRN medication are reached. This MUST occur on a rolling period basis (e.g. 24 hours, not by date).

MA-21

End users MUST be able to search and access the medicines administration functionality by ward, consultant, community team, caseload for a community team, drug round times (administration schedules) or by individual service user.

MA-22

The solution MUST provide a view of all overdue medication on a given ward.

MA-23

The solution MUST allow the start time of prescribed medication to align with the time the drug is supplied (i.e. so doses are not missed if the drug is unavailable).

MA-24

The solution SHOULD allow closed loop medicines administration, supporting the goals for Scan4Safety for safety.

MA-25

After completion of the relevant template, the solution MUST allow the administration of covert medications but with a built in review date alert/notification function for specified staff. The option to administer covertly MUST be ‘locked’ where a review is not completed before the given date and is only unlocked after the review is completed.

MA-26

The solution MUST allow for early and late administration of depot medicines within certain predefined limits that are locally configurable.

MA-27

The solution MUST allow the recording of 'Nil by mouth' and which medications can be administered whilst the service user is nil by mouth.

MA-28

The solution SHOULD not allow administration of suspended medications and SHOULD allow the end user to edit the duration of the suspension.

MA-29

The solution MUST support the requirement, by local configuration, that some medicines prescribed MUST NOT be administered before a clinical check by a pharmacist and/or in circumstances such as the use of restricted antibiotics requiring microbiologist approval. However, in most cases the solution MUST NOT prevent the administration of medication that has yet to be clinically checked.

MA-30

It MUST NOT be possible to undertake administration without viewing all of the current medicines prescribed, together with all administrations within the past 24 hours.

MA-31

The solution MUST highlight medicines (e.g. Parkinson's medications) which MUST be given at critical times and provide alerts if these times, which are locally configurable, are breached.

MA-32

When an end user accesses a service user's medicines administration record, the solution MUST display all outstanding doses. However, the solution MUST be able to differentiate between an inpatient and a community service user who may be prescribed medications by the Trust but the administration will take place by the patient at home and therefore the clinician will not be required to update the administration record.

MA-33

There MUST be warning alerts, including escalation procedures to identify overdue medicines and end users MUST be able to view when the next dose is due. However, the solution MUST be able to differentiate between an inpatient and a community service user who may administer medications at home meaning such alerts will be unnecessary.

MA-34

The solution MUST NOT allow more than one service user's record to be accessed at any one time for actual preparation or administration of medicines.

MA-35

Prior to administration, the solution SHOULD provide any relevant advice on the reconstitution of medicines and use of diluents. This may be done by directing the end user to an external source (e.g. MEDUSA).

MA-36

The solution MUST allow locally configurable prompts to inform nursing staff of any particular medicines storage (e.g. refrigerator) or handling requirements at the point of administration.

MA-37

It MUST be possible, through local configuration, to administer some medicines without restrictions in frequency.

MA-38

The solution MUST provide an accessible and viewable prompt when a service user is on a MHA section and compliance with T2, T3, CT01 and CT02 forms is required.

MA-39

It MUST be possible to record the site (e.g. left/right side, deltoid initially next dose gluteal etc.) of administration where this is not explicit in the prescription.

MA-40

It MUST be possible for all appropriate end users to add notes to the administration record and for this to be viewed easily. For example, it MUST be possible to annotate a record to show that the actual administration of a medicine was slightly different to that prescribed (e.g. tablets dissolved rather than swallowed with rationale recorded in the note).

MA-41

The solution MUST support the administration of more than one infusion being used over a period of time to complete a prescription (e.g. two 500 mL bags used sequentially to infuse 1L over 8 hours).

MA-42

The solution MUST display a clear, legible and complete overview of all historic and outstanding administration events for the current admission.

MA-43

The solution SHOULD support the generation of reminders in the medicines administration pathway to update the end user that the medicines for a service user in their care has altered since the last recorded medicine administration for that service user. In certain wards or departments this reminder may be displayed when the end user accesses the solution.

MA-44

The solution SHOULD enable authorised end users to initiate the replenishment of drugs from within the medicine administration function if ward stocks are low.

MA-45

The solution MUST be able to automatically return to the ward view after medicines have been administered. The end user SHOULD not have to re-select the ward between administrations.

5.11 Simple Medicines Policy and Patient Group Directions (PGDs)

No.

Simple Medicines Policy and Patient Group Directions (PGDs)

SMP-1

The solution MUST support the use of the Simple Medicines Policy and Patient Group Directions (PGD) for all groups of healthcare professionals that may legally utilise them (e.g. Occupational Therapists, Physiotherapists etc.) by area. When a drug is supplied or administered using this facility it will be clearly identifiable as such within the records and on any displays.

SMP-2

The solution MUST identify the individual for whom a specific direction is applicable and manage access to allow the supply or administration to be recorded when a PGD is employed. Links to decision support will be in place to facilitate checking of the request against any other medicines being taken by the service user.

SMP-3

The solution MUST provide access to the details of the actual PGD via links to local documentation.

SMP-4

Where local agreement requires, the solution MUST ensure that medicines available under PGD can only be accessed by authorised HCPs in certain parts of the solution. A locally derived limited formulary list MUST be configured/utilised to facilitate this.

5.12 Discharge Prescribing

No.

Discharge Prescribing Specification Item

DP-1

The solution MUST seamlessly support conversion of an inpatient prescription into a ‘TTO’ for home leave and discharge purposes for a defined length of treatment.

DP-2

The solution MUST support discharge prescribing (via interfacing/integration) in a manner which mirrors inpatient and daycase prescribing as closely as possible. The drug lists that are accessed MUST comply with other controls (formulary lists) used in other prescribing areas in the solution, including the use of order sets.

DP-3

The solution MUST have appropriate outbound API’s that will allow the Trust to support the transfer of discharge prescription and/or medication information to GPs, community pharmacists and a small group of designated commercial pharmacy and Homecare providers. As part of the solution’s standard workflow processes, it MUST be able to push Electronic Discharge Summaries to receiving parties.

DP-4

The solution MUST support the transfer of a discharge prescription and/or medication information electronically to other locations (e.g. other hospitals).

DP-5

Discharge prescribing MUST be paperless. However, the solution MUST support discharge prescription and/or medication information being given to the service user or sent to the GP on paper when electronic transfer is not possible. This should include discharge to other providers.

DP-6

The outbound API information MUST include:-• Service user identifiers• Drug name (generic or proprietary if locally required), form, strength, dose, frequency and duration.• Status of supply• Indication for some medicines• Whether medication has been stopped, started or continued• Additional administration instruction • Instructions for the GP about continuing the treatment, further review and monitoring• Additional information from the checking pharmacist• Instructions for pharmacy dispensing to ‘Increase font size’• The reasons why any previous medicines have been stopped, whether on a temporary or permanent basis• The option to request any compliance aids required by the service user - including any compliance aid assessment.• Any stop dates for specific medications

DP-7

Discharge prescriptions SHOULD include an indication of when they are required by the service user (i.e. what is the estimated time of discharge).

DP-8

Antimicrobials on the discharge section MUST have an indication as to why it has been commenced and a stop date unless clinically inappropriate.

DP-9

It SHOULD be possible for the solution to prompt the end user to assign a level of urgency or priority when the TTO is dispensed. This SHOULD be locally flexible to allow for authorised end users to be granted access to this facility. In this context, it SHOULD have an estimated date of discharge that is received electronically from the Trust’s Prescription Tracker.

DP-10

It MUST be possible to pre-prescribe or partially prescribe a discharge prescription for a service user and complete/authorise it at a later date. The solution MUST permit the prescriber to add new items to the discharge prescription, and to discontinue and modify existing ones.

DP-11

It MUST be possible to generate discharge prescriptions from inpatient medicine lists, including safeguards for review of PRN, parenteral and rectal medicines.

DP-12

If controlled drugs are being prescribed for discharge, the solution MUST support the production of a hard copy of the discharge prescription in the required format for a handwritten signature.

DP-13

If controlled drugs are being prescribed for discharge, the solution MUST comply with the Misuse of Drugs Act 1971 and with any additional information required to the ensure prescription is legal.

DP-14

The solution MUST allow medicines to be locally highlighted if they are not to be prescribed on discharge. This MUST prompt a review by the prescriber if the medicine is selected as part of the discharge process.

DP-15

The solution MUST alert end users to review the discharge prescription if changes have been made to an inpatient prescription after the discharge medicines have been prescribed.

DP-16

Discharge information MUST make it clear if the service user is going home with their own medicines which they brought in on admission, if they already have a supply at home, or will be having their medication delivered by a specialist homecare provider.

DP-17

If the service user was previously taking a medicine which was stopped or suspended during admission, the solution MUST have the ability to link this discontinuation to the discharge information, such that the information will be available on discharge with the reason for stopping it.

DP-18

If a recommendation is made to the service user to buy a certain medicine as it is a cheaper option, this information SHOULD be transferred to primary care as part of the discharge information or outpatient information.

DP-19

The solution SHOULD be able to send a copy of the discharge medicines information, in either electronic or paper format, to the service user's regular nominated community pharmacy in order to ensure continuation of supply, providing that the service user is in agreement.

DP-20

Clinical checking of discharge medicines by pharmacists MUST be supported. The status of checking MUST be visible within the medicines record and be incorporated into discharge information communicated onwards. Transfer of prescriptions to stock control solutions for supply MUST NOT occur without validation having been undertaken. It MUST be possible to delay discharge and/or transfer of discharge information from the solution until checking has been undertaken.

DP-21

The solution MUST support the ability to prescribe short leave (weekend leave) medications in a similar manner to discharge medicines. These prescriptions SHOULD be identified as being different to discharge prescriptions in all views within the solution. When leave medicines are prescribed, the duration of the leave MUST be defined either within specified time frames or for a set number of days. The solution MUST support the automatic presentation of leave status in the drug administration record so that the nurse does not have to keep completing a record for each drug round, and all end users know that the service user is on leave. If a service user returns early, it MUST be possible to remove the automatic administration record so that manual recording can begin again.

DP-22

The solution SHOULD support the ability to highlight a drug/group of drugs as being covered by a shared care arrangement (e.g. for diabetes, asthma, or antenatal care etc.).

DP-23

The solution SHOULD record whether a service user is on a nebuliser and make this information available during the discharge process in order to highlight appropriate ordering requirements.

DP-24

If a medicine has not been collected, an alert SHOULD be generated which prompts follow up by the prescribing team according to locally agreed procedures.

DP-25

The solution SHOULD allow the generation of reminders to service users via text messages, mobile phone codes or email that their medicine(s) needs collecting.

DP-26

The solution MUST support TTO prescribing for varying amounts of time and the production of a prescription summary using locally configured templates that can be sent to the service user’s GP and incorporated within a discharge summary.

DP-27

The solution should be able to include any locally developed discharge initiatives.

5.13 Reports

No.

Reports Specification item

R-1

The reporting functionality, MUST NOT impact on the performance or the normal working of the solution.

R-2

The solution MUST store all data items used within the solution. End users MUST be able to define reports on any of the stored data items.

R-3

The solution MUST provide flexibility for the extraction, combination, analysis and reporting of all data recorded in any part of the solution (e.g. prescription modification, pharmacy validation, medicines administration, missed administrations, costing etc.) into a data warehouse environment.

R-4

All actions performed within the solution MUST be auditable by being date, time and end user stamped to enable the Trust to improve accountability and governance. This auditable capability MUST be utilised to generate reports and MUST be readily available for local administrators at all times.

R-5

The solution MUST be sufficiently flexible to enable statutory reporting for both clinical and management requirements.

R-6

The solution MUST be sufficiently flexible to enable locally determined reports for both clinical and management requirements (e.g. to support NICE requirements).

R-7

Alongside the solution's standard reporting functionality, it MUST be possible for the end user to locally tailor data to an output of their choosing (e.g. Excel).

R-8

Specifically, it MUST be possible for end users to report by and use filter functionality for the following:-• Service user• Date and time parameters• Ward• Specialty• New admissions• Drug/medicine (individual and also by therapeutic/BNF or BNFC classification) • Diagnosis/disease• Intervention• Clinician• Pharmacy• HRG/SNOMED codes• Financials.

R-9

The solution SHOULD be sufficiently flexible to support local development of competence amongst prescribers. For example, when the number of prescriptions requiring correction is abnormally high, the solution SHOULD automatically track this back to individual prescribers and notify them so that clinicians know when they make mistakes. Also, the solution SHOULD record details of these corrections so that report(s) can be generated enabling the Pharmacy Directorate to track trends and identify prescribers making more than an acceptable number and type of prescribing errors, which may indicate an educational requirement or the need for remedial action.

R-10

The solution SHOULD be sufficiently flexible to support continuous professional development and local development of competence amongst medicines administration personnel. For example, when the number of prescriptions being administered late or the number of administration records needing correction is abnormally high; the solution SHOULD automatically track this back to individual members of staff and notify them so that they know when additional educational, training or practice improvements are required. Likewise, the solution SHOULD also have the facility to generate report(s) which management can utilise for audit purposes.

R-11

The solution SHOULD support the display of costs for individual medicines, on a locally defined basis if required. There SHOULD be the functionality to support financial reporting for internal cost centres. It SHOULD be possible to generate reports that summarise/detail the costs of medicines prescribed and administered to individual service users, or groups of service users, within the solution to support clinical audit, payment by results and commissioning.

R-12

The solution MUST allow for the recording of a user definable text string to identify the Trust's corporate title, so that it is available for display on all report headings and footers.

R-13

The solution MUST have a comprehensive Database Schema, showing all relationships/links between key data tables and be provided to the Trust.

R-14

The solution MUST have a comprehensive Data Dictionary to support the schema and be provided to the Trust.

R-15

The solution MUST use an industry standard, ODBC compliant database, with the supplier able to determine what system they use.

R-16

The solution architecture MUST be flexible to allow the Trust read-only, direct access to the back end database, to allow for the automated extraction of data.

R-17

The solution MUST allow reports to be printed on any industry standard printer, without any requirement for specialised printing hardware or software.

R-18

The solution MUST allow any report to be printed upon any specified printer, and individual printer tray, catalogued within the system, whether that printer is attached directly to the originating PC, or attached to a separate PC, or is attached directly to the network.

R-19

The solution MUST allow the contents of a screen to be printed at any time. The solution MUST have an auditable trail with regards to printing from the solution.

R-20

The solution SHOULD provide the ability to print in hard copy, as well as download the contents of reports into standard desktop software (e.g. Microsoft Office, PDF) and print from there.

R-21

The solution MUST allow any print job to be aborted without adversely affecting the solution.

R-22

The solution MUST always print the PMI Number, NHS Number, the service user's surname and date of birth as standard upon any correspondence with the service user, GPs, other Healthcare professionals and organisations. This applies equally to operational and management reports referring to an individual service user, except in services where such data is typically encrypted/withheld such as sexual health. This service would provide a patient identifier code, but would not normally record name.

R-23

The solution SHOULD produce a report detailing each end user’s access rights.

5.14 Technical

No.

Technical Specification Item

T-1

The Trust is an equal opportunities employer and the supplier MUST show how a range of disabled personnel (e.g. sight issues) can access the solution.

T-2

The supplier MUST provide a concurrent licencing model that will allow up to 500 staff members to work concurrently without impacting the solution’s performance or any end user based activity.

T-3

It MUST be possible to uniquely identify all end users of the solution.

T-4

The solution MUST integrate with the Trust's Microsoft Active Directory environment so that the end user details and password held in Active Directory can be used to access the solution. Where the end user password is held in the solution itself, then it MUST be encrypted.

T-5

The solution MUST be compatible with the use of a Single Sign On solution (e.g. Imprivata).

T-6

The supplier MUST state their approach for temporary logins for agency/bank staff.

T-7

The solution MUST NOT display an entered password on a screen.

T-8

The solution MUST only allow the local administrator or a designated ‘super user’ to set up new end users on the solution.

T-9

All end users MUST be allocated with a security access/job role profile. The solution MUST only allow the local administrator or a designated ‘super user’ to allocate an end user with a security access/job role profile. This will determine the access rights of each end user.

T-10

All security functions MUST be controllable by a local administrator.

T-11

The solution MUST be able to support local configuration of user roles (e.g. the expanding ward technician job role).

T-12

The solution MUST automatically logout an end user after a locally defined period of inactivity without affecting the solution’s integrity.

T-13

The solution MUST limit (e.g. 3) the number of attempted login failures, providing an intruder detection and lockout facility. It would be preferable if this function was locally configurable so that the number of login failures can be adjusted in line with any future changes in Trust policy.

T-14

The solution's response times to an end user’s action SHOULD be less than 3 seconds.

T-15

The service user banner (including demographics and allergies/intolerances) MUST be prominently displayed in all areas of the solution, including when the end user moves from one screen to another.

T-16

It MUST be possible to search for the service user by a local ID, NHS number, their name (inc. soundex), date of birth, consultant and ward/clinic.

T-17

The solution MUST record a comprehensive audit trail (including date, time, computer name, device where tablets are used and end user details) of all significant database updates.

T-18

The solution SHOULD minimise the need for repeated data entry by retention of context data (e.g. a service user's identifying details) for re-use at a higher level when a lower level function has been invoked and completed.

T-19

The solution MUST operate with UK terminology and characters.

T-20

The solution MUST use a 24 hour clock and standardised date and time formats throughout the solution.

T-21

The solution MUST automatically cater for clock changes (summer and winter) and this MUST be reflected in the audit trail.

T-22

The solution MUST record the current date and time from a central clock (e.g. using NTP) for the whole solution and not from clocks on individual PCs.

T-23

The solution SHOULD allow default recording of the current date to "today" and time to "now" for activities which are normally performed on-line.

T-24

It MUST be possible for more than one person to view a service user's medication list at any one time. However, only one person MUST be able to update the active medications list at any one time unless safeguards are in place to prevent incidents. The supplier to explain how they handle concurrency collisions (e.g. is there a record locking function?).

T-25

The solution MUST be capable of lasting for an asset life of at least 5 years of continual heavy daily usage and the supplier MUST undertake to provide support throughout this period

T-26

Alongside the solution's Live environment, the supplier MUST provide other environments (e.g. User Acceptance Testing (UAT), Testing, Training, QA) with the same data feeds as the Live environment. The supplier is to state whether these additional environments use the same server as the Live environment.

T-27

The solution MUST provide the ability to copy reference data between the various environments of the solution. Service user data copied to the other environments (e.g. the Training environment) MUST be scrambled so service users cannot be identified.

T-28

The supplier MUST explain how local set-up/configuration will not be lost when new versions of the product, which are version controlled, are introduced.

T-29

The Training environment MUST incorporate a rollback function to assist with training. It is preferable for the rollback function to be held by the Trust.

T-30

The supplier MUST outline their expectations of the Trust’s responsibilities for training.

T-31

The supplier MUST provide appropriate training resources and documentation for local administrators, the Trust’s IT Training team and for end users.

T-32

The supplier MUST explain their approach to on-going end user training and product support. This MUST include:-· On-going training for new end users· Support and training for newly appointed local administrators

· Refresher training for local Training team· Refresher training for local administrators and for end users· Specific training for major upgrades and future rollouts.

T-33

The supplier MUST state the process for backups and data restoration taking into consideration the Trust’s current backup policy.

T-34

The solution MUST cater for wireless and mobile (using tablets) prescribing and medications administration at the service user's bed side. In the case of mobile technology the solution MUST not lose data in the event of signal dropping.

T-35

The solution SHOULD cater for the use of standard machine readable codes such as RFID codes, so that high cost or high risk drugs can be tracked wirelessly in the future. If the solution does not support this, the supplier SHOULD detail plans for developing this functionality along with any additional costs.

T-36

The solution SHOULD cater for the use of barcodes and QR codes conforming to GS1 standard. If the solution does not support this, the supplier SHOULD detail plans for developing this functionality along with any additional costs.

T-37

The solution MUST be compatible with the Trust’s IT standards. The supplier to list standards for:-·Interface(s)

·FHIR compliance·Networking·N3/HSCN·Datacentres·Server·Remote Access·Smart cards ·PC standards (desktop and laptop) ·Mobile technology (tablets) ·Version of Windows, standard desktop software, explorer version or Chrome, Antivirus software ·Java·Citrix·Printer·Active Directory

·OpenEHR.

T-38

The supplier MUST state the links the solution will have to other systems, including:-·CareNotes (the Trust's electronic patient record) ·EVIE (clinical information shared between the Trust and local GPs) ·Electronic Discharge Summary (EDS) ·ICE (pathology results) ·Pharmacy Stock Management system ·Trust Formulary as well as BNF, BNFC, DM+D, SMOMED codes.

T-39

The supplier MUST indicate how they would provide functionality that will allow the ePMA solution to be integrated with the EVIE system (or another system) allowing the end user to launch ePMA seamlessly and in the context of the service user from EVIE.

T-40

A bi-directional interface MUST operate in a seamless way for end users (e.g. how it handles refreshes, errors, inconsistencies, amendments, merges and the maintenance of data quality).

T-41

The bi-directional interface MUST be able to handle the Patient Master Index (PMI), Admission, Discharge and Transfer (ADT) and allergy data.

T-42

The solution MUST be able to push medications and allergy information to other Trust systems (e.g. CareNotes, Electronic Discharge Summary).

T-43

The solution SHOULD generate an outbound API that identifies outstanding medications that will allow the Trust to integrate eMPA information with ward based electronic whiteboards to prompt nursing staff to review any outstanding medication administrations.

T-44

The solution MUST have a way of informing the local administrator or the “superuser” group when the proposed interfaces are not operational. If appropriate, the system SHOULD also inform end users when they first log onto the solution and a message SHOULD be sent to end users already logged on.

T-45

The solution MUST ensure that when interfaces are re-activated, the solution will handle retrospective interface file feeds in a controlled and strictly chronological manner.

T-46

The solution MUST lock down the record when a service user's death is recorded in another system as this will stop prescribing to a deceased service user. However, end user's SHOULD be able to annotate the service user's record.

T-47

The solution MUST be capable of functioning during downtime or other disruptions (e.g. interface issues). In the case of interface related issues, it MUST also be possible to bring both systems in line when the issues are resolved.

T-48

The solution SHOULD have the ability to create medication orders that can be sent to pharmacy for label production and assembly.

T-49

The solution MUST use and maintain a comprehensive drug reference file using the national drug dictionary (dm+d) descriptions and identifiers. For all drug