NHS Purchasing and Supply Agency / Pharmacy Business Technology Group Part One

NHS Purchasing and Supply Agency / Pharmacy Business Technology Group Part one

Information pack Electronic interchange of drug contract data

Part one: E-Contract upload

November 2002, version 6.1

Electronic interchange of drug contract data between NHS Purchasing and Supply Agency (NHS PASA) and hospital pharmacy computer systems is the current major initiative of the Pharmacy Business Technology Group (PBTG). A facility to export an electronic drug contract file has been included on the cd-rom to facilitate this process.

PBTG have identified areas where purchasing groups and pharmacy system user-groups could provide input to support the implementation of this project and produced an information pack.

Contents

Links to external information sources are made throughout this document, to our secure extranet (known as the NHSnet), however this information pack is published in full on our website at www.pasa.nhs.uk/pharma/

Background

Part one: e-Contract upload Part two: Technical information pack: Standards for electronic interchange of drug contract data

Appendices

Appendix one - Example data from a PHAED file

Appendix two - See appendix for flow diagram illustrating the above process

Appendix three - Pharmacy Business Technology Group - Mission statement, terms of reference and contact details

Information pack Electronic interchange of drug contract data

Part one: E-Contract upload

This document is a companion to the technical information pack to provide background to support colleagues at purchasing groups and pharmacy system user groups. It describes a step-by-step process for uploading NHS Purchasing and Supply Agency (NHS PASA) medicines contracts into pharmacy purchasing systems by electronic means.

NHS PASA provides two standard electronic file formats PHAED and PHAEUS, defined in the technical information pack that can be used by pharmacy system providers to achieve this objective. The advantages of this development, such as reduced workload for contract maintenance and simplified, more accurate return of usage information are described in detail in the technical information pack which can be found by clicking here (NHSnet visitors) or via our website at www.pasa.nhs.uk/pharma/

Actions for Pharmacists:

 Pharmacists to enter into a dialogue with pharmacy system suppliers about development of a software interface that will import contract information directly into the pharmacy system using the PHAED file.

 Pharmacists to enter into a dialogue with pharmacy system suppliers to provide issues (usage) data back to NHS PASA in the PHAEUS file format.

 Pharmacists to schedule this improvement in functionality into pharmacy system development programs.

The introduction of NPC codes - which are national, generic, pack level codes will facilitate the introduction of the AMPP (Actual Medicinal Patient Pack) codes from the UKCPRS which enables supply chain enhancements at trusts such as batch traceability, improved internal supply chain management, audit trail and recall procedures. This will therefore deliver a level of supply chain improvement that are not essential aspects of the UKCPRS codification which is clinically focused and supports EPR.

Initial discussions have taken place between third party database companies e.g. First Data Bank and the file structure of the NPC has been seen to be compatible with existing dictionaries and may support implementation of UKCPRS and EPR developments.

This essential initiative fits well with the vision in the NHS Plan to modernise NHS procurement. A national code UKCPRS established by the NHS Information Authority will come on stream in 2003. The process described here is a first step to achieving the national vision, as it allows the NPC code to be used as a bridge to the national UKCPRS code.

The best solution is a process that eliminates the majority of workload at each stage and aims at achieving in the region of 80% of the matching process automatically, managing the processes by exception.

Professionally based decisions as opposed to logically based decisions mean that the process does not lend itself to full automation. This development is considered to be a staged process and is not envisaged as a completely automated process.

Time saving and reduction in workload is ultimately the largest benefit as the keying- in of information is substantially reduced.

1 Essentials

There are essential elements that need to have some facility in your local system to facilitate contract upload, so for example if the PASA supplier code is an essential then somewhere on your system a field needs to contain this reference, Most Pharmacy systems will not have this reference and therefore needs to have some sort of translation table (lookup) to convert current supplier codes into PASA supplier codes.

1.1 National Product Code NPC

The NPC (National Product Code) as defined by NHS PASA is a 6-digit reference 3 alpha and 3 numeric; it uniquely defines each product on the contract at the pack level.

Therefore your the pharmacy system you’re using must be able to view the NPC at pack level not solely at a higher product level like a group of packs for example Amoxycillin Capsules 250mg.

Local Pharmacy systems need a facility to map to this code in order to automate the majority of the contract upload process. Creating an extra field in local systems and then matching items to this code is an essential aspect of achieving contract upload. It is a one off exercise that only needs low-level maintenance after this for new products to be entered onto the system.

One useful piece of advice is that if a field is created on your system to contain the NPC code it is advantageous to have this field appear on screen, especially purchasing screens, to identify products without NPC's

1.2 Factoring facility

Pack size factoring is necessary to map purchased packs into units of issue packs used with in the hospital e.g. Oral contraceptive is purchased as 3x21 but can be issued as 1x21 to a patient this often leads to the pharmacy system being set up as packs of 21 for issuing purposes and therefore a factor of 3 needs to be applied to the issued pack when purchasing. Likewise invoicing information needs to be divided by a factor of 3 to successfully match invoices. Not all pharmacy systems use pack factoring and rely on other means however they still need to solve this problem in their own way if they are to achieve external trading electronically.

Therefore pack factoring is an essential feature of the contract upload process and is fundamental to sharing information with any third party. It should not be left to an external system such as EDI or WEB trading platform, it needs to be an integral part of your hospital pharmacy system.

1.3 National Supplier Code (NHS PASA) NSC

The NSC code is a national supplier code managed by NHS PASA. There are currently around 200-250 supplier codes. It is a three-alpha code often derived from the suppliers name but not always (i.e one cannot always tell who the supplier is from reading the code).

Changes to the supplier code can occur under the following circumstances: mergers; acquisitions and company name changes.

Where codes are updated as a consequence of these changes notification will be made by PASA via the website and also on the Pharmacy CD catalogue.

Most systems will need to map to this code, however some systems may be able to create a separate field called “PASA Supplier Code” and populate it, as a one off exercise. Other systems may be able to align existing supplier codes by simply amending there codes to ensure they match with PASA NSC codes.

1.4 Interface

There are four essential elements to creating an effective interface.

The first 3 essential elements are NPC, NSC and factoring. These are for contract uploads. Once these have been established, a fourth element comes into play for the collection of usage data.

This Fourth Element requires that the trust is able to apply the trust unit organizational code to the data (see Technical Information pack). Trust unit organisational codes are managed by the NHS Information Authority and can be obtained on the Internet from http://nww.nhsia.nhs.uk/ocs/ then clicking on ‘Downloads Index’. It is possible that this will be hard coded into the report, or set-up with user intervention to determine the code written in this field. The code used should be the Trust Unit organisational code and not the Trust organisational code.

This interface at its most basic level will import data into a holding area on the pharmacy system for manual or semi-automatic matching to product records on the © Crown copyright, 2002 Page 4 NHS Purchasing and Supply Agency / Pharmacy Business Technology Group Part one pharmacy system and at its most sophisticated form will interpret the PHAED data and apply suitable records onto the 'live' pharmacy system proper (see Technical Information Pack).

The level of sophistication of this interface is determined a) By the architecture of the system and b) The level of automation the users require.

1.4.1 Design of the Interface By designing the data upload process to take place away from live data, in a different part of your system, automation of the process can be dramatically improved and accuracy enhanced.

You can achieve the upload with live data but this reduces the automation as the process needs to occur line by line and not by exception, which can be achieved in the former process, you also increase the chances of introducing errors.

1.4.2 Exception based rules The entire purpose of this approach is to reduce workload uploading contract data. In order to achieve workload reductions the data must be 'processed by exception'. In other words this process uploads all data with robust reliability without manual interference and applies intellectual decision making only to those records that do not meet the basic rules of applying data.

1.4.3 Upload facility Uploading data from a flat comma separated variable (CSV) file produced by PHAED (37 fields) can be achieved by both PC based Pharmacy systems directly and by UNIX based systems using "FTP" (File transfer protocols).

If this data is uploaded into a separate area of the Pharmacy system it can be manipulated, matched, deleted, amended and finally posted. If it is however imported directly into the live data, your options are more restricted and all actions need to be carried out line by line.

1.4.4 Download facility Downloading data from your pharmacy system is required to produce a flat file of usage data, for this data to be meaningful, you will need to have carried out the upload of contract data to ensure factoring is in place, so reference is made to the same factor parameters. i.e. When producing the usage data file the factoring manipulation works in reverse.

1.4.5 The file structure of PHAED The Technical Information pack defines the rules for record handling in PHAED. PHAED displays contract changes as a sequential file, showing each change to a record as an 'event'. This means that the same NPC can appear consecutively on the file - be it for banded pricing, shared awards or future notifications of changes. In the latter case, the current record and future changes are displayed in sequence in the file.

Pharmacy systems must take account of the possibility of encountering consecutive NPC's on the PHAED file as part of the process of applying the data.

2 Processes

2.1 Maintaining NHS PASA supplier code (NSC)

Ensure the PASA supplier code (3 digit alpha code) is matched with your Pharmacy system so that contract changes can be applied to the correct supplier on your pharmacy system. Most Pharmacy systems will need to set up a translation process for this however some may be able to amend their supplier code to match the PASA code. Either way it must be possible to recall the supplier as described by the NSC on the PHAED data file.

2.2 Weeding out the items you are not interested in

When the contract data is uploaded into the Pharmacy system, interest should be shown in only those items that have no match. The ability to exclude / eliminate any of these items at this stage will reduce the list of items requiring action at a later date.

For example if you do not stock or use blood product items, they will not have an NPC code on your system and unlikely to even appear as an item on your drug file.

These need to be excluded from any further decisions.

If you are unsure, then always choose NOT to exclude and they will appear later for further clarification, during other parts of the contract matching process.

When each record on the contract import file is read in, the NPC on the record needs to be checked to see if it exists on your Pharmacy system.

If it does exist, the next record is read.

If it does not exist, details of the contract record need to be displayed on screen for the next process to handle, in-other-words you only need to view at this stage items on the contract, that do not have a matching NPC code.

2.2.1 Eliminate items that you do not want to match with This is a useful time saving feature to allow you to concentrate on items that will affect your system.

2.3 Creating NPC in your pharmacy system

For items on the contract without a matching NPC code on the Pharmacy system (this could be all products the first time you run contract upload) the user needs to be able to view on screen all of the description of the product with some information like supplier and route of distribution to help the user make a match to an item on the host pharmacy system.

There is a logical set of steps in helping to identify items for attaching an NPC code to:

 Searching for the correct drug name

The user is prompted to enter the first part of the drug name for the first drug found without a NPC code this drug or other packs of this drug.

All drug approved names that satisfy the search criteria are displayed. If the contract drug is not on the list, you need to move onto the next item, as you cannot make a match at this stage.

If the drug is on the list, select the appropriate name to move onto the next stage and search for all forms of the selected drug.

 Searching for the correct form

If the contract form is not on the list, no match with NPC is possible, and so move onto the next item. However if the correct form appears select this and move to see if the strength matches the contracted strength.

 Selecting correct strength.

If the correct strength does not appear then move onto the next item, this is because the system cannot match the item that is on the contract.

 Pack size

The user needs to be able to choose to remove the item from the contract update file or leave it on the file and make a note to set this item up as a new item on the Pharmacy system for later inclusion.

If the contract pack size is on the list, then the user can include the item on the contract update, as it is means that the item is on your Pharmacy system but has not had an NPC attached to it.

To facilitate this process attach (populate) the NPC field on your Pharmacy system with the contract NPC.

If the contract item is not on the list of packs then the user can decide, depending on what packs are on the Pharmacy system, whether the contract item is required.

See appendix for flow diagram illustrating the above process (NHSnet visitors please click on the link, alternatively see our website at www.pasa.nhs.uk/pharma)

2.4 Dealing with new items on the contract not on your system

The previous process allows you to match up new items on the contract to existing items on your pharmacy system. However you will reach the point whereby the item does not appear on your pharmacy system and you'll need to create it if you are going to purchase the item in the future.

In creating the item you need to gather all the relevant information from the contract. Essential elements are:

NPC code Purchase price per pack Supplier Code Any factoring issues resolved.

This is in order to create the product on your system to comply fully with the contract to ensure that a match will be made with the new item when the final upload is run. You do not want to create an item that will require any further intervention during upload.

2.5 Factoring

It is essential to have a screen view that allows you to see the NPC description including pack size & outer (MOP) and the local description including pack size, so that you can compare and contrast the same items from both information sources.

If a factor is entered, this needs to be re-confirmed as the correct relationship between the issuing pack and the new contract pack size, then the confirmation of price in the same way. The factor needs to remain on your system for future use.

2.5.1 Eliminate these items by creating a factor Once you have set up a factor you have resolved a relationship and have set up a way of displaying two views of the same item.

This is essential when ordering, but is also crucial when sending usage data so that the data sent is related to the contracted pack size.

2.6 Price comparisons

Price comparison between contract and current Purchase Price for the System main supplier.

Once all the items, which are not on the Pharmacy system, have been identified, you must do one of the following:

 Add them to the pharmacy system  Or remove them from the contract update list.

And then:  Align the pack sizes using factoring  Check the prices. Prices on contract are checked against the main supplier purchase price of the item on your system  The main supplier purchase price of other packs of the same drug, form and strength on your system, which currently have stock in at least one location. (In other words you use the item but maybe a different pack).

This process cannot happen unless the previous factoring process has occurred, so to ensure you are comparing like with like.

Contract inner pack size is checked against your system pack size x factor (the initial factor is blank, i.e. no factor)

 Contract inner pack size is checked against the supplier of your choice ‘outer pack size.

2.7 Pack changes

The contract maybe awarded for a pack size of a product, which is not currently stocked. This will require you to rationalise your stock and make a professional judgment to standardise to a particular pack.

A process needs to be created to accommodate this part of processing a contract, as a consequence of these pack changes the packs you are changing from need to be considered (see managing the effects of contract changes) in stock management terms.

2.7.1 Managing the effects of contract changes When you change your contract from say, a pack of 50 to a pack of 100 or a contract line is discontinued you need to suspend the ordering of the orginal 50's and ensure this stock is used up before the new contracted item becomes available. The contract reference needs to also either expire or be manually removed.

This is outside the scope of uploading a contract but is related to the process, because the change of contract has had an affect on the status of other products in your system. Proper care and attention needs to be paid to these consequences of contract change to guard against wastage and the danger of continuing to buy the original pack size as well as the new contracted line.

2.8: Brand selection

Once all the decisions have been made to accept or reject items from the contract list, the process of identifying the new main brand starts.

PHAED provides a brand name (field 37) if a brand name exists. As Pharmacists need to have the supplier name applied to all records for ordering purposes, a derived field needs to be created by the Pharmacy system when the Brand field is empty in PHAED.

To generate this 'derived brand' take the supplier code (field 7) map it to the supplier name held on the system and concatenate the supplier name with the product name into the Pharmacy system brand field, eg "Alpharma Ibuprofen". Applying the supplier name first ensures that the most important data can be seen where field length is an issue.

The new main brand may:

 Not change  Change to an existing one for that item  Change to an existing one for another instance of the same drug  Change to a new brand, which does not exist on the Pharmacy System.

The program needs to list all brands for the drug from your system, including brands for other instances of the same drug.

Your system then needs a way of adding this new brand name and associates it with the item.

2.9 Final process

The final process is dependent on the way in which the system has been designed.

If your system supplier has designed the process to take place in a separate area of your disk and the intention is to post the changes to the live part of the system, it is advisable to have a final print out stage to check before committing the final action, a single keystroke.

However if the system process occurs with the live data, there is no final posting and therefore increases the implications of human errors and also reduces the potential for automating most aspects of the processes

2.10 Post application check

This stage is verifying that what you expected to happen has actually occurred.

You may decide to take a random sample and double check manually or choose for the system to produce an audit report of all changes to the system.

3 Problems

3.1 How items are described on systems can cause problems

Eg Gelofusine and Haemacael (Colloidal Gelatin Infusion). Description sequence for new combination products Inners and outers Packs? Naming conventions Therapeutic substitution

Coding reduces these potential conflicts or problems

3.2 Pharmacy system file structure

Are individual packs defined to a pack level, or other parameters?

Codes are needed to identify products and pack sizes uniquely.

The process, once set-up, is labour saving for each contract period. It is no longer necessary to devote extensive resources for data manipulation. Weekend work.

3.4 Pharmacy system suppliers 'agendas'

EPR - this concept is part of the EPR vision

The 'Big Picture'

Planning blight?

Other initiatives

If we do this, we don’t do anything else

Conflicts & duplications of effort?

Spoonful of Sugar – automation

UKCPRS - coding

Step-by-step v's 'Blue Sky'

By introducing this development, the procurement process becomes more automated and electronified. This will help reduce the additional effort required to move pharmacy systems towards EPR level 3 and additional targets.

4 Opportunities and synergies

4.1 EPR

The Pharmacoeconomic aspects of EPR cannot be achieved without accurate reliable real time data, which can be achieved using ECU (Electronic Contract Upload).

4.2 Accuracy labour and money saving

See Information Pack for more details.

4.3 Electronic data v's paper

Allows data manipulation, sharing, analysis & deductions, benchmarking, process monitoring & improvement, generation of historical trends, SWOT analysis.

One of the benefits of creating a relationship between NPC code and your products is that you are not just making a relationships with this code but your are creating relationships with all the information connected to this code, so for example if your system is able to hold BNF code or EAN number, this link can be used to integrate all this additional (validated) data into your system together with the contract information.

For more information contact a member of the Pharmacy Business Technology Group (details available at the PASA website).

5 Glossary

NPC: National Product Code - Developed and Maintained by PASA, a lookup facility is available on http://www.pasa.doh.gov.uk/pharmacy/npcsearch/default.asp

NHS PASA: Purchasing and Supply Agency. An Executive Agency of the Department of Health with responsibility for procurement.

UKCPRS: UK Clinical Reference Source managed by The NHS Information Authority to enable electronic coding of medicines in the clinical setting. More information can be found at the NHS IA UKCPRS website at www.nhsia.nhs.uk/ukcprs.

AMPP: Part of the codification for medicines providing the structure for the UKCPRS. Actual Medicinal Product Pack – for example Atenolol Tablets 50mg, pack of 28 made by Cox. More information about the coding structure can be found at http://www.ppa.org.uk/systems/pcdd_intro.htm.

NSC: National Supplier Code - Developed and maintained by PASA. It uniquely defines all suppliers that trade with the NHS.

Trust Unit organisational code: A trust unit identifier maintained by the NHS information authority and can be obtained on the internet http://nww.nhsia.nhs.uk/ocs/ then click downloads index. A Five character code alpha numeric with the first three characters defining the parent trust (trust organisational code)

Trust organisational code: A trust identifier maintained by the NHS information authority and can be obtained on the internet http://nww.nhsia.nhs.uk/ocs/ then click downloads index. A Three character alpha numeric code uniquely identifying the trust

CSV File: Comma separated variable file, used in importing data from a simple flat file.

FTP: File Transfer Protocol a standard set to allow data to flow from one system to another.

UNIX: Operating platform, most pharmacy legacy systems run on Unix platforms.

PHAED: (Pharmacy Electronic Data) the name given by NHS PASA to the file standard for contract data upload.

PHATE: (Pharmacy Tender and Evaluation System) the Contracting software of NHS PASA.

EDI: Electronic data interchange

MOP: Minimum order pack

PACK: The integral lowest tradable unit up from the dose unit.

EPR: Electronic Patient Record.

PBTG: Pharmacy Business Technology Group.

EAN: European Article Number.

INNER: Typically a pack or may be a wrapped pack multiple within an outer.

OUTER: A shipping package containing ‘inners’ (packs or pack multiples).

ECU: Electronic Contract Upload

SWOT: Strengths, weaknesses, opportunities & threats.

BNF: British National Formulary

PCCD: Primary Care Drug Dictionary

Appendices

Appendix one

Example data from a PHAED file

(NHSnet visitors please click on the link, alternatively see our website at www.pasa.nhs.uk/pharma)

Appendix two See appendix for flow diagram illustrating the above process

(NHSnet visitors please click on the link, alternatively see our website at www.pasa.nhs.uk/pharma)

Appendix three Pharmacy Business Technology Group - Mission statement, terms of reference and contact details

Appendix three

The Pharmacy Business Technology Group

Mission statement June 2006

To act as a strategic focus for secondary care projects in medicines management business processes. To ensure that the NHS benefits from the appropriate and cost-effective use of modern technology

Terms of reference

 The Pharmacy Business Technology Group is a sub-group of the NPSG (the National Pharmaceutical Supplies Group) and reports at each meeting  To be active in horizon scanning for pharma related business concepts  To support changes and developments in pharmacy business processes within the NHS  To support Connecting for Health in their development of electronic systems within the healthcare sector  To interface with other stakeholder groups, building on the initiatives within the NHS  To design and drive projects that better utilise information technology for disseminating and sharing information on hospital medicine procurement for the benefit of the NHS  To influence the development of end-user systems including prescribing, contracting, procurement and finance systems

Key development areas

PBR (Payment by Results) Pharmaceutical coding Robotics and automation Machine readable codes NHS Pharmacy Messaging Service Homecare Tendering and contracting Financial interfacing

PBTG membership December 2007

Roger Miles (Chairman) Nickie O’Neill ASCribe Category Manager - General Pharmaceuticals Pharmacy Department, NHS Purchasing and Supply Agency Royal Bolton Hospital Tel: 0118 980 8830 Minerva Road Nickie.O’[email protected] Farnsworth Bolton Paul O’Brien BL4 0JR EDS Senior Principal Pharmacist (Operational Services) Tel: 01204 390968 Hull and East Yorkshire Hospitals [email protected] Tel: 01482 62(3275) PauI.O'[email protected] Judie Finesilver (Secretary) eBusiness Manager Pharmaceuticals Andrew Davies NHS Purchasing & Supply Agency EDS Premier House Head of Pharmacy Services 60 Caversham Road [email protected] Reading RG1 7EB [email protected] uk Grenville Weston Mob: 07785 573 914 ASCribe Principal Pharmacist Diane Slater Informatics and Modernisation iSoft East Sussex Hospitals NHS Trust Principal Pharmacist, Project Manager, Electronic Tel 01323 413801 Prescribing Team [email protected] East Cheshire NHS Trust

Tel 01625 661519 Anthony Sinclair [email protected] EDS

Pharmacy Department Phil Aubrey Birmingham Children's Hospital JAC Tel: 0121 333 9780 NW London NHS Trust [email protected] Tel: 0208 869 2209 [email protected] George Gannon PIMS Andi Swain Pharmacy Business & Distribution Centre ASCribe UCL Hospital Trust Purchasing & Supply Manager Tel: 0207 380 9730 Pharmacy Department [email protected] Addenbrookes NHS Trust Tel 01223 274335 Graham Cripps [email protected] Bedford Pharmacy Purchasing and Distribution Operational Manager David Dalton Oxford Radcliffe Hospitals NHS Trust EDS Tel: 01865 225975 Pharmacy Department [email protected] Royal Devon & Exeter Hospital Tel 01392 402469 Margaret Dolan [email protected] Pharmaceutical Adviser Pharmacologistics Scottish Healthcare Supplies Danny Palmer Tel: 0131 275 6163 JAC [email protected] Senior Pharmacy Technician Pharmacy IT Luton & Dunstable Hospital NHS Trust Michael McBeth Tel. 01582 497118 ASCribe [email protected] Procurement and Logistics Pharmacist Queens Medical Centre Nottingham [email protected]