Electrifying prescriptions

teaser

Andrew Heed
Lead Clinical Informatics 
Pharmacist
The Newcastle Upon Tyne
Hospitals NHS Foundation Trust

Layla Campbell
Medicines Management Pharmacy Technician

The Trust wanted a single integrated electronic patient management interface. The Trust had well established IT healthcare systems and while these existing systems worked well, some were nearing the end of their ‘shelf-life’. It was also increasingly difficult to develop and maintain interfaces between multiple systems. Cerner Millennium® was chosen, as it comprises multiple healthcare applications all co-ordinated through a common front end. This facilitates greater sharing of information across departments and in the long term will improve standardisation of processes.

The Cerner system was implemented in Conjunction with The University of Pittsburgh Medical Centre (UPMC) an American Healthcare company with a proven record of implementing Cerner in the US. UPMC provided guidance on technical and build elements of implementation as well as infrastructure needs. Trust staff had responsibility for building the system and for ensuring that system design and processes were appropriate for the Trust.

Building the electronic prescribing system
As with many electronic prescribing (EP) systems, the Cerner system is based on an ascending hierarchy of linked databases. These layers are:

• Core Codes – Routes of administration, drug forms and dose frequencies
• Order Entry Formats (OEF) – These define the information required at the point of prescribing and determine what end users and patients see
• The drug catalogue – A comprehensive core catalogue was supplied by Multum® this required local configuration to formulary
• Order Sentences – Common dosing instructions to guide prescribers
• Order Sets – Groups of commonly co-prescribed drugs.

It is very easy when building EP systems to become bogged down in defining each layer. To limit this we based our design on Connecting for Health and DM+D guidelines. These guidelines seem daunting on first viewing but they are based on sound principles and are extremely comprehensive, they were invaluable to our build. We also convened weekly project team and monthly project board meetings to enable quick review of design principles. These multi-disciplinary groups allowed us to test and modify several build designs very quickly.

Design challenges
At its core prescribing is communication. To succeed, EP systems must be clear and unambiguous to a range of users. This requires a common language and defining this is a considerable challenge. Table 1 illustrates an example of how different groups define or use language to achieve the same endpoint, that is ‘Patient receives Mesalazine’. It could be argued that example 4 is required to remove any ambiguity. Any attempt to implement this level of prescribing detail into secondary care, however, is likely to spark rebellion amongst clinical users.  It is essential therefore to select an appropriate balance and compromise on clarity for clarity’s sake.

The DM+D can be used as a tool in this. Their naming convention standardises on drug nomenclature and defines ascending levels of detail. Their basic level is called a ìVirtual Therapeutic Moietyî (VTM.) This is the drug name. As more detail is added a new level is created, for example, add the form and you create a ìVirtual Medicinal Productî (VMP.) This builds through several levels to an AMPP, which is akin to Example 4.

Our drug catalogue is predominantly VTM, with VMP for specialised oral or non-oral forms. We also have a limited range of AMPs where functionality requires this, for example, controlled drugs. The Cerner system contains several types of decision support. They can be divided into two categories: proactive and reactive. Proactive decision support includes order sentences and order sets, which guide prescribing.

Our experience of order sentences is that a maximum of 10 sentences be created per drug; any more than this and the risk of miss-selection increases. This limit necessitates a selection criteria and some creativity of design as well as on-going review based on usage.

Order sets work best when developed with clinical users. Our most successful order sets were post-op analgesia sets developed with a team of anaesthetists; our least successful were developed with a Trust steering group, who while enthusiastic were not end users.

Reactive decision support takes the form of alerts and warnings to ‘incorrect’ prescribing. Cerner supports interaction checking, allergy checking, therapeutic duplication checking and dose range checking. We have de-activated all but allergy checking, which has the advantage of being substance and patient specific. This decision was based on concerns over alert fatigue, in which end users potentially become blasÈ about alerts and dismiss without reading. Analysis of the alert matrix indicates that over 7,000 alerts per day would post were decision support fully active. This to some degree supports the decision.

We do however wish to use alerts and will be developing over time an alert configuration that responds to a Trust hit list of high-risk interactions.

Training and engagement
In conjunction with the EP team, the Trust’s IT trainers developed and delivered training to users. A variety of training methods and materials were used including: classroom sessions, printed handouts, on-line tutorials, a training version of Cerner and interactive quizzes. While training was not officially mandatory, certain groups were targeted, for example, ward sisters and managers. We also delivered in-depth training to create in-house experts ‘Super Users’ who had a mandate to cascade training within their department. This approach resulted in a high level of training for nursing staff. We were less successful with medical staff for which the percentage trained was very low. The EP team largely focussed on engagement sessions. While these were at times volatile and often seemed repeatedly directed at the same faces, they were valuable two-way forums. The sessions allowed our team to determine ward processes, to plan change management and to mobilise departments into readiness for going live. They were also crucial in pre-empting going live challenges and reducing the number of surprises on the floor.

Ultimately, the key training methodology was hands-on experience when going live. This was particularly the case for medical staff many of whom had not accessed training materials. It is clear in hindsight that those wards fully engaged at go-live had fewer problems than those who were disinterested.

Hardware
Considerable expense and work can be wasted if users do not have hardware that is fit for purpose. It is essential therefore to choose kit based on defined criteria and have a strategy for on-going maintenance and replacement.

Our Trust opted for Dell Laptops inside Ergotron mobile carts. This combination met our criteria for mobility, infection control, robustness and practicality. They are however bulky and problematic in areas in which space is at a premium. Our deployment ratio per ward was four mobile devices plus five desktops. Subsequent audit work indicates that this is the minimum required for a standard 30 bed ward with three to four drug rounds per day. We tested hand-held devices. These were popular with some users but were limited by difficulties with screen resolution and significant textual input. They also carry a security risk and are not currently cheaper than standard laptops devices.

Long-term the Trust is keen to explore thin clients as they have benefits in terms of maintenance costs. In recent trials we experienced problems with excessive log-in times. Future investment would require either reconfiguration of log-in processes or devices with improved processing power.

Rollout
Our initial plan for rollout was a big bang, simultaneously going live across three main sites. This is the methodology used by UPMC at US sites and was used for going live with our Cerner Patient Administration System. This methodology carries a huge work force and training burden, which was not possible within our resources. We opted therefore for an aggressive staggered rollout. We went live with an initial ward over one week then two to three wards per week. In total 27 wards went live over four months including a break for Christmas.
A rapid rollout schedule has the advantage of limiting transfer issues between different prescribing mediums. However, the rapid rollout does limit an ongoing presence at ward level. To counter this we arranged follow-up meetings with directorates to review any issues. Of particular value was a pharmacy hit squad that visited wards to reiterate the processes. This was a valuable learning exercise for both pharmacy and the wards and they were able to resolve and discuss long-standing supply as well as EP issues.

Lessons learned
Our rollout was extremely aggressive and presented many challenges necessitating quick thinking and occasional changes of direction. The following are lessons learned or points to reflect upon:

This article was originally printed in HITE Vol 3 No 4