IPU eprescribing User Requirements Specification for Primary Care. Draft for Consultation

IPU eprescribing User Requirements Specification for Primary Care Draft for Consultation

User Requirements Specification A document of expected functionality required for a Primary Care eprescribing System. Document History Date Version Author(s) Changes 01 January 2018 0.1 Jack Shanahan 19 January 2018 0.2 Alan Reilly Formatting 28 January 2018 0.3 Jack Shanahan Signature and extemporaneous & substitution categories 1 February 2018 0.4 Alan Reilly Formatting; medicinal product information; hub design; messaging. 2 February 2018 0.5 Jack Shanahan Use Cases 14 March 2018 0.6 Hugh Glover HL7 Messaging 21 March 2018 0.7 Alan Reilly Renamed document; incorporated Blue Wave analysis. 0.8 Alan Reilly Prepared for Public Consultation Feedback Form This is a preliminary draft for discussion. All comments for inclusions, exclusions, errors, omissions, suggestions for improvement are welcome. Please send to Alan Reilly alan.reilly@ipu.ie

Definitions Prescriber is a healthcare professional authorised to issue prescriptions e.g. GP, Dentist or Registered Nurse Prescriber. Prescribing is the intellectual process of deciding on a treatment and physically issuing a prescription information object. All aspects that lead to defining the entered information are regarded as being prior to prescription entry. review is a legally required process, which pharmacists undertake, of all prescription information to ensure the therapy is safe and appropriate for the patient. To fulfil this task, the pharmacist should have access to information concerning the current treatment of the patient and medication already dispensed. For a prescription to be validated, more than one pharmaceutical review may be needed. During this process, there may be a need to contact the prescriber. ehealth is electronic health and refers to the provision of healthcare services supported by modern electronic information, management tools and processes for health services with the support of Information and Communication Technology (ICT) i.e. computers, mobile phones, satellite communications, etc.; this includes mhealth, telehealth, eprescribing and Electronic Health Record (EHR). eprescribing is electronic prescribing, the computer-based electronic generation, transmission and filing of a medical prescription. It allows medical practitioners to write and send prescriptions to a pharmacy electronically instead of using paper prescriptions. In the context of eprescribing in Ireland, the paper prescription is currently the required legal document for dispensing. Electronic Health Record (EHR) is a compilation of core health data submitted by various healthcare providers and organisations, accessible by restricted authorised parties, from a number of points of care across the country. Shared Care Record (SCR) is a summary health data submitted by various healthcare providers and organisations, accessible by restricted authorised parties, from a number of points of care across the country. Health Service Executive (HSE) provides public health and social care services to everyone living in Ireland. Primary Care Reimbursement Service (PCRS) part of the HSE; responsible for making payments to healthcare professionals, like GPs, dentists and pharmacists, for the services they provide to the public.

ehealth Ireland is the technology delivery function of the HSE. Its remit is to bring improved population well-being, health service efficiencies and economic opportunity through the use of technology-enabled solutions. Healthlink is an electronics communications project which facilitates the transfer of information via an electronic messaging service and allows the secure transmission of clinical patient information between hospitals, healthcare agencies, clinical centres and GPs in Ireland. Individual Health Identifier (IHI) is a number that safely identifies a person who has used, is using or may use a health or social care service in Ireland. Health Service Provider Identifier (HSPI) is a number that safely identifies a person or establishment/organisation providing a health or social care service in Ireland.

DEFINITIONS... 3 1 INTRODUCTION... 7 1.1 PURPOSE... 7 1.2 OBJECTIVE... 7 1.3 PCEPS SCOPE... 7 1.4 OUT OF SCOPE... 8 1.4.1 Controlled Drugs... 8 1.5 ASSUMPTIONS... 8 1.6 CONSIDERATIONS... 8 1.7 SYSTEM REQUIREMENTS... 9 2 SYSTEM DESIGN... 10 2.1 CENTRAL HUB: SCDR APPROACH... 10 2.2 A NATIONAL MESSAGE BROKER SYSTEM: HEALTHLINK... 10 2.3 NATIONAL MEDICINAL PRODUCT CATALOGUE... 11 2.3.1 Standard Data Model... 11 2.3.2 IPU Product File... 11 2.3.3 GP File... 11 2.3.4 Common Medicinal Product Code... 11 2.4 IDENTIFIERS... 12 2.4.1 Patient Identifier... 12 2.4.2 Health Service Provider Identifier... 12 2.5 STANDARDISED MESSAGES AND METHODOLOGY... 12 2.5.1 HIQA-defined Use Cases... 12 2.6 EPRESCRIBING MESSAGES... 13 2.6.1 GP Messages... 13 2.6.2 Pharmacy Messages... 13 2.7 PROPOSED STRUCTURE... 13 2.8 EPRESCRIPTION DATA MODEL... 14 2.8.1 Structure and Data Elements... 14 2.8.2 Practical Implementation... 17 2.9 SCDR FUNCTIONALITY... 18 2.9.1 Phase 1 Simple ETP... 18 2.9.2 Phase 2 Shared Care Record... 18 2.10 PHARMACY SYSTEM FUNCTIONALITY... 19 3 PCRS REIMBURSEMENT... 20 3.1 PROPOSED SOLUTION... 20 3.1.1 Prescribing Software... 20 3.1.2 Dispensing Software... 20 4 NON-TECHNICAL REQUIREMENTS... 21 4.1 GOVERNANCE... 21 4.1.1 Governance board... 21 4.1.2 Governance constitution... 21 4.1.3 Information governance... 21 4.2 LEGISLATIVE ISSUES... 22 5 TECHNICAL REQUIREMENTS... 23 5.1 INTEROPERABILITY... 23 5.2 PERFORMANCE... 23 5.3 SECURITY... 23 6 IT VENDOR ENGAGEMENT... 24 7 USE CASE ANALYSIS... 25

7.1 BLUE WAVE INFORMATICS... 25 7.2 ANALYSIS TECHNIQUE... 25 7.3 STORYBOARD: SIMPLE PRESCRIPTION... 26 7.4 IMPLEMENTATION: HL7 V2... 32 7.5 IMPLEMENTATION: CDA... 32 7.6 IMPLEMENTATION: FHIR... 32 7.7 APPENDIX FHIR RESOURCE DRAWINGS... 35 8 REFERENCES... 37

1 Introduction The Irish Pharmacy Union (IPU) is the representative and professional body for community pharmacists. Its mission is to promote the professional and economic interests of its members. Members of the IPU aim to provide the best possible professional pharmaceutical service to all members of the public. They are committed to delivering a quality, accessible, personal and professional service that puts the patient first and has as its primary goal the optimisation of the health and well-being of society. Pharmacists are accountable for their professional conduct and strive to maintain the confidence and respect of their patients, customers, the State and other professionals in the healthcare field. This IPU User Requirements Specification for eprescribing details the functionality required to manage an electronic prescription (e) and outlines the necessary infrastructure and principles for technology solutions that will be part of a national system in primary care. 1.1 Purpose To produce the IPU eprescribing User Requirements Specification (URS) for Primary Care that will be a comprehensive and pragmatic approach to the unique nuances of Irish work practices and legislation pertinent to GP practices and pharmacies. This document is not a technical specification, although it may use specific technical examples to describe a concept. However, the URS will reference published standards in this country that are more technically specific i.e. HIQA s GP Messaging Standards, e dataset and CDA standard, and Data model for a national electronic drug reference catalogue. For clarity, this URS describes eprescribing in Primary Care i.e. between GP practices and community pharmacies. 1.2 Objective To provide the necessary direction for the design of a Primary Care eprescribing System (PCePS) for adoption across the Republic of Ireland. The principal objectives of the PCePS project are: 1. To enable the Electronic Service (EPS) in Ireland between: Prescribers (GPs) Dispensers (Pharmacists) Secure Clinical Data Repository (SCDR / Central Hub) Primary Care Reimbursement Service (PCRS) 2. To facilitate the provision of enhanced patient-centred services by GPs and community pharmacists which require access to the SCDR e.g. Shared Care Record. 1.3 PCePS Scope PCePS starts at the point where a decision to prescribe has been taken and ends when medication is dispensed and reimbursed (or prescription is cancelled, expires etc.). PCePS covers all primary care prescribing and dispensing (including repeat dispensing) and supply of medicines, drugs, appliances and chemical reagents by community pharmacists for both privately paid and State-paid items. Secondary care prescriptions issued for dispensing in the community.

1.4 Out of Scope 1.4.1 Controlled Drugs Schedule 2 and 3 controlled drugs only out of scope; these items must be hand-written. Other schedules can be printed. Note: The Misuse of Drugs Regulations can be amended to facilitate eprescribing, i.e. remove the requirement for handwriting. 1.5 Assumptions The following is a list of assumptions; the concepts will be explained in context throughout the document: An e as a prescription that is generated electronically, by an authorised prescriber, and can be transmitted and received without the need for paper. Given the current regulatory framework, es have no legal standing. A paper form, bearing a signature in ink, being the only legal prescription object. As noted above, the Misuse of Drugs Regulations can be amended to facilitate eprescribing, i.e. remove the requirement for handwriting. es should be more than simple messages to replace paper. A national electronic system needs to add meaningful functionality over current paper based systems. All system messages will be designed for standardisation and full interoperability. They will be system/vendor agnostic. One prescriber per prescription. If a second prescriber is involved, then a separate prescription is required. One patient per prescription. No ambiguity on the e. The patient, prescriber, treatment, posology and authentication information are all clear. items will have a unique medicinal product code, common to GP and pharmacy software systems e.g. IPU Product Code. 1.6 Considerations The following is a list of considerations to bear in mind when designing a Primary Care eprescribing System: While the exact figures are not known, up to 100 million prescription items are dispensed annually in Ireland. Over 70 million are paid, or partially paid, through the PCRS. Of these, approximately 60 million are GMS prescriptions. Many private prescriptions can be repeated for up to 6 months, depending on the statutory classification and the stated wishes of the prescriber. Simple GMS prescriptions are not repeatable, although there is a facility where multiple forms are issued with sequential monthly dates, i.e. GMS three-month prescription. Currently, because of PCRS reimbursement rules, all the items on a single GMS form must be dispensed in a single pharmacy. If the requirement for paper prescriptions recedes, then this condition could also vanish. A special type of GMS form, the GMS repeat, can be dispensed up to three occasions. These have legal and PCRS restrictions associated with them that make it complicated to reproduce.

Not all GMS prescriptions originate from the GP surgery. Hospital Emergency prescriptions, based on hospital discharge prescriptions, are treated as GMS prescriptions for GMS patients, as are Dental GMS prescriptions. Currently the PCRS requires the doctor s GMS contract number to be associated with a GMS prescription, solely for reimbursement purposes. This is separate from the Medical Council Number, which must be captured for all prescriptions. 1.7 System Requirements The following items have been identified as required components for a Primary Care eprescribing System: Central Hub: Secure Clinical Data Repository A National Message Broker System: Healthlink A National Medicinal Product Catalogue or a Common Product Identifier across GP and pharmacy systems Patient Identifiers Healthcare Provider Identifiers GP software with the ability to send and receive standardised messages Pharmacy software with the ability to send and receive standardised messages An agreed Primary Care eprescribing Technical Specification for IT vendors Governance Some of the above items listed already exist, some do not. This document will describe each component and how they might be used, or developed, to support a national Primary Care eprescribing System.

2 System Design eprescribing is electronic prescribing: the computer-based electronic generation, transmission and filling of a medical prescription. It allows GPs and other medical practitioners to write and send prescriptions to a pharmacy electronically instead of using handwritten notes. In the context of eprescribing in Ireland, the paper prescription is currently the required legal document for dispensing. Figure 1 is a simple illustration of the proposed Primary Care eprescribing System. Healthlink will broker the GP and Pharmacy system messages to and from the SCDR GP Pharmacy GP SCDR Pharmacy GP PCRS (controlled audit) Pharmacy Figure 1: Simple eprescribing Model 2.1 Central HUB: SCDR Approach From studying other systems including Australia, Canada, UK, USA and Greece, it is clear that the most suitable system is a hub-based messaging approach. This allows all prescription messages to be sent to a central hub, a State-provided Secure Clinical Data Repository (SCDR). The SCDR will contain all current prescription data, as well as dispensing information, for a defined period. The information on this SCDR can be accessed by authorised people only, with defined levels of access, supervised by an appropriate governance structure/authority e.g. Healthlink. 2.2 A National Message Broker System: Healthlink Originally set up by the Department of Health, Healthlink started as an electronics communications project which facilitates the transfer of information between primary and secondary care in Ireland. Since the formation of ehealth Ireland, Healthlink has been brought under the Office of the Chief Information Officer (CIO) in the HSE and its role has expanded to allow the secure transmission of clinical patient information between Hospitals, Health Care Agencies, GPs and pharmacies. Healthlink has the functionality to broker messages between GP and pharmacy systems via the SCDR; this has been proven in existing test systems.

2.3 National Medicinal Product Catalogue The National Medicinal Product Catalogue (NMPC) will be an electronic dictionary of medicinal products available for prescribing and dispensing. The key aim of the catalogue is to provide a consistent approach to the identification and naming of medicinal products prescribed and dispensed. The HSE is working to deliver an NMPC in Ireland. 2.3.1 Standard Data Model In January 2015, HIQA published its standard data model for an electronic medicinal product reference catalogue i. The standard defines the data model required to support the implementation of an electronic medicinal product reference catalogue, essentially an electronic dictionary of medications available for prescribing and dispensing. The data model catalogue was developed by HIQA in collaboration with the ehealth Standards Advisory Group (esag) and a technical subgroup which was primarily made up of pharmacist and GP representatives. 2.3.2 IPU Product File The IPU Product File is a medicinal product catalogue completely in line with the HIQA standard; it is in existence for over 30 years and is used by over 96% of community pharmacies in Ireland. From 2000 to 2015, GPs used the IPU Product File, sub-licensed through their system vendor, Helix Health and Socrates at the time. Both companies are now under the umbrella of Clanwilliam Health. Since 2015, Clanwilliam Health provides their GP customers with a drug file. 2.3.3 GP File Since 2015, Clanwilliam Health has a licence for the IPU Product File for use in the prescribing modules of Clanwilliam Health practice management systems. Each month, Clanwilliam produces its Safescript Drug File which includes information from the IPU Product File e.g. the IPU Product Code (a unique identifier). Clanwilliam Health provides software systems to 90% of GP practices in Ireland. 2.3.4 Common Medicinal Product Code Until a NMPC is delivered, a common medicinal product code will meet the requirements of a Primary Care eprescribing Solution. The IPU Product Code is a unique identifier common to both the IPU Product File (96% of community pharmacies) and the Clanwilliam GP file (90% of GP practices). 2.3.4.1 Why not SNOMED CT? On 31 October 2016, the OoCIO of the HSE announced that, in conjunction with the DoH, it joined SNOMED International as their 29th member. The Assess CT report ii, published in December 2016, evaluated SNOMED CT for large scale ehealth deployments in the EU, producing five recommendations. Recommendation 4 sets out that the adoption of SNOMED CT should be realised incrementally rather than all at once, by developing terminology subsets that address the interoperability requirements for priority use cases and expanding these sets over a number of years. While the IPU has started mapping the Dose Form, Route of Administration and EDQM values in the IPU Product File to SNOMED CT codes, at this point in time there is no mapping at a medicinal product level. It is early days for SNOMED Ireland

and it will be some time before Ireland has the national extension codes necessary for product-level coding. 2.4 Identifiers The HSE Individual Health Identifiers Programme has been established to focus specifically on the Individual Health Identifier (IHI) national register. Separate projects will be established to focus on the national registers for Health Service Providers and Healthcare Organisations. 2.4.1 Patient Identifier An IHI is a number that identifies each person who has used, is using or may use a health or social care service in Ireland. IHIs have been rolled out to GP systems and it is proposed that IHIs will expand out to pharmacy systems via various mechanisms, one being e messages. 2.4.2 Health Service Provider Identifier As part of the IHI programme, a register of health service providers will be established. Until that is in place, GPs and pharmacists have existing unique identifiers e.g. Medical Council Number (MCN) and PSI Number respectively. 2.5 Standardised Messages and Methodology The PCePS will use standardised HL7 messages. All GP and pharmacy messages will go through the SCDR. All messages will have acknowledgement and error functionality. 2.5.1 HIQA-defined Use Cases HIQA defined the following ten use cases for eprescribing in their General Practice Messaging Standard iii : 1. GP: Medication items are prescribed 2. Pharmacy: Electronic message is retrieved from the message exchange (SCDR) 3. Pharmacy: All medication items dispensed 4. Pharmacy: No medication items are dispensed 5. Pharmacy: Some medication items are not dispensed 6. Pharmacy: Medication items are dispensed (no e exists) 7. Pharmacy: Modifies medication items (e exists) 8. Pharmacy: Modifies medication items (no e exists) 9. GP: Cancels prescription 10. Pharmacy: Cancels prescription Section 2.2 of the General Practice Messaging Standard describes each use case, the supporting system interactions that occurs, trigger events, message types and required segments/data fields for each interaction.

2.6 eprescribing Messages Building on the HIQA-defined messaging methodology, the following use cases will cross-over the above ten with some additional use cases presented. 2.6.1 GP Messages 1. GP: Send prescription 2. GP: Send prescription query (status/dispensing history) 3. GP: Receive prescription query results 4. GP: Send Cancel notification 5. GP: Receive Cancel Result (Success/ already dispensed) 6. GP: Receive Query from Pharmacy 7. GP: Send Query Reply to Pharmacy 8. GP: Request Summary Medication Record 9. GP: Receive Summary Medication Record 2.6.2 Pharmacy Messages 1. Pharmacy: Request prescription 2. Pharmacy: Receive prescription (or error result) 3. Pharmacy: Send dispense record (against specific prescription) 4. Pharmacy: Send prescription for item prescribed by pharmacist e.g. EHC 5. Pharmacy: Send dispense/not dispensed record for item prescribed by pharmacist 6. Pharmacy: Send prescription query to specific GP 7. Pharmacy: Receive confirmation of deliver of prescription query to specific GP 8. Pharmacy: Receive prescription query reply 9. Pharmacy: Send non-dispense notification 2.7 Proposed Structure

2.8 e Data Model 2.8.1 Structure and Data Elements There are quite a number of elements required for a successful, unambiguous prescription message. These are set out in HIQA s e dataset and clinical document architecture standard iv where an e is modelled around Patient, Prescriber and Item(s) information; these are detailed as follows: 2.8.1.1 Patient / Subject of Care Name Definition ity Usage Title Coded value that contains the title relevant to the subject of care. To be selected from a predefined list. Forename A patient s first name or given name(s) as recorded on their birth certificate. Mandatory A patient s first name or given name(s) as recorded on their birth certificate. Surname The second part of a patient s name which denotes their family or marital name. Mandatory The second part of a patient s name which denotes their family or marital name. Address Date of birth 1 Sex Health identifier The location to be used to contact or correspond with the patient. This would normally be the patient s usual home address. Date of birth indicating the day, month, and year when the patient was born. Sex is the biological distinction between male and female. Where there is an inconsistency between anatomical and chromosomal characteristics, sex is based on anatomical characteristics. A number or code assigned to an individual to uniquely identify the individual within an organisation. Mandatory Mandatory Mandatory The particulars of the place where the patient lives. The date of birth should be supplied in dd/mm/yyyy format. Examples of sex include male and female Both the code and the code type that the code relates to should be provided, for instance 0987654321 Healthcare Record Number (HcRN). When a national individual healthcare number is 1 The prescription should also state the patient s age if under 12

2.8.1.2 Prescriber / Healthcare Practitioner available, this should be carried in this attribute. Other identifiers which may be carried in this field include the General Medical Scheme, Drug Payment Scheme, Long-term Illness Scheme and Hardship Scheme identifier. Name Definition ity Usage Title Coded value that contains the title relevant to the healthcare practitioner. To be selected from a predefined list. Forename Surname Address 2 Telephone number Email address Fax number Health identifier 2.8.1.3 Item First name or given name of healthcare practitioner. The second part of a healthcare practitioner s name which denotes their family or marital name. The particulars of the place used to correspond with the healthcare practitioner. The telephone number of the prescriber A secure email address for the healthcare practitioner. The fax number for the healthcare practitioner. A number or code assigned to an individual to uniquely identify the individual within an organisation or professional regulatory body. Mandatory Mandatory Mandatory Mandatory Where the healthcare practitioner is registered with a professional body, the forename should be the forename registered with the professional body. Where the healthcare practitioner is registered with a professional body, the surname should be the surname registered with the professional body. The particulars of the place used to correspond with the healthcare practitioner. The phone number to contact the prescriber The secure email address to contact the healthcare practitioner. The fax number to contact the healthcare practitioner The number or code assigned to the professional by its regulatory authority or the health services providers identifier when it is implemented. Name Definition ity Usage Date written Date prescription was written. Mandatory Date field which indicates when the prescription was written. This is the same as the date the document and or prescription 2 Not legally required on GMS prescriptions

Effective date Status Medicinal product code Medicinal product Medicinal product package Number of packages Dose form (strength) Dose form (type) Total number of dose instances Dose (number of instances) Frequency Date prescription becomes effective. Status of the prescription. Code that identifies the medicinal product. The name of the medicinal product or package. This should be sufficient for a pharmacist to identify the kind of medication to dispense. It may be a trade name or a generic name. Size and or type of package prescribed. Number of complete packages required to fulfil the prescription. Content of the active ingredient expressed quantatively per dosage unit, per unit of volume or per unit of weight, according to the pharmaceutical dose form. A description of the dose type. Total number of instances of the medicinal product required to fulfil the prescription. Number of instances of the medicinal product to be taken by the patient at a given time. How often the medication is to be administered, often expressed in number of times per day but may also include information such as 1 came into being or was created on. Mandatory Date field which indicates when the prescription becomes effective. For example, the date on which the healthcare practitioner instructs the patient to begin the treatment. Mandatory Coded value, that is to say, 1 =active 2= on hold, 3= completed Mandatory A code associated with the medicinal product. Mandatory A textual description associated with the medicinal product. Conditional When prescribing occurs at a package level, this field is used to describe the size and type of the package to dispense. When prescribing occurs at a package level, this field is used to describe the number of the package(s) to dispense. This field consists of a size value and unit, a combination of both defines the strength, for example 250 mg, 1g. This field describes the does type, such as tablet, vial. This field is used to describe the number of the units(s) to dispense. This field is used to describe the number of units(s) to be taken at a given time. This field is used to describe the frequency the dose described in Dose should be taken by the patient.

Duration Route of administration Advice to pharmacist Substitution 3 Indications Repeats Number of Repeats Advice to patient hour before or after meals. Duration of time for the regime to be taken. Coded element which indicates how the medication is to be received by the patient. Any advice the prescriber might suggest to the pharmacist. Used to indicate if the medication prescribed may not be substituted. Clinical information about the reason for providing the medication. This is to indicate that a prescription item can repeat or not. This is the number of times that each prescription item can repeat. Any advice the prescriber might suggest to the patient. This field is used to describe the duration the dose described in Dose should be taken by the patient. A representation of the place in or on the body when the medicinal product or active ingredient is introduced in order to achieve the desired effect e.g. oral, IV. Additional advice the prescriber may provide to the pharmacist. Indicates whether the prescriber does not want generic substitution to occur. This could be coded to include Do Not Substitute. This will be a code and description. This should be coded to include the values Do Not Repeat (N) or Can Repeat (Y). This should be a numerical value Additional advice the prescriber may provide to the patient 2.8.2 Practical Implementation For practical purposes the message must clearly identify, in a standard format, all the necessary core elements. These are: 1. Patient (the subject of care): Demographic information, including DOB if under 12 years. Medical card information, if applicable. 2. Authorised healthcare provider (the prescriber): Demographic, contact, statutory id. Doctor GMS number if PCRS need data. 3. Therapy (the prescription item): from national medicinal product catalogue or other validated and verified product catalogue. Form, quantity 4. Posology (the prescription item): Route of administration, directions for use, conditionality, duration of treatment, start date (if applicable). 5. Authentication, including digital signature. 3 Current legislation requires this to be in the prescriber s handwriting

2.9 SCDR Functionality The functionality of the Secure Clinical Data Repository is key to the potential of a Primary Care eprescribing System. There are two main approaches: 2.9.1 Phase 1 Simple ETP The first is to simply store a current prescription until it is either retrieved or expires. It would store minimal dispense information, other than exceptions and repeats. Used purely as an Electronic Transfer of (ETP) system, the SCDR will: 1. Generate and receive structured messages 2. Validate and Authenticate 3. Store current prescriptions up to expiry (6 months, with some exceptions) 4. Store repeat information. 5. Update repeat information from pharmacy. 6. Accept and update prescription with pharmacy exceptions (where an item is partially dispensed or not dispensed). 7. Allow for cancellation by prescriber. A simple store and transfer of prescription information is not suitable for most e use cases that currently exist. Of necessity, the e needs to be persistent until each line item is: Fully dispensed; Flagged as inappropriate to dispense ; Expired; or, Cancelled. 2.9.2 Phase 2 Shared Care Record A Hub or SCDR that stores dispense information with the ability to generate a summary record for GPs, pharmacists, emergency departments and other authorised categories; additional SCDR functionality will: 1. Store dispense information associated with current prescription or older if dosage form is given at >6 month intervals. 2. Be capable of providing summary of prescribed/dispensed items in the form of a medication profile. 3. Prioritise routing for pharmacy prescription query (where pharmacist requires urgent clarification prior to safely dispensing). Development of Phase 1 will support growth towards Phase 2. 2.9.2.1 Benefits of a Shared Care Record Upon a review of international evidence and best practice, HIQA has concluded that using a central secure record of people s medical history can help to improve patient care and safety by giving healthcare professionals timely access to relevant patient information to guide care and treatment, such as in an emergency department or a pharmacy. v

2.10 Pharmacy System Functionality A Primary Care eprescribing System will use an SCDR to link GP software and community pharmacy software, specifically the PMR (Patient Medication Record) within the dispensary system. There are currently three companies (vendors) providing dispensary systems for community pharmacy in Ireland: McLernons, Clanwilliam and Touchstore. Without getting into technical details, to engage with a Primary Care eprescribing System, pharmacy systems will need the following functionality: 1. Connection to SCDR a. Authenticate pharmacy b. Authenticate pharmacist 2. Read/receive authorisation token to access prescription on SCDR 3. Retrieve prescription a. Scan barcode b. Lookup patient 4. Parse prescription into appropriate fields that can be directly written to PMR, avoiding transcription errors: a. Extract Patient Identifier i. Map to existing patient in PMR ii. Create new patient 5. Present for review by pharmacist a. Extract Product Identifiers 6. If required, support generation and transmission of prescription query to prescriber 7. Facilitate pharmacist to make modifications for safety, substitution or other reasons 8. Import information approved by pharmacist into PMR 9. Return dispense information to SCDR a. Full dispense b. Partial dispense c. Non-dispense 10. Retrieve summary medication history, to support clinical decisions, if available 11. Submit data on items prescribed and dispensed in pharmacy

3 PCRS Reimbursement While this document primarily addresses the clinical, electronic messaging and pharmacy workflow requirements for eprescribing, it is acknowledged that the HSE Primary Care Reimbursement Service (PCRS) is a part of the overall system. There are an increasing number of HSE reimbursement schemes, some may come and go over time. The rules governing the reimbursement of prescriptions are complex and there is a fully functioning reimbursement system already in place. For audit purposes, it is a requirement for the PCRS to receive a copy of a prescription where items are subject to State reimbursement. In lieu of a paper copy, the PCRS will require sight of the electronic prescription for each item subject to State reimbursement. This section describes a proposed solution that is scheme-agnostic and meets the necessary PCRS-audit requirement; it also means the system can be used for private scripts without much complication. 3.1 Proposed Solution 3.1.1 Prescribing Software As per HIQA e Dataset and Clinical Document Architecture Standard March 2015 vi, each e generated and sent to the Secure Clinical Data Repository (SCDR) will contain, inter alia: Script ID ( identification: unique number which identifies the prescription) Line Item # ( item identification: unique number which identifies the prescription item) 3.1.2 Dispensing Software For each item dispensed, the dispensary software will record the: Script ID Line Item # The above two items will be included in the pharmacy electronic claim file, currently sent to the PCRS on a monthly basis. Access to the SCDR will be controlled and audited by Healthlink. Using the Pharmacy Contract Number, Script ID and Line Item #, the PCRS will be able to query the SCDR for audit purposes; however, the PCRS will be unable to query for items that are not in a pharmacy claim file i.e. not reimbursed by the State. This will protect the patient sensitive data in private prescriptions and allow for an eprescribing system that is clinically driven as opposed to being designed around complex reimbursement rules. Important note: It will be possible to mark a Line Item as Did Not Dispense : a professional judgement made by the pharmacist, a comment may be added for audit purposes.

4 Non-Technical Requirements 4.1 Governance A National eprescribing Steering Group is necessary. Establishing a steering group and developing a design proposal for eprescribing in Primary Care will put in place the necessary groundwork for a national solution which will be a priority deliverable for the HSE. 4.1.1 Governance board The Primary Care eprescribing Steering Group (PCeSG) should include delegates from the following: ehealth Ireland as the over-arching project governors Healthlink as the National message broker service IPU representing community pharmacy GPIT representing General Practitioners Patient HSE PCRS as business stakeholders HPRA the medicines regulator HIQA 4.1.2 Governance constitution The PCeSG will ensure that the Primary Care eprescribing Solution proposal will appropriately represent the breadth and depth of all of the Primary Care prescribing requirements and will focus on enabling the strategic services necessary to deliver on the proposal. The resulting Primary Care eprescribing System Specification will be a standard in its own right and made publically available for any system vendor to develop an eprescribing solution with access to the Healthlink brokering system. Using the published standards from HIQA, the group will design a detailed System Specification framed around a Healthlink infrastructure (and the coding standards and requirements associated with to interface with Healthlink). 4.1.3 Information governance The PCeSG will agree the provisions necessary to ensure data is: Held securely and confidentially Obtained fairly and lawfully Recorded accurately and reliably Used effectively and ethically Shared appropriately and legally Compliant with data protection regulations

4.2 Legislative issues e legislation e transmission legislation National product catalogue regulations IHI access & access to demographic information Electronic signature Controlled drugs GDPR Misuse of Drugs Regulations Medicinal Products ( and Control of Supply) Regulations

5 Technical Requirements 5.1 Interoperability Legal interoperability to ensure seamless exchange Semantic interoperability Technical 5.2 Performance Efficient inter-system communication 5.3 Security Encryption Authentication Non-repudiation Record integrity Legal sufficiency Signature verification Confidentiality Access control

6 IT Vendor Engagement All system-to-system communication for PCePS will be implemented using messaging. Full technical details will be described in the Primary Care eprescribing System Technical Specification. The specification will be publically available to all IT system vendors.

7 Use Case Analysis The IPU has worked with Blue Wave Informatics for a number of years and has commissioned the company to provide analysis and guidance in delivering a Primary Care eprescribing System for Ireland. 7.1 Blue Wave Informatics Blue Wave Informatics is a limited liability partnership providing consultancy and training in healthcare informatics. Blue Wave specialises in Medicines Information, and its various clinical applications, including Prescribing, Dispensing and Drug Administration and the Decision Support and Medication Databases needed to make these effective. In the UK, Blue Wave has a track record of activity in the development of medications databases for both primary and secondary care through the UK Clinical Products Reference Source (UKCPRS). The consultancy company has also been involved in development of ETP (Electronic Transfer of s) messages for the NHS National Programme for IT (NPfIT). Internationally Blue Wave is active in HL7, especially in the Pharmacy Special Interest Group. 7.2 Analysis Technique The analysis technique is to begin with a Storyboard a real world description of one or more events that illustrate how the system is expected to work. Within this it is possible to identify the specific messaging Use Cases and the Data Models that represent the information to be conveyed within the message. As more Storyboards are developed the Use Cases identified will tend to be similar or identical to ones that have already been developed and over the course of the analysis the set of Use Cases are developed that are the minimal set required. The Data Models can be adjusted to account for small differences and also structured so that elements occurring in more than one Use Case are represented by a single Data Model. The Use Cases can then be implemented by various different HL7 methods. V2, CDA and FHIR are the ones to be considered. The analysis below has looked at a Simple and a Private with Multiple dispenses as representative of the spread of complexity that can be expected. The other storyboards identified by the IPU should also be done, but time pressures have prevented this to date. There are 8 uses cases that have been identified from these two Storyboards: Use Case: Dispense Details Use Case: Acknowledgement Use Case: Details Use Case: Rejection Use Case: Request Use Case: Send to Hub Use Case: Token Details Use Case: Token Request

7.3 Storyboard: Simple Key: Use cases in document System functionality Uncertain functionality Patient Mary Murphy, 17 Mount Pleasant, Ballyraggett, Tralee, Co Kerry, V93 G6G7, dob 17/3/1930 GMS Number OH543212A which is also her HiTech number, LTI Number: 445566, IHI?? She is diabetic. Doctor John O Sullivan, Mount Brandon Medical Centre, Blennerville, Tralee, Co Kerry, V92 Y1T2 Medical Council Number: 987654, GMS Panel Number: 23456 Pharmacy The Medical Hall, Ballyraggett, Tralee V93 R6Q2 GMS Contract number 44455, PSI registration number 7654 Pharmacist Harry O Hare, PSI number 23456 Story Mary calls the prescription line, a dedicated phone line with a telephone answering system. She orders her prescription, specifying her name, address, DOB. She then is guided through the menu, specifying each medicine, asking for three months supply. The medicines ordered are: aspirin 75mg x28, atorvastatin 10mg x28, metformin 500mg x56, amlodipine 5mg x28, furosemide 20mg x28, bispoprolol 1.25mg x28 and anagrelide 500mg x112. The recorded message advises her to allow two days before collection. The prescription line messages are reviewed by the practice secretary. She pulls up Mary s file, using the DOB as key, and confirms she has the corresponding patient. She then compares Mary s requested items to see if they are on the repeat medicines schedule. All the requested items are flagged as routine, with a review date in three months, so the secretary proceeds to print three prescriptions, each for 28 days supply and each dated consecutively at 28 day intervals. In parallel, a temporary electronic prescription, corresponding to the printed version, is generated and stored for review by Dr John. Three separate unique codes are generated, one for each printed form. These are encoded as a 2D barcode on each printed prescription, that contains a pointer and authorisation to access, to each prescription. When time permits, Dr John reviews the prescription and patient file, and signs the three prescription forms. He then flags the prescriptions as approved on the computer system and electronically signs them. This marks them as completed, posts them to the patient record and sends the es to the hub [Use Case: Send to Hub]. The hub validates/acknowledges [Use Case: Acknowledgement]. It (doctor or hub) may

also securely send the unique 2d code to a patient s mobile device or email [Use Case: not represented]. Mary collects the prescriptions, travels to the pharmacy, and hands them to the prescription receptionist. Mary s contact details are confirmed, allergies noted and special instructions recorded. In this case Mary tells the receptionist that she has enough of the atorvastatin and does not need them this month. The prescription is then placed in a work tray with the receptionist notes. The pharmacy technician, logs into the PMR and scans the prescription barcode. This code is transmitted to the hub [Use Case: Request]. The hub validates the request, enforcing permissions, validating that each item on the prescription is still authorised (has not been cancelled, previously dispensed or currently locked by another pharmacy). Assuming all is OK, the prescription details are returned to the pharmacy [Use Case: Details]. The hub marks the prescription record with the datetime of retrieval and the details of the pharmacy and locks the record. In the pharmacy the e arrives for initial processing. Initially it must be assigned to the correct patient. Using the GMS number, or IHI, the PMR selects the correct patient. If the patient cannot be found, the technician is offered the facility to link the details to an existing patient or to create a new record using the prescription demographic details. In this case, the patient already exists on the PMR, so the technician selects the correct patient and loads the prescription for review. This may require pharmacist Harry to assess for any issues. In this case, Harry notes that this is the second time in four months that the patient, Mary, has declined the atorvastatin. He flags this for review, placing a note on the PMR and an alert on the bag label. For each item he ensures that the correct PCRS scheme is allocated. Some medicines are allowed on the LTI scheme, which means that Mary will avoid paying the prescription levy. The anagrelide is a High Tech drug, so Harry must confirm that the appropriate High Tech prescription is on file and in date. High Tech drugs must be initiated by, and reviewed by, specialist consultants. Once the pharmacist is satisfied, he commits the prescription to the medication record and prints labels and various UCF receipts. A dispense record is sent back to the hub [Use Case: Dispense Details] enclosing the date of preparation, which is assumed to be the date of dispensing, and the quantities of each item dispensed. The hub updates each item as fully dispensed, with the exception of the atorvastatin, which has yet to be dispensed. The dispensed item is locked and not available for further dispensing. Once the items are assembled, labelled and checked, they are bagged and associated with the various forms that need to be signed. There is a High Tech receipt for anagrelide and an LTI receipt for the rest. When Mary returns to collect the prescription, she signs the relevant UCFs. The technician notes the alert on the bag and the pharmacist, Harry, talks to the patient Mary about any issues she may be experiencing with her atorvastatin. Mary admits that she has been

reading stories on the internet about statins and is reluctant to take them. Harry discusses the concerns and reassures Mary. She then decides that she will take them. As she still has some left, she will only require 14 tablets. Harry then scans the code on the prescription form and sends a request to the hub [Use Case: Request]. The hub sends back the valid balance of the prescription [Use Case: Details], atorvastatin 10m x 28. The pharmacy dispenses as before and sends back, to the hub, a dispensing record for 14 atorvastatin 10mg [Use Case: Dispense Details]. The hub updates the item to 14 dispensed, 14 remaining to be dispensed.

Dynamic Model Prescriber Hub Patient Pharmacist Start Write Hand over prescription Token Receive Send Send to Hub Message «flow» Receive Validate AUthenticity Present Token to Pharmacy Details Message Acknowledgement Dispense Details Receive Acknowledgement Send Acknowledgement «flow» Acknowledgement Rejection Request Finish Receive Request Request «flow» Request Details Acknowledgement Request Retrieve Check Details Send Details «flow» Receive Assess Dispenses Dispense Details Recieve Dispense Details Dispense Details «flow» Send Dispense Details Save dispense details Finish Finish Rejection Send Invalid Rejection «flow» Receive Rejection Finish Finish

Storyboard: Private Prescriber Hub Patient Pharmacist in Pharmacy A Pharmacist in Pharmacy B Start Write Hand over prescription Private Receive Finish Present to Pharmacy Request 1 month supply Yaz and Beclazone Check for Token Private Message Details Message No token Enter Details Dispense Details Receive Request Token Request Token Request «flow» Request Token Retrieve by Details Acknowledgement Request Rejection Token Request Token Details Not Found Found Retreive token Validate AUthenticity Create token Send Token Token Details Token Details «flow» Receive Token Receive Token Token Hand over token Receive Request Request Request «flow» has token Request Details Check Retrieve Details Send Details «flow» Receive Assess Dispenses Recieve Dispense Details Dispense Details Dispense Details «flow» Send Dispense Details Save dispense details Finish Update Dispense Balance Send Invalid Finish Rejection Rejection «flow» Receive Rejection Finish Present token to Pharmacy Request 1 month supply Yaz only Finish Request Receive Request Request «flow» Request Details Retrieve Check Send Details Details «flow» Receive Assess Record Previous Dispense Dispenses Recieve Dispense Details Dispense Details Dispense Details «flow» Send Dispense Details Save dispense details Update Dispense Balance Finish Finish Send Invalid Rejection Rejection «flow» Receive Rejection Finish Finish

Use case: Send to Hub Send to Hub UseCase Prescriber «Provider» As a: Prescriber I want to: send details of a prescription to the hub So that: the prescription will be available for dispensing (anything else) «Consumer» Hub Message The message content conveyed is a Message and the below data model is used as a representation of this. Data Model: Message class IPU Data Model Ingredients Ingredient name Strength Posology Conditionality Start date Dose Route of administratuion Frequency Duration End date Indications Indication name 0..* 1..* 0..* 1 1 1 item Identifier Descri[ption Strength Extemperaneous Quantity to supply Quantity type Prescriber Prescriber ID Full Name Address Contact Information Qualification Statutory number 1 1..* 1..* 1 0..* 1 1 0..* Repeats 1 Total quantity Conditionality Frequency Duration Number of repeats 0..* 0..* 1 Location Location ID Other 1 Patient Patient ID Full Name Full Address Contact Information Sex DOB Weight Height Allergy Information Condition Information Scheme Eligibility 1 Authentication Id Type Date stamp Security data Signature 1..* 1..* Carer Demographics 0..1 0..1 Guardian Demographics

7.4 Implementation: HL7 V2 V2 is a standard based on exchange of messages via TCP/IP or other forms of file transfer. The content is then processed into useable content according to a specific syntax. V2 content is not easily human readable - while this is not important in production it makes development a more opaque process. The use of a custom syntax makes message content quite dense and therefor efficient in bandwidth terms. V2 implementations are custom implementations - there has to be a body that states exactly how a given V2 message is to be interpreted - there are no real "standard" blocks that can be used repeatedly. 7.5 Implementation: CDA CDA is a very constrained part of the V3 standard that is based on Document Exchange as its working model. The standard specifies how the document is to be described (title, author etc.) but the content can be provided as plain text. However, the C-CDA extension specifies templates that then further divide the content of the document into specific elements thus avoiding the reliance on text. The virtue of CDA is the conceptual simplicity but like V2 it is heavily dependent on implementation guides to make it work. HIQA has specified a dispensing note (see: National Standard for a Dispensing Note including a ClinicalDocument Architecture specification) and this draws heavily on the work done in the EPSOS project for example, section 11 page 40 onwards here: D3.9.1_Appendix_B1_B2_Implementation_v1.4_20110725.pdf. This same EPSOS specification describes the e structure in the same way. Of necessity it repeats many of the elements and if CDA is the implementation chosen it would be appropriate to draw from the same source. 7.6 Implementation: FHIR FHIR specifies a significant number of small models (resources) that represent common concepts such as Patient, Medication Order etc. It also offers a range of implementation technologies, but particularly uses the service based RESTful protocol. The existence of small resources allows a significant degree of standardised processing and profiles and extensions can then be specified to allow local requirements to be catered for. FHIR has captured the imagination of implementers and has more momentum behind it than any of the other HL7 standards have ever done. There is very high quality documentation and also freely available test servers that make development more rapid than any of the other standards. In FHIR the Message is a Medication request within a Task. Details for the Patient, Medication and Prescriber are separate resources and the structure is shown in the drawings in the Appendix. These resources offer more than is required and it is easier to present the structure as an example. FHIR content can be formatted as XML or JSON but for illustration it is easier to use a simple tree representation for the Medication Request. The details for the Patient, Medication and Prescriber are not presented here but would follow a similar pattern.

1 General identification of the request type - this is for version management and provision of internal identifiers 2 This is the publically visible value for the identifier and its status 3 This request refers to one item with two ways in which it is identified (coded) The first is based on the RXNORM code, the second on the NDC code 4 This provides a reference for the patient. The details for the patient are represented as a separate resource which can be batched to be sent as part of the same message. 5 Date the prescription was written 6 Identification of the individual who wrote the prescription - the details are represented as a separate resource which can be batched to be sent as part of the same message.

7 Dosage instructions The route is provided as a coded item that has the display name "Oral" 8 Number of repeats

7.7 Appendix FHIR Resource Drawings Medication Request Patient

Medication Practitioner