Www.eprescribingtoolkit.com



Output Based Specification For the procurement of a Trust-wideElectronic Prescribing and Medicines Administration (ePMA) SolutionTable of Contents TOC \o "1-3" \h \z \u 1.Purpose of this document PAGEREF _Toc507586992 \h 32.Introduction PAGEREF _Toc507586993 \h 63.Business Context PAGEREF _Toc507586994 \h 64.Trust Infrastructure and Standards PAGEREF _Toc507586995 \h 65.Functional Requirements PAGEREF _Toc507586996 \h 75.1Drug Allergies and Interactions PAGEREF _Toc507586997 \h 75.2Alerts PAGEREF _Toc507586998 \h 95.3Controlled Drugs PAGEREF _Toc507586999 \h 115.4Clinical Decision Support PAGEREF _Toc507587000 \h 135.5Depot PAGEREF _Toc507587001 \h 175.6Clozapine PAGEREF _Toc507587002 \h 185.7Prescribe Medication PAGEREF _Toc507587003 \h 195.8Pharmacy Communication PAGEREF _Toc507587004 \h 285.9Medicines Management PAGEREF _Toc507587005 \h 305.10Medicine Administration PAGEREF _Toc507587006 \h 335.11Simple Medicines Policy and Patient Group Directions (PGDs) PAGEREF _Toc507587007 \h 385.12Discharge Prescribing PAGEREF _Toc507587008 \h 395.13Reports PAGEREF _Toc507587009 \h 435.14Technical PAGEREF _Toc507587010 \h 476.Abbreviations PAGEREF _Toc507587011 \h 56Purpose of this documentThe 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. StatusVersionDateActioned ByDescriptionDraft1.025/01/2018Nilam Bola and Katie BaluDraft ePMA Specification for Comment.Prepared for distribution to Trust personnel. Draft1.129/01/2018Nilam BolaDraft ePMA Specification for Comment.Re-ordered for distribution to medics:-Dr Simon ChallandDr Martin CurticeDr Ian DouglasDr Charlotte HullDr Louisa JamesDr Hannah LiuDr Sangram PathaniaDr Kirsty ProtheroughDr Tara WalkerDr Anna WilkinDraft1.229/01/2018Nilam BolaDraft ePMA Specification for Comment.Re-ordered for distribution to nurses and therapists:-Mandy AndersonPhil BellNaomi DevelinChelsea ElcocksDan FisherRachel GibbonsKathy HankinsHelen IstifanSimon KerslakeClaire LeesAndy McKeeNaomi MorganAlex PatrickKaren RemmingtonPoppy TranterKerry WykesDraft1.329/01/2018Nilam BolaDraft ePMA Specification for Comment.Re-ordered for distribution to Pharmacists:-Jaswinder DhapAndy DownSiriosha GopalanShelley PalmerDraft1.429/01/2018Nilam BolaDraft ePMA Specification for Comment.Re-ordered for distribution to Matrons:-Jo RobertsPhil ShakeshaftJo WhitehouseDraft1.529/01/2018Nilam BolaDraft ePMA Specification for Comment.Re-ordered for distribution to IT, Support and Reporting:-David BrownKen HadleyMark GallagherDarren HulbertSam MundayRichard PammentDawn PattisonVanessa RobertsSteve SidwellTim WindsorDraft2.005/02/2018Nilam BolaDraft ePMA Specification for Comment.Returned comments added:-Vanessa RobertsKirsty ProtheroughDraft2.107/02/2018Nilam BolaDraft ePMA Specification for Comment.Returned comments added:-Martin CurticeClaire LeesTara Walker(NB Dawn Pattison returned email with no comments)Draft2.208/02/2018Nilam BolaDraft ePMA Specification for Comment.Returned comments added:-Tim WindsorKen HadleyDraft2.309/02/2018Nilam BolaDraft ePMA Specification for Comment.Returned comments added:-Darren HulbertKathy HankinsJas DhapShelley PalmerDraft2.412/02/2018Nilam BolaDraft ePMA Specification for Comment.Returned comments added:-Shelley Palmer (continued)Mark GallagherAndrew DownIan DouglasPoppy TranterRichard Pamment(NB Simon Challand, Karen Remmington, Jo Whitehouse and Jo Roberts returned email with no comments)Draft3.020/02/2018Nilam BolaDraft ePMA Specification for Comment.Review of comments by John Morrison, Katie Balu and Nilam BolaDraft3.123/01/2018Katie BaluReview of comments by John Morrison, Katie BaluDraft3.226/02/2018Nilam BolaDraft ePMA Specification for Comment.Amendments to document made by Nilam BolaDraft3.328/02/2018Nilam BolaDraft ePMA Specification for Comment.Amendments to document made by Nilam Bola to reports sectionDraft4.028/02/2018Nilam BolaDraft ePMA Specification.Renamed document and re-formatted in preparation for sendingIntroductionBusiness ContextTrust Infrastructure and StandardsFunctional RequirementsDrug Allergies and InteractionsNo.Drug Allergies and Interactions Specification ItemA&I-1The 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-2The solution MUST allow for the update and discontinuation of allergies and it MUST be mandatory to record reasons.A&I-3Using 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-4It 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-5The 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-6The 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-7The 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-8The 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-9The 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-10The 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-11The 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-12The solution MUST be able to support the “Yellow Card” scheme and send messages or notifications to the MHRA.A&I-13The 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-14The 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-15Prior 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-16The allergy information added to the solution MUST update other systems.AlertsNo.Alerts Specification ItemA-1The 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-2Where 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-3The solution MUST prompt the end user where they try to prescribe a drug that was previously prescribed or discontinued.A-4The solution MUST prompt the end user if they try to prescribe the same drug twice, including when present in compound drugs.A-5The solution MUST display if a service user is pregnant or breast feeding each time a new medicine is prescribed.A-6Medications which have NICE or other guidelines attached to them SHOULD prompt or initiate activities (e.g. booking an ECG).A-7The 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-8The solution SHOULD provide the ability to suspend a medication and provide an alert where received results indicate cessation of that medication.A-9The solution MUST be able to record and support a drug incident/error process.A-10The solution will prompt prescribers when specific information MUST be supplied to the service user.A-11The 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-12The 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-13The 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-14The 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-15It MUST be possible to define alerts that cannot be overridden. A-16End users MUST be able to see all alerts, historical and active, generated for a service user.A-17Alerts 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-18Alerts 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-19Display 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-20Where 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).Controlled DrugsNo.Controlled Drugs Specification ItemCD-1The solution MUST meet or conform to all legal requirements regarding controlled drugs.CD-2The 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-3The solution MUST have an electronic CD register facility for both wards/departments and pharmacy.CD-4The 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-5The 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-6The 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-7The 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-8The 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-9The 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-10When 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-11The solution MUST support advanced electronic signatures to enable OPD and CD processes (when legislation available).Clinical Decision SupportNo.Clinical Decision Support Specification ItemCDS-1The solution MUST provide decision support which is appropriate and applicable to UK practice.CDS-2The 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-3Decision support MUST include alerts on:-? Allergies, adverse reactions, intolerances? Contraindications? Dose range checking? Therapeutic duplication ? Drug interactions.CDS-4The solution MUST provide decision support, including checking against service user demographics, diagnoses, dose calculation and other results captured in the solution. CDS-5The 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-6The 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-7The 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-8Decision support SHOULD include checks on pathology results.CDS-9Decision 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-10When 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-11The 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-12The 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-13The 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-14Information 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-15The solution MUST support the implementation of action plans to respond to NPSA safety notices and recommendations.CDS-16The 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-17The 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-18The solution SHOULD offer guidance on dosage adjustment for service users on different types of dialysis.CDS-19The 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-20The 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-21For 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-22The 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-23More 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-24It 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-25Decision support SHOULD be re-run whenever new information is added to a service user’s record.CDS-26The solution MUST identify who is responsible for maintaining the information that drives the decision support and its continual update.DepotNo.Depot Specification ItemD-1The solution MUST allow regular, periodic prescribing (e.g. depot injections) when required/PRN, once only, and continuous intravenous prescribing.D-2Support for depot prescribing MUST allow the end user to define tolerances for administration.D-3The 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-4The 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).Clozapine No.Clozapine Specification ItemC-1The 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-2The solution SHOULD provide a prompt to prescribers when a clozapine assay is due.Prescribe Medication No.Prescribe Medication Specification ItemPM-1The solution MUST provide the ability to prescribe.PM-2The solution MUST be able to record end user and date/time stamp for prescription related events.PM-3The solution MUST ensure that prescribers are easily identifiable for every prescription written.PM-4The 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-5The 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-6The 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-7The solution MUST be able to select a drug by BNF/BNFC therapeutic class.PM-8The 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-9The solution MUST provide links to general prescribing information at the point of prescribing such as .uk.PM-10The solution MUST be able to display service user specific dosing recommendations based on age and weight.PM-11The 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-12The 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-13The solution MUST be able to prescribe fractional amounts of medication (e.g. 1/2 tablet).PM-14The solution MUST be able to prescribe pharmacy compounded preparations.PM-15The 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-16The 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-17The 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-18The solution MUST provide the ability to add comments to a prescription (e.g. why medication is being prescribed, amended or stopped).PM-19The 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-20The solution MUST allow authorised individuals to sign and countersign medication orders.PM-21The 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-22The solution MUST be able to display the service user’s prescription history for the current admission.PM-23The solution MUST be able to maintain a coded list of medications.PM-24The 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-25The solution MUST be able to accommodate the prescribing of variable doses (e.g. every 72hrs/ weekly/ alternate day prescribing/ warfarin dosing).PM-26The solution MUST be able to electronically verify a service user's prescription eligibility.PM-27The solution MUST enable repeat prescription management.PM-28The solution MUST allow an end user to reorder a prescription without re-entering previous data (e.g. administration schedule, quantity).PM-29The solution MUST be able to send prescriptions electronically, including the ability to document the source of prescription order.PM-30The solution MUST be able to identify any medication dispensed documenting the lot number and the expiration date.PM-31The solution MUST provide secure prescription printing and the ability to electronically fax prescriptions.PM-32The solution MUST be able to re-print, prompting the end user to record the reason why.PM-33The 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-34The solution MUST enable printing and reprinting of medication onto all FP10s with each prescription adhering to the appropriate legal requirements per page.PM-35The 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-36The solution MUST provide the ability, for an individual medication request, to define a validity time period.PM-37The 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-38The 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-39The solution MUST provide options for prescribers to decide whether to treat adolescents with paediatric or adult doses/regimens and record the reason why.PM-40The solution MUST allow the prescription of dressings and allow the specification of the size and quantity required.PM-41The solution MUST provide the ability to prescribe and administer blood products.PM-42The 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-43The solution MUST allow for the prescribing of nebulised medicines including any diluents.PM-44The 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-45The 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-46The solution MUST support formulary management, including a local formulary and NICE guidance, based upon a standard drugs directory reflecting the BNF/BNFC.PM-47The solution MUST support the ability to define a limited formulary for particular roles supported by Role-Based Access Control (e.g. dental formulary).PM-48The solution MUST support prescribing by medical and non-medical healthcare professionals as defined within the RBAC or by Patient Group Direction.PM-49The solution MUST allow prescribing by the relevant units of issue.PM-50It 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-51The 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-52The 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-53The solution MUST allow the set-up and use of commonly used medication regimes. These SHOULD be managed locally.PM-54The solution MUST allow the set-up of groups of commonly prescribed drugs.PM-55The solution’s prescribing functionality MUST interact with the Mental Health Act functionality to support Consent to Treatment.PM-56The solution MUST support prescribing of emergency medication (stat). Medication prescribed this way SHOULD be highlighted until administered.PM-57The 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-58The 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-59The 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-60The solution MUST allow the prescribing of medication to reflect the timing of medication administration.PM-61The solution MUST allow end users to search and view medication by BNF/BNFC section.PM-62The solution SHOULD enable BNF/BNFC maximum dose warnings during prescribing.PM-63The 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-64The solution MUST be DM+D and SNOMED compliant.PM-65The solution SHOULD provide the ability to prescribe and administer medications when the service user is temporarily away from their admitted location.PM-66The solution MUST allow prescribing for service users who are registered with a PMI number only (e.g. an unconscious service user).PM-67The 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-68The solution MUST allow the service user's preference for formulation and route of medications to be recorded.PM-69The solution MUST support community prescribing and administration (inc. different supply routes and publication of administration charts).PM-70The 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-71Outpatient 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-72The 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-73The 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-74The 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-75After 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-76On medication selection, the drug name, form, route and strength MUST stay on screen throughout the prescribing and medication administration.PM-77The solution MUST support the prescribing and administration of medications administered by syringe drivers and pumps.PM-78The 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-79The 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-80The 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-81The solution MUST allow the prescribing of dietetic products and thickeners.PM-82The 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-83The solution MUST allow the specific scheduling for particular drugs (e.g. Methotrexate, transdermal CD patches)PM-84The 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-85The 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-86The solution MUST support the prescription of dose loading.PM-87The 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-88The solution MUST mandate the duration of treatment for some drugs (e.g. antibiotics).PM-89The solution MUST allow prescribing of antibiotic prophylaxis.PM-90The solution MUST allow the prescribing of the final infusion as a single entity.PM-91The 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-92The 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-93It 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-94It 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-95It 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-96The solution MUST support restrictions (by end user, user type, specialty and/or location) on who can prescribe cytotoxics in non-oncology specialties.PM-97The solution MUST highlight during prescribing, administration and the pharmacy clinical check those medicines selected that are unavailable on NHS prescriptions.PM-98The solution MUST warn end users of therapeutic duplication but allow this under certain circumstances, with a reason for prescribing despite warning.PM-99Suppliers 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-100The solution MUST avoid the unnecessary use of decimal points (e.g. 3?mg not 3.0?mg/ 500mcg not 0.5mg).Pharmacy CommunicationNo.Pharmacy Communication Specification ItemPC-1The 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-2The 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-3The solution MUST allow the pharmacist to send messages to the prescriber for further checks or requests for information on prescribed medications.PC-4The solution MUST provide the pharmacist with the ability to modify medication request details within certain parameters without the need for prescriber verification.PC-5The solution MUST provide the ability to add pharmacist comments to the medication request during verification.PC-6The solution MUST provide the ability to specify service user appropriate directions that could appear on a medication label.PC-7The 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-8The solution MUST be able to integrate with stock control and other systems as required to minimise duplicate data entry.PC-9The solution SHOULD support the electronic transmission of prescriptions to a selected community pharmacy.PC-11Once the prescription is completed it SHOULD be available electronically at a pharmacy/dispensary used by the Trust PC-12The 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-13The solution MUST allow the ability to prepopulate some medications/medication classes with relevant pharmacist instructed comments.PC-14The 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-15It 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-16The solution MUST allow/permit a pharmacist to add, amend/edit and cancel prescriptions with reasons recorded, without replacing the original prescriber details.PC-17The 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-18The clinically checked status of an order MUST be consistent and visible throughout all areas of the solution (i.e. prescribing, administration etc.). PC-19The 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-20It MUST be possible to highlight which medicines need specific counselling. This SHOULD be locally configurable.PC-21The 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.Medicines Management No.Medicines Management Specification ItemMM-1Supply 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-2The 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-3It 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 homeMM-4It 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-5The 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-6The 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-7The 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-8The solution MUST distinguish between a NHS service user and a private service user for both prescribing and costing purposes.MM-9The 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-10The solution MUST be able to allow the end user to enter, modify, deactivate, “delete”, update, display, copy and print medication lists.MM-11The 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-12The 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-13The solution MUST allow the medication record to be produced in a printable format. This will include medication history, current medication and administration record.MM-14The 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-15The solution MUST allow authorised end users to exclude a medication from the current medication list and document the reason for such action.MM-16The solution SHOULD be able to notify locally determined healthcare providers that a service user’s prescribed medication might be running out.MM-17The solution MUST allow the local administrator to input, modify, inactivate, “delete”, update, display, copy, and print medication information in any medication formulary list.MM-18The solution MUST allow the local administrator to input, modify, inactivate, “delete”, update, display, copy, and print medication formulary rules and guidelines.MM-19The 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-20The solution MUST allow the local administrator to input, modify, inactivate, “delete”, update, display, copy, and print locally defined prescription templates.MM-21The solution MUST provide the designation of a medication item as a service user’s own medication.MM-22The solution MUST enable the management of suspended medication. MM-23The solution MUST enable medication history to be recorded, or imported, where the solution does not maintain the service user's prescription.MM-24The 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-25The solution MUST be able to record that a service user has no medication history.MM-26The solution MUST be able to record illicit drugs use/frequency, smoking quantity/ frequency and alcohol consumption quantity/frequency.MM-27The solution MUST be able to record nebulised medications and home oxygen together with the dose/concentration and device.MM-28When 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.Medicine AdministrationNo.Medicine Administration Specification ItemMA-1The 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-2The 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-3The default time stamp for administration of medicines MUST be the actual time of administration rather than the time the medication was due.MA-4Via 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-4bIt 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-5It 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-6The 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-7It MUST be possible to administer a medicine earlier than the prescribed/scheduled time but within a specified timeframe that is locally configurable.MA-9The 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-10The solution MUST provide the ability to record batch numbers for administered medications using administration comments.MA-11In 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-12The 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-13The solution MUST provide ability to record "who" (e.g. carer/parent/guardian, nurse etc.) is/would be responsible for administering medication.MA-14The 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-15The 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-16In 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-17The solution MUST be able to amend administration settings automatically when an inpatient is on leave.MA-18After 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-19The 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-20A 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-21End 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-22The solution MUST provide a view of all overdue medication on a given ward.MA-23The 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-24The solution SHOULD allow closed loop medicines administration, supporting the goals for Scan4Safety for safety.MA-25After 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-26The solution MUST allow for early and late administration of depot medicines within certain predefined limits that are locally configurable.MA-27The solution MUST allow the recording of 'Nil by mouth' and which medications can be administered whilst the service user is nil by mouth. MA-28The solution SHOULD not allow administration of suspended medications and SHOULD allow the end user to edit the duration of the suspension. MA-29The 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-30It 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-31The 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-32When 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-33There 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-34The 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-35Prior 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-36The 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-37It MUST be possible, through local configuration, to administer some medicines without restrictions in frequency.MA-38The 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-39It 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-40It 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-41The 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-42The solution MUST display a clear, legible and complete overview of all historic and outstanding administration events for the current admission. MA-43The 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-44The solution SHOULD enable authorised end users to initiate the replenishment of drugs from within the medicine administration function if ward stocks are low.MA-45The 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.Simple Medicines Policy and Patient Group Directions (PGDs)No.Simple Medicines Policy and Patient Group Directions (PGDs)SMP-1The 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-2The 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-3The solution MUST provide access to the details of the actual PGD via links to local documentation.SMP-4Where 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.Discharge PrescribingNo.Discharge Prescribing Specification ItemDP-1The 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-2The 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-3The 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-4The solution MUST support the transfer of a discharge prescription and/or medication information electronically to other locations (e.g. other hospitals).DP-5Discharge 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-6The 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-7Discharge prescriptions SHOULD include an indication of when they are required by the service user (i.e. what is the estimated time of discharge).DP-8Antimicrobials on the discharge section MUST have an indication as to why it has been commenced and a stop date unless clinically inappropriate.DP-9It 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-10It 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-11It MUST be possible to generate discharge prescriptions from inpatient medicine lists, including safeguards for review of PRN, parenteral and rectal medicines.DP-12If 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-13If 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-14The 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-15The 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-16Discharge 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-17If 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-18If 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-19The 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-20Clinical 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-21The 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-22The 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-23The 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-24If 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-25The 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-26The 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-27The solution should be able to include any locally developed discharge initiatives.ReportsNo.Reports Specification itemR-1The reporting functionality, MUST NOT impact on the performance or the normal working of the solution.R-2The 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-3The 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-4All 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-5The solution MUST be sufficiently flexible to enable statutory reporting for both clinical and management requirements.R-6The solution MUST be sufficiently flexible to enable locally determined reports for both clinical and management requirements (e.g. to support NICE requirements).R-7Alongside 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-8Specifically, 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-9The 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-10The 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-11The 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-12The 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-13The solution MUST have a comprehensive Database Schema, showing all relationships/links between key data tables and be provided to the Trust.R-14The solution MUST have a comprehensive Data Dictionary to support the schema and be provided to the Trust.R-15The solution MUST use an industry standard, ODBC compliant database, with the supplier able to determine what system they use.R-16The 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-17The solution MUST allow reports to be printed on any industry standard printer, without any requirement for specialised printing hardware or software.R-18The 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-19The 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-20The 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-21The solution MUST allow any print job to be aborted without adversely affecting the solution.R-22The 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-23The solution SHOULD produce a report detailing each end user’s access rights.TechnicalNo.Technical Specification ItemT-1The 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-2The 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-3It MUST be possible to uniquely identify all end users of the solution.T-4The 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-5The solution MUST be compatible with the use of a Single Sign On solution (e.g. Imprivata).T-6The supplier MUST state their approach for temporary logins for agency/bank staff.T-7The solution MUST NOT display an entered password on a screen.T-8The solution MUST only allow the local administrator or a designated ‘super user’ to set up new end users on the solution. T-9All 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-10All security functions MUST be controllable by a local administrator.T-11The solution MUST be able to support local configuration of user roles (e.g. the expanding ward technician job role).T-12The solution MUST automatically logout an end user after a locally defined period of inactivity without affecting the solution’s integrity.T-13The 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-14The solution's response times to an end user’s action SHOULD be less than 3 seconds.T-15The 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-16It 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-17The 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-18The 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-19The solution MUST operate with UK terminology and characters.T-20The solution MUST use a 24 hour clock and standardised date and time formats throughout the solution.T-21The solution MUST automatically cater for clock changes (summer and winter) and this MUST be reflected in the audit trail.T-22The 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-23The solution SHOULD allow default recording of the current date to "today" and time to "now" for activities which are normally performed on-line. T-24It 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-25The 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 periodT-26Alongside 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-27The 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-28The 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-29The 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-30The supplier MUST outline their expectations of the Trust’s responsibilities for training.T-31The supplier MUST provide appropriate training resources and documentation for local administrators, the Trust’s IT Training team and for end users.T-32The 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-33The supplier MUST state the process for backups and data restoration taking into consideration the Trust’s current backup policy.T-34The 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-35The 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-36The 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-37The 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-38The 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-39The 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-40A 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-41The bi-directional interface MUST be able to handle the Patient Master Index (PMI), Admission, Discharge and Transfer (ADT) and allergy data. T-42The solution MUST be able to push medications and allergy information to other Trust systems (e.g. CareNotes, Electronic Discharge Summary).T-43The 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-44The 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-45The 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-46The 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-47The 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-48The solution SHOULD have the ability to create medication orders that can be sent to pharmacy for label production and assembly.T-49The solution MUST use and maintain a comprehensive drug reference file using the national drug dictionary (dm+d) descriptions and identifiers. For all drugs, the file MUST include:-? International Non-Proprietary Name (rINN) or approved BP name or clinical trial name? Dose, form, strength, pack size(s) (where applicable)? SNOMED clinical terms? EAN or approved auto-ID code? Proprietary names? Legal class and therapeutic classification (including BNF/BNFC classification, with the ability to add free text)? Cross reference to the Drug Tariff, where applicable? Technical attributes of the drug to allow ‘manufacture’ where appropriate e.g. diluents allowed? Local formulary status and exceptions? Blueteq status? Payment by Results high cost exclusions status.T-50All manual and automatic updates, amendments and creations in the Drug Reference File MUST be verified/approved on implementation by the Trust before being accessible/visible to the end user.T-51It MUST be possible to add specific notes to individual medicines within the database that will be displayed during prescribing. This function MUST be limited to local administrators only.T-52The Drug Reference File SHOULD indicate the appropriate service user information leaflets that are to be used according to local requirements. It SHOULD be possible to access/produce service user information leaflets in different languages and formats (e.g. Braille).T-53The solution MUST allow electronic loading of reference data files (e.g. specialties, wards, consultants) as an alternative to manual data input where such data is either published as a national resource or is already available within the Trust.T-54The solution MUST have a mechanism for validating incoming data (e.g. new codes, new reference tables, etc.) prior to it being loaded into the solution. The local administrator MUST be provided with sufficient information to enable investigations of failed record loads to be completed. Failed files MUST be reprocessed if required.T-55The solution MUST allow for the use of national coding standards, where they exist, but SHOULD also allow locally defined codes to be used, where appropriate. However, any outputs from the solution MUST comply with national coding standards as documented in the NHS Data Dictionary, NHS Information Standards Notices (ISNs – previously DSCNs), and other similar official publications. Such compliance MUST be achieved at no extra cost beyond the supplier’s annual software support charge and accommodate for when national coding systems change.T-56The solution MUST provide extensive (locally configurable) on-line Help functions, both in context and indexed.T-57The solution SHOULD provide the ability to display and select from sorted lists of reference codes and associated meanings where operational data entry is required.T-58The solution SHOULD provide system management facilities for viewing and printing reference data files and SHOULD allow flexibility in selection of data, sequence and format.T-59The solution MUST be consistent across all modules and functions with regard to screen design, the use of keyboard stokes and mouse clicks.T-60The solution SHOULD enable access to functions via navigation through a structured menu but SHOULD also allow a fast-path route to commonly used functions. T-61The solution MUST ensure that all data items are subject to appropriate and comprehensive validation for format, length, range and cross-data item compatibility, and MUST always display a meaningful error message on the screen in the event of invalid data input. T-62The solution MUST ensure that clinically important data items are subject to further validation checks for range and MUST display a meaningful warning message where data entered is valid, but outside of a normal range.T-63The solution MUST allow local flexibility in the definition of whether the recording of data items is mandatory or optional, where this does not compromise overall data integrity.T-64The supplier MUST describe how their solution handles record merging and deletion of erroneous records. This MUST include details of how appropriately trained end users can merge records and details of either manual or automatic procedures to reconcile conflicting data items.T-65The supplier MUST support the Trust in developing robust business continuity and disaster recovery plans, and the testing and subsequent revision of such plans as necessary.T-66Solution documentation MUST be provided to the Trust to enable effective operation of the solution. The documentation MUST cover all products supplied, including those originating from third parties, and include:-·?Solution design and architecture·?Technical description and specification of hardware·?Hardware operation and maintenance·?Operating System software operation and maintenance·?Solution software operation·?Solution screens, data dictionary or data structures/items· Support and training manuals ·?Codes, reports, and functions for local tailoring and parameterisation·?Technical specification and operating instructions for interfaces to other systems.T-67Subsequent releases of software MUST be accompanied by timely changes to the relevant documentation, including release notes which MUST be supplied to the Trust in advance of any change taking place.T-68The supplier MUST explain their approach and planning for migration to the Trust’s live environment.T-69The supplier MUST support the Trust throughout the go-live and rollout period and outline how this will be delivered.T-70The supplier MUST explain their approach to system acceptance and verification.T-71The supplier MUST use the Trust’s change control and release management process to commissioning of the solution and to any upgrades that are implemented during the length of the maintenance agreements.T-72The supplier MUST explain their UK-based service organisation and processes (e.g. how many support staff are available? Where are they located? How many can reasonably be expected to cover Worcestershire? What is the approach towards conducting periodic SLA reviews? What is the process for requesting solution changes? What escalation routes exist? How are issues managed and resolved?).T-73The supplier MUST outline what technical support & maintenance arrangements are available (e.g. gold, silver, bronze levels) to include SLAs and categorisation of SLAs and timescales.T-74The supplier MUST explain what replacement equipment and/or software will be provided on loan in the event of being unable to rectify fault within a specified time period.T-75The supplier MUST explain their approach to mitigating any disruption to the service in the event of any software upgrades.T-76The supplier MUST explain the approach to and management of software upgrades which would normally be expected to be part of the contract and state whether these are at no extra charge or incur any additional costs.T-77The supplier MUST explain the approach to and management of minor/major enhancements and state whether these are at no extra charge or incur any additional costs.T-78The supplier MUST detail their future development plans for the solution's functionality and, if possible, provide their current developmental roadmap.T-79The supplier MUST maintain their data extract functionality in line with solution developments.T-80The supplier MUST explain their approach to extension of contract(s) at the end of the contract period. T-81The supplier MUST provide a detailed exit strategy and plan and full costing where applicable.T-82The supplier MUST undertake to support the Trust to migrate from their proposed solution to an alternative solution at the end of the contract(s) (i.e. in the event that the new contract(s) are not renewed with the same supplier) by providing data extract(s) to a predefined and documented specification. T-83The supplier MUST state where the solution will be hosted (e.g. on Trust premises or not).T-84The supplier MUST state their disaster recovery plan and their warm stand-by’s.AbbreviationsePMAElectronic prescribing and medicines administrationPGDPatient Group DirectionWHACWorcestershire Health and Care TrustMHRA Medicines and Healthcare products Regulatory AgencyIVIntravenousIM IntramuscularNICENational Institute for Health and Care ExcellenceECGElectrocardiogramBNFBritish National FormularyBNFCBritish National Formulary for ChildrenNPSANational Patient Safety AgencyeMAR Electronic medicines administration recordPRNAs required medicationMEDUSAInjectable Medicines GuideMHAMental Health ActCDControlled DrugOPDOutpatient DepartmentGPGeneral PracticeEDSElectronic Discharge SummaryHCPHealthcare PractitionerTTO‘To Take out’ discharge medicationsBMIBody Mass IndexINRInternational Normalised RatioFP10Outpatient PrescriptionHOCFHome Oxygen Consent FormA&EAccident and EmergencyRBACRole-Based Access ControlVTEVenous ThromboembolismDM+DDictionary of Medicines and DevicesSNOMEDSystemised nomenclature of medicinePMIPatient Master IndexBSABody surface areaAPIApplication programming interfaceHRG Healthcare Resource GroupODBCOpen database connectivity ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download