Pharmacy – Requirements, Standards, Architecture & Implementation

1. Pharmacy – Requirements, Standards, Architecture & Implementation Michael van Campen, Jean Duteau HL7 New Zealand Conference, November 2, 2010

2. Acknowledgements Hugh Glover, Blue Wave Informatics UK experience Tom de Jong, NICTIZ Netherlands experience Canada Health Infoway Canadian experience Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 2

3. Michael van Campen Has been involved in the HL7 organization for 15+ years (internationally and in Canada) Affiliate Director on the HL7 Board of Directors HL7 Canada Chair Involved in many HL7 activities in Canada and abroad Most importantly... Opinions expressed today are solely my own They may be shared by others... Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 3

4. Jean Duteau Has been involved with HL7 implementations since 2000, both v2.4/2.5 and v3 Worked with Canada Health Infoway as a Standards Subject Matter Expert (SME) and a Jurisdictional SME Current Modeling facilitator for Pharmacy, Past Publishing facilitator for Patient Care Co-chair of Modeling & Methodology, Implementable Technology Specifications, and Tooling workgroups Currently involved in HL7 activities in Canada, United States, and Europe Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 4

7. Major Pharmacy Functions Prescription management Script definition (what is an Rx?) Create, stop, suspend, resume scripts Dispense management Administration (institutional) Drug interaction checking Adverse events Medication history (for a patient) Health System Use or secondary use Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 7

8. Pharmacy Defined - Not For our discussion today, we do not include: Drug safety Structured product labelling Automated Pharmacy dispensers (robots) Pharmacovigilance Drug development, testing and recalls Pharmacy claims & claims management Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 8

10. Pharmacy Workgroup Handles two domains: Medications – representing Medication in a clear and unambiguous way Pharmacy – describing processes related to medications Making of a prescription or a medication order Organizing of a supply of a medication Administration of the medication to a patient Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 10

11. Medication Model Clinical information about the product Identifiers and codes (NDC, GTIN, etc.) Form and Strength information Ingredients, Moieties, and Packaging Approval and Policy information Over-the-counter vs prescribed Product Approval guidelines Territorial and organization-specific guidelines Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 11

12. Pharmacy Topics Prescription Ordering Create Discontinue/Reactivate Hold/Release Medication Dispense Broken into the processing of a dispense and the actual pickup by the patient Includes Refusal To Fill and Pharmacy Transfers Medication Administration Currently focused on medication statements Starting to include institutional use cases around administrations Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 12

13. Messages vs. Documents vs. Services The focus has been on pharmacy messages All of the content has been creating interactions Various projects are using the information models as underpinnings for service operations Documents are another story… Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 13

14. Document Metaphor Clinical Document have the following characteristics: Persistence Stewardship Potential for authentication Context Wholeness Human readability Clinical documents are not: data fragments, unless signed birth-to-death aggregate records electronic health records Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 14

15. Pharmacy in Documents CDA R2 uses the “Clinical Statement” pattern Substance Administrations, Supplies, and Medications are represented differently in the CDA model than in the messaging models CDA R3 is a new project that is trying to minimize those differences by using the models that workgroups are creating This will effectively remove all differences in content between messages, services, and documents Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 15

16. Interactions/Services vs. Documents Creating a system that sends and receives Pharmacy information via Clinical Documents can provide a low barrier to the exchange of information Workflow can not be adequately expressed using documents I can send the prescription that was ordered or the dispense that was processed I can not send a document indicating that a prescription should be put on hold Once I have a system that is receiving and parsing information out of a clinical document, it is another small step to introduce the workflow pieces via messaging or services Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 16

19. Architectural Approaches Many different approaches are in place Institutional Community National Each has pros/cons and is very much business driven Here we introduce 3 sample architectures & some variants More exist! Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 19

21. Arch 1: Institutional Primarily used with an order entry system within an institution Aids in Rx workflow All medication information for the patient is retained in the Pharmacy system Central control Variant 1: Integrated Systems are connected to one another Variant 2: Integration Broker OE, Rx & admin systems may not be compatible Integration brokers may be inserted between systems Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 21 Order Entry Orders, Queries druginteractionchecking Pharmacy Integrationbrokers Variation Admin requests Nursing Admin Pyxis Robot

22. Arch 2: Point to Point Prescriber systems are directly connected to Rx systems No centralized repository of medications Variation 1: Point to Point Variation 2: P2P with Central Index Aids in the location of records Connection points are additive Connect #3 to #2 Connect #1 to #4, #3 to #4 Etc. Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 22 druginteractionchecking druginteractionchecking Prescriber IndexQueries 3 1 Prescriber Orders Orders Central Index Variation druginteractionchecking druginteractionchecking Pharmacy IndexQueries Pharmacy 4 2

23. Arch 3: Central Hub/Repository Central system manages communications between systems Variation 1 – Store & Forward Simple router No consolidated medication record Prescriptions are managed at the Pharmacy once dispensed Variation 2 – Passive Repository Prescriptions and dispenses stored on the repository for a full medication record No drug interaction checking at the repository Variation 3 – Active Repository Seen as authority for electronic prescription Adds drug interaction checking at repository Adds active management of identifiers Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 23 druginteractionchecking druginteractionchecking Prescriber Prescriber OrdersQueries OrdersQueries druginteractionchecking Variation Central Hub/Repository Medicat’nRecord Variation DispensesQueries DispensesQueries druginteractionchecking druginteractionchecking Pharmacy Pharmacy

24. Architectures in Contrast Each of the previous architectures have intrinsic benefits And costs to implement! Contrast architectures along the following dimensions: Patient’s Comprehensive Medication Record Identifier Management Drug Interaction Checking Prescribing Workflow Dispensing Workflow Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 24

26. Input of community medications may be a feature

28. A Central Index will assist in assembling the complete record

29. A comprehensive record does not exist in 1 location

31. For other variations, central source of this information

32. For variation 1, no support for full medication record

34. Target systems create identifiers, swapped during exchanges of orders/admin instructions

36. Target systems create identifiers, swapped during exchanges of orders/admin instructions

38. Identifiers can be created by repository (Active Repository), and only once the object is “valid” (e.g. prescription)

40. Drug interaction checking is performed by the Pharmacy system

41. Drug interaction checking is limited to orders dispensed by the Pharmacy system

43. Drug interaction checking is limited to data at each system

45. For Active Repository systems, performed by the central repository

46. Management of same contraindications may be duplicated

48. Closed loop system suggests simple workflow

50. No central (singular) location for complete medication record

52. For other variants, prescription remains on repository (as well as dispense events)

53. For Store & Forward variant, no central (singular) location for complete medication record

56. No central (singular) location for complete medication record

58. For other variants, dispense events sent to repository to create full medication record

59. For Store & Forward variant, no central (singular) location for complete medication record

62. Large Country, Small Population 2nd largest country 32.6 million people -- 3.3/km2 -- among lowest density in world Population concentrated in 4 broad areas: “Golden Horseshoe”, Ontario (Toronto, Ottawa) Montreal, Quebec Lower Mainland (Vancouver and surroundings), British Columbia Calgary-Edmonton, Alberta Ethnically diverse 46% British Isles/French 19% other European 13% non European (esp. Chinese & East Indian) 22% mixed ethnic heritage Image Source: Canadian Tourism Commission Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 32

63. Health Care in Canada CDN$142 Billion business 60% of cost for hospitals,drugs and physicians A system that is substantially publiclyfunded (70%) 38% of provincial budgets are devoted to healthcare expenditures (average) Source: http://www.oecd.org/dataoecd/19/13/36956887.pdf Source: Canada Health Infoway Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 33

64. Infoway Programs $500 million added in 2009, with the major portionto aid EMR adoption by Physicians - the last mile! Source: Canada Health Infoway Oct 28, 2010 © 2010, Gordon Point Informatics Ltd. 34

65. Infoway Drug Systems Strategy Program Funding: $185M (Generation-3) 75:25 Funding Solution Objectives Comprehensive collection of All People All Drugs (ADAP) Patient’s Medication Profile (MP) is viewable electronically by the physicianand pharmacist (Portal or Message-based) Physician can generate and send a patient’s Rx electronically Pharmacist can view the order online and to fill the prescription Automatic notification to the attendingphysician and pharmacist of Adverse Drug Events (ADE) Expected Results $613M annual savings, Canada wide,avoiding adverse drug reactions and drug compliance issues Source: Canada Health Infoway Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 35

67. Alert notification (e.g. duplicate tests, drug interaction)

68. Provisioning of Clinical Practice Guidelines

69. Patient demographics

70. Provider demographics

72. Dispensed medications

74. Drug Program Investment Strategy Support Drug Information System (DIS) solutions: Generation 3 Drug Information Systems that will: Capture data on All Drugs for All People Support viewing of drug profiles, as well as ePrescribing Generation 2 systems as a stepping stone to a Gen-3 Support the establishment of replicable COTS (“Commercial Off-The-Shelf”) Solutions (e.g., NL Procurement) Invest in HL7v3 pan-Canadian message standard (i,e., CeRx, NeCST) Engage with key stakeholders to foster engagement/adoption. Excludes funding for Drug Claims Processing system components Source: Canada Health Infoway Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 37

75. Clinical Drug Information Systems Provider Access Clinical Management Claims Administration Client Client Registry Registry Network Client Client Domain Repository (Pharmacy) Provider Client Registry Registry Registry Registry Public and Private Claims Adjudication and Administration Pharmacy System Pharmacy Access Dispensing Support Dispensing Message EMR MD Access Claims Message Prescribing Message Prescribing Support Prescribing Support CIS Hospital Access Existing Systems Pharmacy/MD/ Hospital Access Clinical Viewer Existing Messages New Messages Source: Canada Health Infoway Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 38

76. Adoption will be key to success… Drug Information System is highly dependent on collaboration with... Private sector stakeholders - i.e. retail pharmacies (Rx) - to implement core parts of the technology solution Professional colleges - i.e. colleges of pharmacists and physicians - to support changed professional roles and work processes Ministries of Health - to align with their drug benefit systems Standards Projects - National electronic Claims Standard (NeCST) and Clinical Message development (CeRx) Pan-Canadian deployment is highly dependent on supporting provinces to evolve their pharmacy networks Deployment of Gen 3 Drug is highly dependent on physician connectivity and adoption. Source: Canada Health Infoway Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 39

77. Current Status Pharmacy dispensing Newfoundland, PEI, Alberta, Saskatchewan, Quebec HL7 v2-like system in BC for 15 years (PharmaNet) Project underway in Ontario to address ePrescribing (& eDispensing) Claims support for BC, Newfoundland & PEI Source: Canada Health Infoway Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 40

79. Population: 16 million Capital: Amsterdam Hospitals: about 100 General Practitioners: 8000 Community Pharmacies: 1700 Some Background on the Netherlands… Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 42

80. Current Challenges in Dutch Healthcare Increased demand; shortage in budget and staff, leafs to long waitlists for care Restructuring of healthcare financing Shift from intra-institutional to trans-institutional cooperation and a resulting need to share information throughout the ‘chain of care’ Very little central coordination in the application of technology standards Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 43

81. Can IT solve all this? Definitely not, but it’s an important instrument To create more efficiency (and thus reduce cost) But also to increase quality (and thus save lives) In the medication domain alone, estimates are: € 300 million worth of preventable cost > 90.000 preventable admission days due to medication-related errors in the Netherlands… Not all of these errors can be prevented by IT, but accurate, up-to-date, shared information throughout the chain of care is essential Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 44

82. 45 CHI DIS Workshop Toronto, January 17/18 2006

83. 46 CHI DIS Workshop Toronto, January 17/18 2006

84. Current situation: Regional Care Networks Intra-institutional prescriptions, but almost no trans-institutional interfaces (either to other hospitals or to primary care) Hospital Hospital General Practitioners Community Pharmacies HL7 v2 interfaces HL7 v2 interfaces OZIS server(Master Patient Index) Patient Data (LDAP) Medication Data (EDIFACT) E-Prescriptions (EDIFACT) Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 47

85. Problems with Current Situation No shared patient ID Fixed! No common authorization scheme (security) Vendor-based, no stakeholder participation Proprietary EDIFACT data exchange standard Based on SMTP (e-mail): relatively slow Many-to-many connections  high set-up & maintenance costs; high error rate; complex No international harmonization & cooperation Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 48

87. Solution: achieve high connectivity in at least one region early in the process

89. NICTIZ National Information & Communication Technology Institute for Healthcare Not-for-profit organisation Founded by healthcare stakeholders: Ministry of Healthcare Organisation of HC Providers Organisation of IT Vendors in HC Dutch HC Insurers Organisation Patient representation groups Funding by Ministry of Health (for a 5-year ‘trial’ period) Based on cooperation with ‘the marketplace’ but without a legal mandate to enforce solutions Very similiar to Canada Health Infoway, but with a much lower budget Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 50

90. Nationwide Switching Point Well Managed Care System (GBZ) Well Managed Care System (GBZ) Well Managed Care System (GBZ) Well Managed Care System (GBZ) Well Managed Care System (GBZ) Nationwide Switching Point (LSP) Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 51

91. Well Managed Care System Set of requirements for systems that want to attach to the national infrastructure Non-stop dependable operation & access Safe storage and repeatable query results Retrievable audit trail, logging of all access Guaranteed ‘semantic interoperability’ A well managed care system (GBZ in Dutch) can be both a single system or a set of systems that act as a single entity Describes behavior, not technology Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 52

92. Hierarchy of Care Information Brokers Nationwide Switching Point (LSP) Regional level Well Managed Care System (GBZ) SubsystemPharmacy 1 HL7 version 3 SubsystemPharmacy 2 Local Care Information Broker (ZIM) proprietary standards SubsystemPharmacy 3 National level SubsystemPharmacy 4 Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 53

93. Status update 2009 Nationwide Switching Point (LSP) is operational, acting as the national Care Information Broker Big delays because of original method for secure transmission  move to token authentication National Patient ID and Provider ID have been implemented in care provider organizations Increasing number of software vendors are ready to update and access the LSP with their software NICTIZ runs qualification tests for ‘well managed care systems’ (procedural and technical criteria) Source: NICTIZ Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 54

95. Architechture – ETP Focussed Reimbursement Agency MQ NCRS SPINE SDS LRS CSA ETP PSIS SSB PDS TMS N3 LSP Prescribing System (ESP) Prescribing System (LSP) Dispensing System (ESP) Source: NHS/Blue Wave Informatics Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 56

96. Scale – Some Stats 650 million prescriptions 5 interactions per prescription (minimum) 3250 million per year 300 working days per year 10 million interactions per day 6 hours account for most of flow (guess) Peak 1.7 million per hour (peak) 300 000 per minute (peak) 50 000 per second (peak) @ 10 k bytes per interaction, 500 Mb per second (peak) Source: NHS/Blue Wave Informatics Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 57

97. UK Architecture All messages are stored and returned as Clinical Statements Only message fragments are stored – the contents are not parsed out Local databases arenot considered Source: NHS/Blue Wave Informatics Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 58

98. Why Does UK Use This Architecture? High throughput is required and hence minimal processing Parsing out messages is costly and should be minimised A common pattern for all stored messages makes for more efficient processing Common patterns impose structures on message designs High throughput message design is NOT independent of the architecture Source: NHS/Blue Wave Informatics Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 59

100. epSOS – a European eHealth Project epSOS is the first European eHealth project connecting counties Look to support the following use cases for pharmacy: A patient needs medicine that is already prescribed in the home country when in another country. In this case the pharmacist should be able to electronically access the prescription from the same interface used for prescriptions ordered in the local country A medical professional decides to prescribe medicine to a visiting patient from another country. To assist the medical professional to make the best decision on the pharmaceutical strategy to be used, the patient's medical and pharmaceutical history from her home country will be available through the patient summary Technical approach Use the CDA (document) standard for providing information on current prescriptions (not medication history) Nov 2, 2010 © 2010, Gordon Point Informatics Ltd. 61 Source: www.epsos.eu

103. March 3, 2010 © 2010, Gordon Point Informatics Ltd. 64 Thanks! Michael van Campen Gordon Point Informatics Ltd. Michael.vancampen@gpinformatics.com Jean Duteau Gordon Point Informatics Ltd. Jean.duteau@gpinformatics.com gpi

Pharmacy – Requirements, Standards, Architecture & Implementation

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Pharmacy – Requirements, Standards, Architecture & Implementation

Ähnlich wie Pharmacy – Requirements, Standards, Architecture & Implementation (20)

Mehr von Health Informatics New Zealand

Mehr von Health Informatics New Zealand (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Pharmacy – Requirements, Standards, Architecture & Implementation

Hinweis der Redaktion