Primary Care IM & T Programme - NHS Wales 2DRx Prescriptions... · Tim Tett ( per pro Primary ... will allow the validation of XML data encoded in barcodes printed on prescriptions

Primary Care

IM & T Programme

Community Pharmacy IM & T

“2DRx” Project

Wales 2D Barcoded Prescriptions –

Functional Specification Requirements Release: v2 Final

Date: 31st October 2007

PRINCE 2

Joint author: Gary Jones

Owner: Primary Care IM & T Programme

Client: National Assembly for Wales

Document Number: 2DRX_FSS/L1

Welsh Assembly Government - Primary Care IM & T Programme Wales 2D Barcoded Prescriptions – Functional Specification Requirements

___________________________________________________________________________________

_____________________________________________________________________________________________ Programme: Primary Care IM & T Programme Date of Document: 31/10/07 Author: Gary Jones Version: 2.0 Status: Final (In Confidence)

Page: 2 of 32

Document Information Project Name: ‘2DRx’ Project – 2-Dimensional Barcoded Prescriptions

Prepared By: Gary Jones

Document Version: v2.0 Final

Title: IM & T Programme Manager, Community Pharmacy and Dental Contracts

Document Version Date:

31/10/07

Distribution List

From Date

Gary Jones

31/10/07

To Action * Date

MSS Design and Compliance (DAC) Group

Inform 31/10/07

Neil Jenkins (PSU) Inform 31/10/07 Tim Tett (per pro Primary Care IM & T Programme) Inform 31/10/07

Welsh Information Governance and Standards Board (WIGSB)

Inform 31/10/07

Pat Davis (EPES Project Manager) Inform 31/10/07

Ken Tweedie (HP) Inform 31/10/07

Colin French (HP) Inform 31/10/07

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

Version History

Version No.

Version Date

Revised By Description

2.0 Final 31/10/07 Gary Jones Review by MSS-Design & Compliance Group

1.2 Draft 16/10/07 Gary Jones Incorporating Pharmacy System requirements

1.1 Draft 09/10/07 Gary Jones Incorporating Wales Localisation document 2DRx_FSL1 (previously reviewed)

0.5 Draft 28/09/07 Neil Jenkins Review by Neil Jenkins

0.4 Draft 04/09/07 Tim Tett Review by Tim Tett

0.3 Draft 25/04/07 Gary Jones Authored by Gary Jones

0.2 Draft 20/02/07 Wing Lee Revised by Wing Lee (EPES project / HP) – joint requirements for the EPES project in NI and 2DRx Project in Wales; defining a common schema for both Projects (issued by NI as Epes v1.0)

0.1 Draft 24/01/07 Gary Jones ‘Control Trial’ 2D Barcode Specification (v1.0)


___________________________________________________________________________________


Page: 3 of 32

TABLE OF CONTENTS

PROPRIETARY NOTICE………………………………………….….4 DOCUMENT DEVELOPMENT……………………………………....4 DOCUMENT APPROVAL……………………………………….……5 1. INTRODUCTION………………………………………….……….6 1.1 Purpose of the Document……………………….……...6 1.2 History of Document Development…………….....…..6 1.3 Terms………………..……………….…….……………….6 1.4 Definitions…………..…………………………….………..6 1.5 Background and Strategic Context……….…………..7 2. XML SCHEMA SPECIFICATION……..……….………………..8 2.1 Purpose and Rules of XML Schema………………….8 2.2 Mandatory Fields…………………….…………….……..8 3. 2D BARCODE – IMPLEMENTATION PROFILE……..…….…9 3.1 Purpose and Rules of Schema Localisation……...…9 3.2 Mandatory Fields………………….………………….…..9 4. XML SCHEMA AND LOCALISATION TABLE……….…….…9 5. NON-STANDARD FIELDS……………………………………..12 5.1 Unique Prescription ID………………….……………..12 5.2 Repeat Prescriptions…………….…………………….12 5.3 DM + D………………...…………………………………….15 5.4 Form Types………………..………………………..…….15 6. PRINTING GUIDELINES……..………………………….……..15 7. 2D BARCODE……………………………………………………16 7.1 Barcode Type…………………..………………………..16 7.2 Configurable Parameters…….………………………..17 7.3 Barcode Size………………………...…………………..17 7.4 Barcode Position……………..…………………………18 8. PHARMACY DISPENSING PROCESS……………………….18 8.1 Requirements…………………………………………….18 8.2 Mandatory Processes…………………………………..19 8.3 Variations………………………………………………….20 APPENDIX A…………………………………………………………..23 APPENDIX B…………………………………………………………..25


___________________________________________________________________________________


Page: 4 of 32

PROPRIETARY NOTICE This documentation is the property of, and contains confidential information of, the Primary Care IM & T Programme (PCIP) of the Welsh Assembly Government.

1. Joint Functional Specification The Joint Functional Specification of this document is the product of a collaborative approach towards implementation of 2D barcoded prescriptions in both Northern Ireland and Wales and contains confidential information of Hewlett-Packard Company (HP) and its affiliates, as contractors of the Northern Ireland Department of Health, Social Services and Public Safety (DHSSPS) in relation to its ‘Electronic Prescribing and Eligibility System’ (EPES) Project.

2. Wales 2D Barcode Specification The Wales 2D Barcode Specification of this document is initially based upon a development Work Package between the PCIP and In Practice Systems (InPS) and also incorporates the core ETP message principles being captured in the English EPS solution.

3. Pharmacy Dispensing Process The section relating to Pharmacy development requirements is based on the

Programme’s prototype development Work Package, with some amendments, and also makes reference to the Northern Ireland EPES Project.

Possession and use of this documentation is authorised only pursuant to the requirements for System Supplier software programming changes required by the PCIP.

DOCUMENT DEVELOPMENT This document has been prepared based on our understanding of the dispensing process and the information contained on a Welsh prescription form (WP10SS). In addition to the collaboration with Northern Ireland, our understanding of the requirements for ETP in England – EPS – and the standards in place there have also been taken into account:

Name

Title Date

Wing Lee, Solution Architect (Hewlett–Packard)

per pro Northern Ireland EPES Project – Joint Specification 02/03/07

Gary Jones Primary Care IM & T Programme Manager (Community Pharmacy)

06/07/06


___________________________________________________________________________________


Page: 5 of 32

DOCUMENT APPROVAL Approval for issue of this document is required by PCIP, the MSS Design and Compliance Group (MSS-DAC) and Prescribing Services Unit (PSU) of Health Solutions Wales (HSW). Where mentioned, aspects relating to the Northern Ireland EPES Project development have already been agreed between the Northern Ireland Department for Health, Social Services and Public Safety and Hewlett-Packard Ltd relating to the development, implementation and maintenance of an electronic prescribing and eligibility system (dated 28 July 2006).

Name Version Date of Issue

Signature

Primary Care IM & T Programme

V2.0 Final

31/10/07

Health Solutions Wales (HSW) – Prescribing Services Unit (PSU)

V2.0 Final

31/10/07

Minimum Systems Specification (MSS) Design and Compliance (DAC) Group

V2.0 Final

31/10/07


___________________________________________________________________________________


Page: 6 of 32

1. INTRODUCTION

1.1 Purpose of the Document This Functional Specification document has been developed by the Primary Care IM & T Programme, in collaboration with the Programme’s commissioned IT development teams and Hewlett-Packard Development Company (specifically for the DHSSPS Electronic Prescribing & Eligibility System – “EPES” – project). This document aims to provide a design reference and rules set for the XML Schema, which will allow the validation of XML data encoded in barcodes printed on prescriptions in Wales, according to the localisation of the Schema. The document serves as a source for the solution design by GP and CP System Suppliers and as a basis for solution testing and acceptance.

1.2 History of Document Development Following meetings with the Northern Ireland Department of Health, Social Services and Public Safety (DHSSPS) in relation to its EPES Project, a near-common schema has been jointly agreed which will be used in both the EPES Project in Northern Ireland and the 2DRx Project in Wales (Community Pharmacy IM & T, Primary Care IM & T Programme). The Schema will ensure a consistent approach for the GP software vendors in the creation of the 2D barcoded Prescriptions for both Northern Ireland and Wales.

1.3 Terms Barcode: 2D barcode printed on a WP10 Welsh Prescription Form

Message: The encoded barcode content / data payload

Stationery definitions: Pharmacy system files containing script layout information

Clinician details box: White rectangular area at the bottom of a WP10 Prescription Form, used for recording Practice and Prescriber details.

1.4 Definitions The keywords MUST, MAY, and SHOULD are to be interpreted as described in RFC2119: MUST: This word, or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification.

SHOULD: This word, or the adjective "RECOMMENDED", means that there may exist valid

reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

MAY: This word, or the adjective "OPTIONAL", means that an item is truly optional. One implementer may choose to include the item because a particular implementation requires it or because the implementer feels that it enhances the implementation while another implementer may omit the same item. An implementation which does not include


___________________________________________________________________________________


Page: 7 of 32

a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).

The GP or Pharmacy system supplier wishing to comply with the requirements herein shall be referred to as the “system supplier” throughout this document. Where a requirement relates to a specific type of system the term “GP system supplier” or “Pharmacy system supplier” will be used.

1.5 Background and Strategic Context Community Pharmacy IM & T Developments

The Community Pharmacy Contract (2005) represents a major change in the range and choice of pharmacy services to patients in England and Wales. It was negotiated between the Pharmaceutical Services Negotiating Committee (PSNC) and the NHS Confederation, (acting on behalf of the Department of Health and the Welsh Assembly), with acceptance by Community Pharmacy Wales (CPW) on the proposed model for Wales being reached on 24

th

August 2004.

The new Contract allows initiatives such as repeat dispensing, electronic transfer of prescriptions and electronic transmission of prescriptions to be fully realised, whilst at the same time re-orientating services to meet patient expectations and maximise pharmacists’ potential to deploy their skills to better effect and drive up service quality.

‘2DRx’ Project Prototype Development The 2DRx Project was formerly known as the “interim ETP” Project for Wales. The Project’s new title better reflects the development approach that Wales has taken towards an appropriate ETP solution for the nation, namely 2-Dimensional (2D) Barcoded Prescriptions. In 2006, the PCIP commissioned a development work package into 2D Barcoded Prescriptions, which resulted in a successful Technical Proof of Concept (TPOC) ‘prototype’ using the basic ETP message principles from the EPS project in England. In the proposed Welsh 2DRx solution, the ETP message from a GP system is instead intercepted and captured within a 2D barcode, embedded onto the Welsh GP prescription form – the WP10SS or similar – rather than being transmitted to the “Spine”. This approach aims to capitalise from existing system development work already undertaken by system suppliers in the UK, as part of the accreditation process for EPS Release 1 and is therefore expected to result in the benefit of minimal system re-programming for Wales and Northern Ireland. Subsequently, in summer 2007, a User Proof of Concept (UPOC) ‘control trial’ was also successfully conducted and completed using the prototype barcode specification and the development of wider national implementation plans have now been authorised by the national Community Pharmacy IM & T Programme Board, following acceptance of Recommendations resulting from an Evaluation Report into the trial.


___________________________________________________________________________________


Page: 8 of 32

2. XML SCHEMA SPECIFICATION The following XML Schema considers the joint requirements of both Wales and Northern Ireland from their respective ETP Projects. It has captured as far as possible the same XML Schema being developed by both nations and strives to be a generic format. There are however small differences and these are explained below. This near-common XML Schema should be read in conjunction with the section relating to Welsh “schema localisation”; i.e. ‘2D Barcode Content – Implementation Profile’.

2.1 Purpose and Rules of XML Schema The purpose of this XML Schema is to define the structure and layout of the message contained within the 2D barcode and forms the basis of a specification for GP system suppliers. As the XML generated from this Schema will be encoded into a 2D barcode, it is important that the content is kept as small as possible, therefore the element and attribute names are deliberately kept short (one or two characters). The XML Schema contains some elements which are shown as ‘optional’ for Wales only; however, in order to maintain a near-common specification for Wales and Northern Ireland, they are left in for completeness. When data is read from a 2D barcode, it must will be validated against this Schema. If a field is tagged as ‘mandatory’ in the Schema, and it is not in the 2D barcode, then Schema validation will fail. Therefore, any fields that are not unremittingly contained within GP systems are being tagged as optional in the XML Schema for Wales.

Where other optional elements are specified in the XML Schema, they may or may not be required, depending on the local application of the Schema (NI or Wales).

2.2 Mandatory Fields The Joint XML Schema differs between both nations only by the following exceptions: 1. The inclusion for Wales of two additional mandatory fields:

• Age (element ‘pa’, attribute ‘o’)

• Number of Drugs on Prescription (element ‘sc’, attribute ‘dn’) This is because Wales needs to capture, as a minimum, all the visible text information currently shown on a Welsh Prescription form. 2. The requirement for NHS number to be mandatory for Wales (but not Northern Ireland):

• NHS number (element ‘pa’, attribute ‘h’) At the XML Schema level, if an encoded barcode does not conform to the Schema, the Schema validation will fail and a barcode will not be produced. Therefore, only those fields that must definitely be captured are marked as mandatory. Example If the patient NHS number fails to be captured into a 2D Barcode, the barcode itself will fail to be produced on the prescription, because the XML Schema states that NHS Number at the XML Schema level is mandatory (i.e. “Schema Mandatory = Yes”).


___________________________________________________________________________________


Page: 9 of 32

3. 2D BARCODE – IMPLEMENTATION PROFILE

3.1 Purpose and Rules of Schema Localisation The “schema localisation” for Wales and Northern Ireland applies at a higher level than the XML Schema and should be used in the generation of the XML. This section is relevant for Wales only and determines the differences between both nation’s 2D barcode content specifications, as well as providing an exact content specification for what is required by Wales. The precise 2D Barcode content for Wales is specified in the table shown, but in general it seeks to capture from the GP software systems, as a minimum, all the visible printed text on the WP10, plus additional items. It is therefore assumed that where visible information text is shown on the prescription form, it is equally held as a data field within the GP system.

3.2 Mandatory Fields At this “schema localisation” level, all fields marked as mandatory (“Wales Mandatory = Yes”) must always be included if present and available in the GP system. Example If a required dm + d code for a particular drug is not captured into a 2D Barcode, the barcode will still be produced because the XML Schema states that dm + d codes at the XML Schema level are optional (i.e. “Schema Mandatory = No”).

4. XML SCHEMA AND LOCALISATION TABLE In table 1 below, all Schema / Localisation fields are common and agreed by both nations, except where a field is in yellow, as this is a variation for Wales (either as an additional or amended item, or in terms of having a different mandatory status). In general terms, the “Wales Mandatory = Yes” fields must be captured within a 2D barcode from a Welsh GP system and the corresponding “Schema Mandatory = x” fields will determine whether or not a barcode is produced.

4.1 Prescription Element

Element Description Attributes Description Type Schema

Mandatory Wales Mandatory

Id Prescription id Text (20)

Yes Yes Sc Prescription information

ft Prescription Form Type depends on the type of Prescriber at the GP Practice: (WALES) 1. GP – form type should be WP10SS 2. GP (controlled drugs) – form type should be WP10MDASS 3. Practice Nurse – form type should be WP10PN 4. Community Nurse – form type should be WP10CN

Text (*)

No Yes


___________________________________________________________________________________


Page: 10 of 32

5. Supplementary Prescriber – form type should be WP10SPSS 6. Independent Prescriber – form type should be WP10IPSS (Northern Ireland) HS21 HS21D HS21N HS21X PV1

t Date prescription produced in CCYYMMDD format

Date (8)

Yes Yes

r Repeat info (e.g. “1 of 4”) – link to Repeat Master ID

Text (*)

No No

rm Repeat Master Script ID – Identifier Code for Master Script

Text (*)

No No

dn (New for Wales)

Number of Drugs on Prescription Integer (1)

No Yes

4.2 Patient Element



l Last name Text (*) Yes Yes

m Middle name(s) Text (*) No Yes

f First name Text (*) Yes Yes

s Title Text (*) No Yes

h Health care number / NHS number – new style

Text (10)

Yes Yes

b Date of birth produced in CCYYMMDD format

Date (8)

Yes Yes

x Patient’s gender coded as follows: 0 – Not Known 1 – Male 2 – Female 9 – Not specified

Integer (1)

No Yes

o (New for Wales)

Age Integers (*)

No Yes

a Includes 5 lines of address (comma delimited)

Text (*) Yes Yes

pa Patient

pc Post code without spaces Text (*) Yes Yes

4.3 Prescriber Element



i Prescriber id Text (*) Yes Yes

d Prescriber name Text (*) Yes Yes

n Practice name Text (*) Yes Yes

pb Prescriber information (Signing Prescriber) pi Practice id Text (*) Yes Yes


___________________________________________________________________________________


Page: 11 of 32

a Includes 5 lines of address (comma delimited)

Text (*) Yes Yes

pc Post code without spaces Text (*) Yes Yes

4.4 Registered GP and Responsible GP Elements



i Doctor id Text (*) Yes No

d Doctor name Text (*) Yes No

n Practice name Text (*) No No

pi Practice id Text (*) No No

a 5 x address lines, comma-delimited Text (*) No No

gp Patient’s Registered GP, if different from Prescriber pc Post code without spaces Text (*) No No

i Doctor id Text (*) Yes No

d Doctor name Text (*) Yes No

n Practice name Text (*) No No

pi Practice id Text (*) No No

a 5 x address lines, comma-delimited Text (*) No No

rc Prescriber’s Responsible GP

pc Post code without spaces Text (*) No No

The Registered GP and Responsible GP elements have been identified for possible future Welsh requirements and as such should be included in the Joint Schema as optional (i.e. not mandatory) for Wales. If at some stage they are captured, only the attributes “I” and “d” will be mandatory in the schema.

4.5 Drug Item Element



d Original drug description; e.g. “Aspirin 50mg Tablets”

Text (*) Yes Yes

q Original drug quantity; e.g. “32 Tablets”

Text (*) No Yes

sq Quantity when mapped to SNOMED coded UOM unit, when available

Decimal (8)

No No

do Dosage, as shown; e.g. “TAKE ONCE BEFORE MEALS”

Text (*) No Yes

dm DM&D code Text (18)

No Yes

dd Drug items

u Unit, or SNOMED coded UOM unit, when available

Text (18)

No No

Table 1 – Field Names and Tags

Notes: 1. Repeat Master ID / Slave information (rm, r) must be captured, wherever applicable (see

section 5.2 below); 2. These items will be delimited with a new line symbol. Any existing new-lines in the

payload will be escaped with a space. This method has been proposed within early development of a prototype of the solution, due to its simplicity;

3. The first and last characters in the message will be delimiters (i.e. new line symbols);


___________________________________________________________________________________


Page: 12 of 32

4. With the exception of the Drug Item, where optional items are not present, a blank item will be added. E.g. if only two address lines are available, then three blank lines will be included;

5. Where possible, the format is compatible with existing HL7 standards; 6. There will be a limit of 4 drug items per single 2D barcoded prescription form. Where

more than 4 drug items are prescribed, a new 2D barcoded prescription(s) will be produced containing the surplus drug items and prescription data.

5. NON-STANDARD FIELDS 5.1 Unique Prescription ID A Unique Prescription Identification (UPI) field must be generated by the print process and is not part of the standard prescription data. In addition to the standard (printed) prescription data identified in the previous section, a Unique Prescription Identifier of 21 characters must be generated for each prescription form produced and added to the information contained in the barcode. Therefore, in order to uniquely identify prescription forms, a UPI must be generated based on the following elements: 1. Prescriber’s code / cipher (assume 6 digits, or add preceding zero(s) if less than 6 digits) 2. Date and time of printing (including milliseconds) – dd/mm/yy + hh/mm/ss/msms 3. Random Digit (1-9, excluding zero) This protocol differs from the format advised by the Northern Ireland EPES project, where the random check digit at the end of the 18 digit UPI – i.e. a 19-digit total UPI – is instead replaced by two millisecond digits plus a random check digit for Wales – i.e. a 21-digit total UPI. 1. An example could be, for Northern Ireland, a 19-digit UPI of:

831167 + 220507 + 155803 + [‘1’ = random digit] (8311672205071558031)

2. But, for Wales, the 21-digit UPI could be:

831167 + 220507 + 155803 + [‘27’ = milliseconds] + [‘6’ = random digit] (831167220507155803276)

5.2 Repeat Prescriptions This section applies to all GP systems enabled for producing Authorising Prescriptions (RA) and accompanying Batch Prescriptions (RD), regardless of whether this enablement has yet been activated for Wales, either locally or nationally.

5.2.1 Master Script (RA)

For all eligible systems and in appropriate circumstances, a 21 character Repeat Master Script (RA) Unique Prescription ID must be generated and captured within the 2D Barcode.


___________________________________________________________________________________


Page: 13 of 32

In such scenarios, the first 18 digits would be the same as the UPI of an ordinary barcoded script, except for the final 2 digits plus random digit, which would change. Therefore, the final 2 x ‘ms’ digits must change to reflect: 1. The maximum number of Slave Scripts (01-99) 2. Default zero final digit (0)

For example, if 9 Slave Scripts (RDs) are to be produced with a Master Script (RA), the two ‘ms’ digits must be replaced with [‘09’] and the final check digit must be [‘0’] . In this example, an UPI of 831167220507155803[090] would be created.

5.2.2 Slave Scripts (RD)

The Repeat Slave Script (RD) information must be linked to the RA information, both in terms of its UPI and also Repeat Information text (e.g. “1 of 9”). Therefore, using the example above, four Batch Prescriptions would be individually barcoded to include the following data: 1. Repeat (slave) # 1

UPI: 831167220507155803[091] Repeat Information text: “1 of 9”

2. Repeat (slave) # 2






In these examples, ‘09’ represents the maximum number of slaves scripts produced and the final check digit is the series number of the individual RD (Batch) script; i.e. 1, 2,...8, 9.

5.2.3 Exceptions In the unlikely event that more than 9 Repeat Prescriptions (RDs) are required for any single Master Prescription (RA), the following rules shall be observed:

Master Script (RA) The Master Prescription’s UPI can accommodate a maximum of 61 Slave Scripts, using the system of numeric random digits, CAPITAL-CASE alpha random digits and lower-case alpha random digits. For example, 831167220507155803[610]


___________________________________________________________________________________


Page: 14 of 32

Slave Script (RD) Using the system of numeric random digits, CAPITAL-CASE alpha random digits and lower-case alpha random digits, the following shall be observed: - For 1-9, the supplier shall use digits 1,2,3,4,5,6,7,8 and 9 - For 10-35, the supplier shall use CAPITAL-CASE alpha characters ‘A’ to ‘Z’, where

‘A’=10, ‘B’=11, ‘C’=12 ..... ‘Y’=34 and ‘Z’=35 - For 36-61, the supplier shall use lower-case alpha characters ‘a’ to ‘z’, where ‘a’=36,

‘b’=37, ‘c’=38 ... ‘y’=60 and ‘z’=61 Using the above example of 61 repeat prescriptions to a single Master Script , the Slave UPIs would be within the range of: 1. Repeat (slave) # 1





UPI: 831167220507155803[61A] Repeat Information text: “10 of 61”


UPI: 831167220507155803[61G] Repeat Information text: “16 of 61”


UPI: 831167220507155803[61c] Repeat Information text: “38 of 61”


UPI: 831167220507155803[61s] Repeat Information text: “54 of 61”

In these examples, ‘61’ represents the maximum number of slaves scripts produced and the final check digit is the series number of the individual RD (Batch) script; i.e. 1, 2,...60, 61. The particular information relating to UPIs will be confirmed by the Programme separately within 2 weeks.

5.2.4 Positioning of Repeat Character Identifiers Below is an illustration of where the ‘RA’ or ‘RD’ should be placed on the new 2D Barcoded Prescription, together with specification instructions:


___________________________________________________________________________________


Page: 15 of 32

• Font should be Arial [bold] 10pt

• Text shall be printed in capitals

• The 2 character initiative identifier (RA or RD) must be centred horizontally across the column (defined by the right hand edge of the white personalisation box) and positioned vertically within 8mm of the top of the box (defined by the horizontal line above) in which it appears.

Fig 1 – Example prescription form, showing position and dimensions of ‘RD’ or ‘RA’

5.3 DM + D The dm + d code of all prescribed drug items must also be captured within the 2D barcode, when present and available

1, and encoded as appropriate by GP clinical systems.

5.4 Form Types Specific Form Types (e.g. WP10SS, WP10PN, WP10MDASS etc) must be captured by the Prescriber’s specific user profile in the GP system, or the type of drug being prescribed (e.g. a controlled drug) and embedded as appropriate within the 2D barcode – i.e. attribute / tag = “ft”. It is therefore assumed that the corresponding prescription form is correctly loaded into the GP printer in anticipation of these identifiers.

6. PRINTING GUIDELINES GP system suppliers must ensure adherence to existing WP10 overprinting specifications, as dictated by Welsh Assembly and Prescribing Services Unit guidelines. In the event of any ambiguity, please refer to the appropriate authority.

The 2D barcode must be printed on individual Prescription Forms, specific to the type of Prescriber or the category of drug (e.g. Practice Nurse WP10PN, or GP Controlled Drugs WP10MDASS). Suppliers must adhere to existing BNF guidelines for definitive rules and refer to PSU for further clarification, where necessary.

______ 1 Regardless of the availability of an individual dm + d code in the GP system, it should also be capturing and

encoding the drug information as a text data stream within the barcode, ready for decoding by the pharmacy system. Therefore, dm + d would be the primary drug identification data, where present and available and drug text data would be the secondary source of drug identification


___________________________________________________________________________________


Page: 16 of 32

Fig 2 – Data source from Welsh sample prescription form

7. 2D BARCODE

7.1 Barcode Type The 2D barcode required by the Northern Ireland EPES project is the Data Matrix standard and is the same standard that was utilised in the Welsh 2DRx prototype development and control trial. Datamatrix is covered today by an ISO standard, ISO/IEC16022 and is in the public domain

2,

which means it can be used free of any licensing or royalties. Data Matrix is a 2D barcode standard that is approved for use by GS1 UK – the UK branch of an independent global standards body, dedicated to the design and implementation of global standards for barcodes, RFID tags and electronic communications. Data Matrix is the only "2D Matrix" symbol specified for use by GS1 and is becoming increasingly the symbol of choice for many in healthcare; already being used widely in the pharmaceutical, retail and supply chains sectors. Data Matrix is a two-dimensional matrix barcode consisting of black and white square modules arranged in either a square or rectangular pattern, which has usual data capacity up to 2 kilobytes. Error correction codes are added to increase symbol strength; i.e. even if they are partially damaged, they can still be read.

________ 2 Since the time of its selection, its public domain status is being challenged by an Intellectual Property company, but

this is being strongly defended in a US District Court. In any case, the patent will expire in November 2007 and therefore the legal challenge will become redundant


___________________________________________________________________________________


Page: 17 of 32

A Data Matrix symbol can store up to 2,335 alphanumeric characters and in tests, produced a reliable barcode for reading using both hand scanners and software recognition. However, in order to ensure success with scanning, there is an upper limit which must not be exceeded on any single 2D barcoded prescription form. The Data Matrix barcodes provides control over the overall size of the barcode by controlling the minimum dimension of the squares i.e. the “pitch” or “X-dimension” of the barcode. By reducing the pitch, the size of the barcode is reduced. The Primary Care IM & T Programme recommends that GP system suppliers investigate appropriate and GS1-compliant 2D barcode standards for the 2DRx specification, which are capable of meeting the requirements previously stated herein. In addition, GP system suppliers must investigate appropriate software for the generation of their chosen barcode standard, as part of the overall development requirement.

7.2 Configurable Parameters There are a number of configurable parameters defined within the Welsh stationery definition. These are based on Welsh Assembly prototype trials and early development work: Security Level: This denotes the level of error correction in the barcode with a range

of 0 to 23. The default figure should be determined by GP system suppliers, but it is recommended at the highest value possible without compromising other defined parameters;

Max Characters: The maximum number of characters that the barcode can accept

without overly degrading the readability. The default figure should be determined by GP system suppliers, but it is recommended at a

value of 650 characters, based on success rates using different 2D

scanning devices in the live trial and laboratory tests. If the pre-determined maximum number of characters is exceeded, then the number of drug items on a single script must be decreased until an acceptable barcode can be produced. In the unlikely event that a single drug contains too much information, the barcode will not be printed at all;

Max Drugs per Script: The maximum number of drugs printed on a single prescription will be

four (4). Where there are more than 4 drug items required for a patient, additional barcoded prescriptions should also be produced as appropriate, with their own unique ID;

Barcode Generation: 2D barcodes should be generated using appropriate 2D barcode

generation software, as determined by GP system suppliers.

7.3 Barcode Size The barcode size must be no larger than 25mm square in order to fit in with the parameters of the prescription’s available space (see below). When the barcode is configured, the width of the narrowest bar (the barcode “pitch”) must be set initially to 0.3mm. Should the size of the resulting barcode be greater than 25mm, then the pitch must be decreased by 0.01mm at a time until the barcode is less than 25mm across.


___________________________________________________________________________________


Page: 18 of 32

7.4 Barcode Position Fig 3 (below) shows a sample prescription, and the required position of the 2D barcode. All other data must be printed in exactly the same position as is currently printed, apart from the data that shares the same box on the WP10.

Fig 3 – Example prescription form, showing position and dimensions of 2D barcode

8. PHARMACY DISPENSING PROCESS This section describes the Pharmacy decoding requirements in more detail and takes as its base the previously specified 2D barcode content and XML validation Schema. Pharmacy system suppliers should examine the previous sections regarding exact content specification for Wales. The 2DRx-enabled Pharmacy Dispensing process must not be discernibly different from the existing non-barcoded process, starting with a patient entering the pharmacy with a prescription form and leaving with a labelled bag containing their individual medication items. Current screens and work flows must not be affected adversely by the introduction of 2DRx, within the dispensing environment. The Pharmacy system supplier will be responsible for: 1. Ensuring that the enhanced functionality described in this document conforms to the

functional standards of the existing Pharmacy system; 2. Producing a technical design specification document for the development of the

enhanced functionality described in this document; 3. Developing the enhanced functionality, following the Programme’s authorisation to

proceed.

8.1 Requirements The Programme recognises that how the Pharmacy system suppliers chooses to implement the new 2DRx changes, in terms of their existing processes and screens, is done entirely at

Max 25mm

Max 25mm


___________________________________________________________________________________


Page: 19 of 32

their own discretion, so that the impact of these changes is minimal on the users of the system. This however must be understood in the context of attaining full compliance with the 2DRx specifications advised. Therefore, in order to make the Pharmacy Software system compliant with 2DRx requirements, it will need to be enhanced to execute the following steps: 1. Scan a 2D barcoded prescription; 2. Decode the 2D barcode contents; 3. Search and match a patient’s record, extracted from the 2D barcode against that stored in

the existing PMR, or create a new patient record; 4. Create a PMR episode record from the barcoded data (i.e. from the GP system) for the

identified (or new) patient; 5. Attempt to match the prescribed drug details contained within the 2D barcode (i.e. dm + d

codes, if included) with the existing drug database stored in the system – mapping process;

6. Import the dm + d drug code (or full text of drug(s) description from 2D barcode) into the

patient’s PMR record, together with other 2D barcode-captured data from the GP system; 7. Print drug label(s) for drug(s) imported and retained in the PMR, as normal; 8. Print bag label for the entire dispensing transaction, as normal.

For a fuller description of the Pharmacy Dispensing process, please refer to Appendix A.

8.2 Mandatory Processes As a consequence of the technical and user experiences from its control trial into 2DRx, the evaluation exercise revealed that certain implementations must be undertaken by Pharmacy system suppliers in the development of enhanced 2DRx functionality and these are described in this section.

8.2.1 Elimination of Transcription Errors One of the fundamental benefits of 2DRx – as any other ETP system – is the capture of matched data from GP systems, relating to a patient and their medication. GP clinical data has been subject, over recent years, to initiatives that have driven up data quality and the introduction of 2DRx will allow pharmacy PMRs to benefit from an exact copy of this data as their fundamental record. Added to this is the fact that GP data is likely to become the primary source of clinical data for populating an emerging Welsh Individual Health Record (IHR), plus further developments with pharmacy systems relating to transmission of dispensed medication data, mean that community pharmacies can contribute to the complete patient record from a position of uniformity within the primary care sector. Elimination of transcription errors is largely seen as the primary benefit of an effective ETP system and can only be brought about by the automatic import of GP prescribed data, without manual intervention; i.e. without human input. DM + D In the control trial, it emerged that the practice of importing the 2D barcode data completely within the PMR was only partly done by Pharmacists, as there was an option available – as part of the system prototype development – to use the barcode for patient identification only,


___________________________________________________________________________________


Page: 20 of 32

followed by a manual process of selecting a patient’s drug items through their ‘repeat medication’ tab from the existing PMR. Whilst this had no discernible difference on the process of scanning barcoded prescriptions, it did mean that the full benefit of capturing the dm + d drug code of each item was being missed by some Pharmacists and a matched (prescribed) patient medication record was not being imported into the PMR. The Programme therefore instructs Pharmacy system suppliers that the automatic import of dm + d drug code, where contained in the barcode, must be undertaken by default within a PMR, which will therefore contribute to the elimination of transcription errors, where dm + d codes are both contained by the barcode and mapped within the PMR. Drug Quantity, Dosage and Directions It also emerged that the system development left certain blank fields for a Pharmacist to manually enter, relating to drug quantity, dosage and directions. User feedback about this additional requirement (i.e. previous non-barcoded scripts did not require this input where the pharmacist selected the repeat medication tab) was mixed; some believed that for clinical safety this was important whilst others believed that it was an un-necessary step, which slowed down the dispensing process significantly. However, as the full medication transaction contains not only the dm + d code of the drug but also its quantity, dosage and directions for use, the elimination of transcription errors can only be achieved when all components are automatically imported within the PMR. The Programme therefore advises that the automatic import of these inclusive fields – as captured from the GP system into the barcode – must be automatically imported into the patient’s dispensation record with an option for a Pharmacist to over-ride the individual fields, if necessary. The Programme points out that rigorous testing will be undertaken as part of the GP system compliance process for 2D barcoded data capture, to ensure that all data fields are captured accurately within the barcode, where present in the GP system. In addition, the final checks for clinical safety must always be undertaken by the Pharmacist between the prescription itself and the drug labels produced from the pharmacy system, whether created by manual keyboard entry or via automatic population from a 2D barcode.

8.3 Variations The 2DRx enhanced functionality will accommodate the dispensation of the majority of GP-instigated printed prescriptions, but the following is a list of expected variations or exceptions requiring attention in the development. Repeat Prescriptions In certain Local Health Board areas in Wales, Repeat Dispensing is enabled by GP system suppliers and a number of ‘slave’ scripts are produced in relation to a single ‘master’ script. Therefore, in these instances, a patient can select, ad hoc, a number of different pharmacies to dispense each slave script, or alternatively a single dispensary. In the majority of cases, however, ‘repeats’ are generated by the GP surgery and – either through a prescription collection service or through an existing relationship between a GP and local Pharmacy – dispensed as a ‘batch’ by the Pharmacy, ready for collection by patients or their agents.


___________________________________________________________________________________


Page: 21 of 32

In the 2DRx development, the Programme has specified that repeat prescriptions (RDs) will each be given a unique prescription identification (UPI) number, related to its ‘master’ (RA) script. Therefore, for the correct matching of prescribed and dispensed repeat prescriptions and high-level identification and analysis of prescribing and dispensing patterns, it is advisable that a patient should choose a single pharmacy to dispense each of their related ‘repeats’, so that the pharmacist can submit them all for payment. However, if a patient decides to choose multiple dispensaries, this will not preclude each dispensary from claiming reimbursement for their individual dispensed prescription, as each repeat prescription represents an individual entity for payment. Multiple Dispensed Prescriptions The system must support the multiple dispensing of drugs; i.e. when there is more than a single drug item on a prescription. Dispensation of each drug item will follow the steps described in the main process; however, the prescription will not be completely dispensed until the last of the multiple drug items has been made. Emergency Supplies Where prescription records have been created in advance of receipt of a prescription (for example, emergency supplies taken via telephone or verbal instruction), the usual process must remain unaffected; i.e. a Pharmacist should still be able to enter a subsequently presented paper prescription (whether 2D-barcoded or not) and associate it with the previously entered Dispensation transaction, using the appropriate entry method (see “Owings”). This should allow the Pharmacist to endorse the prescription as required, prior to submission of claims to the Welsh prescription payments unit. Owings If a Pharmacist cannot completely dispense a prescription medication item due to lack of stock, the patient has the option to retrieve his/her prescription from the Pharmacist and take it elsewhere for dispensing (and the Pharmacist must then ‘abort’ the dispensing process for that transaction). However, if a patient agrees, the out-of-stock drug item can be flagged as “owing” to the patient and the Pharmacist can request the patient to return at an agreed date/time for collection. This example illustrates a further Pharmacy development requirement, identified from the evaluation. In the control trial, when a barcoded prescription was subsequently scanned after it had previously been dispensed, the Pharmacist was not able to re-enter that particular patient transaction to make an amendment to the record. This prototype development was to alert the Pharmacist to a possible prescription duplication and it automatically blocked any further actions. The Programme therefore recommends that the Pharmacy system supplier’s development should ‘warn’ rather than ‘block’ a Pharmacist from continuing with a transaction, when a barcoded has been subsequently re-scanned at a later time/date. In the case of an owing, the Pharmacist can in the future complete the dispensation of the prescription by a second scan of the barcode, noting that this prescription would be re-identified by its UPI. Addition of Items In some very rare instances where an additional item, not listed on the prescription, is required to complete a dispensed drug (for example where water is required to make up a solution), the Pharmacist must have the facility to add the additional item to the prescription


___________________________________________________________________________________


Page: 22 of 32

being processed. The additional item will also be added to the dispensation record / labels etc. when it is generated. Handwritten Prescriptions When a patient visits a pharmacy with a non-barcoded, printed prescription – or indeed a manually written prescription – the existing dispensation process must not be affected by the 2DRx development enhancement to the pharmacy system. Therefore, in such circumstances, when a non-barcoded prescription is received, a Pharmacist should be able to manually enter data into the system using his/her keyboard and dispense the prescription normally. Nursing Home Prescriptions These prescriptions are typically submitted to the Pharmacist in a batch and collected later when dispensed by the Pharmacist. The 2DRx process must allow dispensing of multiple prescriptions in the same way as the majority of ‘repeats’; i.e. batched dispensations ready for collection in the normal manner.


___________________________________________________________________________________


Page: 23 of 32

APPENDIX A

Ref Process Name Process Description

1 Receive Paper Prescription

Patient enters Pharmacy of choice and presents paper prescription to Pharmacist

2 Scan 2D Barcode Pharmacist scans the 2D barcode using a scanner

3 Automatic Creation of Electronic Record

The system automatically stores the data read from the 2D barcode for further processing

4 System Attempts to Match Existing Patient Details from PMR

The system will search the existing PMR for a possible Patient Match against the details contained within the barcode. For subsequent barcoded prescriptions, the NHS Number will be used to get an exact match of the patient; otherwise Date of Birth, Surname and Forename will be used, resulting in a number of possible matches displayed as a list to the Pharmacist

5 System Does Not Find Patient Match on PMR

Where no patient match is identified, the Pharmacist should be able to create a NEW Patient Record and automatically accept all barcoded data; i.e. patient/GP demographic data

6 Select Patient from System-Suggested List

Where possible Patient Match is identified, the Pharmacist selects the appropriate patient from the list, or confirms that the one selected (as closest match) is correct

For each drug item on the prescription

7(a) System Attempts to Match DM + D Drug Codes with PMR Drug Codes – i.e. ‘mapping’ process

The system will automatically attempt to match the prescribed drug by its dm + d drug code against the PMR drug dictionary (where dm + d is not adopted natively), using a ‘mapping’ process. This will be the primary source of drug matching. Where ‘mapped’ correctly, the system automatically selects the prescribed drug for further processing; otherwise, the system matches the first few text characters of the drug description with the drugs database on the PMR. This matching process will display a list of drugs in a similar way to the current process of selecting drugs and is the secondary source of drug matching, where dm + d codes cannot be ‘mapped’

7(b) Select Drug from System-suggested list

Pharmacist selects the appropriate drug from the list, or alternatively can manually enter a different drug from their own lists (e.g. personal list)

8 Process Drug and Related Data from 2D Barcode

Import and automatically populate the dm + d drug code (or full text of drug(s) description extracted from 2D barcode) into the patient’s PMR record, together with other 2D barcode-captured data from the GP system such as Drug Quantity, Dosage and Directions

9 Print Drug Label(s) Bottle / Pack label(s) printed, as at present

For each prescription

10 System Prints Bag Label(s) When all items on the prescription have been dispensed, the system will print a Bag Label(s), as normal, including all medication items dispensed.


___________________________________________________________________________________


Page: 24 of 32

Ref Process Name Process Description

All printing will be done using the existing label printers in the Pharmacy.


___________________________________________________________________________________


Page: 25 of 32

APPENDIX B This section contains the source of the validation schema for the barcode XML data and is for reference purposes only. This version of the schema is a copy extracted from the Northern Ireland EPES Specification Documents; however, suppliers would be expected to create and validate the XML schema according to the Welsh-specific data provided in this document.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="xml"> <xs:complexType> <xs:sequence> <xs:element name="sc"> <xs:annotation> <xs:documentation>Script</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="id" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Precription id</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="ft"> <xs:annotation> <xs:documentation>Form type</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="HS21"/> <xs:enumeration value="HS21D"/> <xs:enumeration value="HS21N"/> <xs:enumeration value="HS21X"/> <xs:enumeration value="PV1"/> <xs:enumeration value="WP10SS"/>

<xs:enumeration

value="WP10PN"/>

<xs:enumeration

value="WP10CN"/> <xs:enumeration value="WP10SPSS"/> <xs:enumeration value="WP10IPSS"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="t" type="xs:date"> <xs:annotation> <xs:documentation>Prescription date</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="r" type="xs:string"> <xs:annotation> <xs:documentation>Repeat info</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="rm" type="xs:string"> <xs:annotation>


___________________________________________________________________________________


Page: 26 of 32

<xs:documentation>Repeat master script id</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="pa" minOccurs="0"> <xs:annotation> <xs:documentation>Patient</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="l" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Patient last name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="m" type="xs:string"> <xs:annotation> <xs:documentation>Middle names</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="f" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Patient first name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="s" type="xs:string"> <xs:annotation> <xs:documentation>Patient title</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="h" type="xs:string"> <xs:annotation> <xs:documentation>Health care number / NHS number</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="b" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Patient date of birth</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="x"> <xs:annotation> <xs:documentation>Gender, 0=unknown, 1=male, 2=female or 9=unspecified</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="9"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="a" use="required"> <xs:annotation> <xs:documentation>Address lines, comma-delimited</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="pc" use="required"> <xs:annotation>


___________________________________________________________________________________


Page: 27 of 32

<xs:documentation>Post code</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="pb"> <xs:annotation> <xs:documentation>Prescriber</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="i" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Doctor id</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="d" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Doctor name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="n" type="xs:string"> <xs:annotation> <xs:documentation>Practice name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="pi" type="xs:string"> <xs:annotation> <xs:documentation>Practice id</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="a" type="xs:string"> <xs:annotation> <xs:documentation>Practice address lines, comma-delimited</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="pc" type="xs:string"> <xs:annotation> <xs:documentation>Post code</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="gp" minOccurs="0"> <xs:annotation> <xs:documentation>Patient's GP, if different from prescriber</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="i" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Doctor id</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="d" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Doctor name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="n" type="xs:string"> <xs:annotation> <xs:documentation>Practice name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="pi" type="xs:string">


___________________________________________________________________________________


Page: 28 of 32

<xs:annotation> <xs:documentation>Practice id</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="a" type="xs:string"> <xs:annotation> <xs:documentation>Practice address lines, comma-delimited</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="pc" type="xs:string"> <xs:annotation> <xs:documentation>Post code</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="rc" minOccurs="0"> <xs:annotation> <xs:documentation>Responsible GP</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="i" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Doctor id</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="d" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Doctor name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="n" type="xs:string"> <xs:annotation> <xs:documentation>Practice name</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="pi" type="xs:string"> <xs:annotation> <xs:documentation>Practice id</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="a" type="xs:string"> <xs:annotation> <xs:documentation>Practice address lines, comma-delimited</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="pc" type="xs:string"> <xs:annotation> <xs:documentation>Post code</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="dd" minOccurs="0" maxOccurs="4"> <xs:annotation> <xs:documentation>Drug items</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="d" type="xs:string" use="required"> <xs:annotation> <xs:documentation>Drug description</xs:documentation> </xs:annotation> </xs:attribute>


___________________________________________________________________________________


Page: 29 of 32

<xs:attribute name="q" type="xs:string"> <xs:annotation> <xs:documentation>Drug quantity</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="sq" type="xs:string"> <xs:annotation> <xs:documentation>SNOMED coded UOM quantity</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="do" type="xs:string"> <xs:annotation> <xs:documentation>Dosage</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="c" type="xs:string"> <xs:annotation> <xs:documentation>Drug code</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="dm" type="xs:string"> <xs:annotation> <xs:documentation>DM_D code</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="u" type="xs:string"> <xs:annotation> <xs:documentation>Unit, or SNOMED coded UOM unit</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

The following is the source of a sample XML data file, which contains information of a 2DRx barcoded prescription form printed by a GP supplier system using the prototype specification. This example XML file is therefore for reference purposes only.

- <prescription>

- <patient id="5948">

- <name>

<full>Mr Maurice Boott Grant</full>

<title>Mr</title>

<forename>Maurice</forename>

<middle_name>Boott</middle_name>

<surname>Grant</surname>

</name>

- <address>

<line>Pen Yr Allt Bodeder</line>

<line>Holyhead</line>

<line>Ynys Mon</line>

- <postcode>

<full>LL65 3UF</full>

<first>LL65</first>

<second>3UF</second>

</postcode>

<phone>Patient bus tel not found</phone>

</address>

- <age>

<full>41y 7m</full>


___________________________________________________________________________________


Page: 30 of 32

<year>41</year>

<month>7</month>

</age>

<dob>11/10/65</dob>

<dobDigitsOnly>19651011</dobDigitsOnly>

<sex>1</sex>

<code>922 363 8887</code>

</patient>

- <registered_gp id="8">

- <name>

<full>Dr Lindsay Smith</full>

<title>Dr</title>

<forename>Lindsay</forename>

<surname>Smith</surname>

</name>

<type>1</type>

<code>940558</code>

<nmc>Clin. NMC no. not found</nmc>

<hsw>Clin. HSW reg no. not found</hsw>

<gmc>3333339</gmc>

<phone>01234 567890</phone>

- <employer>

<name>The Health Centre</name>

- <address>

<line>234 Ashtree Road</line>

<line>Leeds</line>

<line>Yorkshire</line>

- <postcode>

<full>LS12 3RT</full>

<first>LS12</first>

<second>3RT</second>

</postcode>

<phone>01234 567890</phone>

</address>

<code>G23456</code>

</employer>

</registered_gp>

- <clinician id="6">

- <name>

<full>Dr John Mcallister</full>

<title>Dr</title>

<forename>John</forename>

<surname>Mcallister</surname>

</name>

<type>1</type>

<code>831167</code>

<nmc>Clin. NMC no. not found</nmc>

<hsw>Clin. HSW reg no. not found</hsw>

<gmc>2222223</gmc>

<phone>01234 567890</phone>

- <employer>


- <address>


<line>Leeds</line>


- <postcode>


<first>LS12</first>


</postcode>

<phone>01234 567890</phone>

</address>

<code>G23456</code>

</employer>

</clinician>


___________________________________________________________________________________


Page: 31 of 32

- <practice>


- <address>


<line>Leeds</line>


- <postcode>


<first>LS12</first>


</postcode>

<phone>01234 567890</phone>

</address>

<code>G23456</code>

- <senior_partner>

- <name>

<full>Dr Alison Hill</full>

<title>Dr</title>

<forename>Alison</forename>

<surname>Hill</surname>

</name>

</senior_partner>

</practice>

- <pct>

<name>The Primary Care Trust</name>

- <address>

<line>2 The Main Road</line>

<line>Anytown</line>

<line>Anywhere</line>

- <postcode>

<full>AN12 4PT</full>

<first>AN12</first>

<second>4PT</second>

</postcode>

<phone>PCT bus tel not found</phone>

</address>

<code>PCT code not found</code>

</pct>

<pharmacy>DISP</pharmacy>

- <lhs>

- <token>

<id>68D75CDA-65BA-4DFD-B96D-8EAAC995A762</id>

<page_num>1</page_num>

<num_pages>--</num_pages>

</token>

- <drug ty="39" id="451787">

- <text>

- <![CDATA[ NABILONE caps 1mg. Mitte (12) capsule(s).

]]>

</text>

- <dosage>

- <![CDATA[ AS NEEDED

]]>

</dosage>

<pack_size>20.00</pack_size>

<drug_name>NABILONE caps 1mg</drug_name>

<pack_description>12</pack_description>

- <quantity>

<value>12</value>

<preparation>capsule(s)</preparation>

</quantity>

<dmandd_code>000000000322126007</dmandd_code>

<date>22/05/2007</date>

<dateDigitsOnly>20070522</dateDigitsOnly>


___________________________________________________________________________________


Page: 32 of 32

- <age>

<full>41y 7m</full>

<year>41</year>

<month>7</month>

</age>

</drug>

</lhs>

</prescription>