ePMA electronic Prescribing and Medicines Administration ePMA Testing June 2014

Presentation outline About Stockport Our ePMA Journey System build and associated QA processes System testing and processes/documentation Lessons learnt

About Stockport Stepping Hill Hospital based in Stockport 736 beds Look after a population of over 396,000 in Stockport & High Peak Over 5,600 staff

Our ePMA journey

System build - Approach Where to start? We split into 5 areas -Formularies -Order sentences (QuickLists) -Order sets (Protocols) -Rules/intelligence -General configuration Focussed on initial areas of rollout and evolved during rollout -Top 200 drugs for first 2 wards and worked from there -Shared Trust/GMMMG formulary -Project team fed into a lot of the configuration decisions Ensure someone responsible for each area to help make decisions and for QA purposes -e.g. we have a Pharmacist for each BNF Chapter

System build – QA process QA process approved by Trust Prescribing Committee (Drug & Therapeutics) Involved lots of printouts, screenshots and persuasion Mainly Pharmacists, but Clinicians involved for Protocols Medchart Quicklist checking Data entry by: Date: Checked by: (sign) ___________ Date: ___/___/___ EACH PAGE NEEDS TO BE SIGNED Annotate comments and feed back to Sarah

System build – Going forward Don’t think you’re done on day 1 of go live Constant refinement and adjustment in initial months Have a process for requesting changes & document everything Don’t relax your standards from initial data build -Everything in test first, sign off, then live use Spend time getting ready for surgical areas -Our anaesthetists have really embraced protocols/order sets Now everyone can see the potential -Requests for development and fresh ideas

System testing – Our approach Real life scenarios with real life examples We have 20 example patients that we prescribe review and administer medications Complex patients covering lots of different medications Simulate ward environment, follow usual processes (3 days of administrations) Ensure each and every element of the system is tested, documentation is key Use different logins testing each user role Don’t forget to test user permissions

System testing - Documentation Testing log and issue log are essential Log each and every action that is completed We split into Careful consideration of headings e.g. Dual monitor workstation has been indispensable! -Configuration -Meds on admission -Prescribing -Administration -Pharmacy review & ordering -Clinical Review -Drug data -Rules -New features & fixes -Issues resolved since last version -Reporting -Support module (back up charts/system monitoring) -‘Other’

System testing – Recording issues Record each and every issue -No matter how big or small -Whether able to replicate or not -Document which user role you were logged in as -Keep issue log up to date, review daily during testing period -Clear screenshots and replication steps are best way of explaining issues -Where possible share issues and testing experience with other sites

System testing – At point of upgrades Once upgrades are complete a basic set of testing is required to release the system back to users Have a list of basic functions that need to be tested as part of this process The start of ours is shown here, it is 43 steps in total but covers all basic functions

System testing – Lessons learnt Ask supplier for details of known issues Study release notes and write testing script based on new features and fixes Screenshots are key Learn from other sites Real life charts with real life examples Don’t aim to do in one sitting Log everything Always test printouts, don’t just look at them onscreen

Thank you