Pharmacy – Requirements, Standards, Architecture & Implementation

4,135 views

Published on

Michael van Campen
Affiliate Director, HL7 Board of Directors and Chair, HL7 Canada

Jean Duteau
Modeling facilitator for HL7 Pharmacy

(2/11/10, Workshop 2, 12.30)

Published in: Health & Medicine, Business
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,135
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
0
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide
  • Michael this is an old “official” view of the UK architecture from about 2005. Thinking about it I’m not sure even now I can legally share this with you!
  • Michael – These are some extrapolations that I did in about 2005 using figures from a year or two earlier. The figures assume that all prescriptions went through ETP. In practice I’ve never yet seen one in the flesh!
  • Pharmacy – Requirements, Standards, Architecture & Implementation

    1. 1. Pharmacy – Requirements, Standards, Architecture & Implementation<br />Michael van Campen, Jean Duteau<br />HL7 New Zealand Conference, November 2, 2010<br />
    2. 2. Acknowledgements<br />Hugh Glover, Blue Wave Informatics<br />UK experience<br />Tom de Jong, NICTIZ<br />Netherlands experience<br />Canada Health Infoway<br />Canadian experience<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />2<br />
    3. 3. Michael van Campen<br />Has been involved in the HL7 organization for 15+ years (internationally and in Canada)<br />Affiliate Director on the HL7 Board of Directors<br />HL7 Canada Chair<br />Involved in many HL7 activities in Canada and abroad<br />Most importantly...<br />Opinions expressed today are solely my own<br />They may be shared by others...<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />3<br />
    4. 4. Jean Duteau<br />Has been involved with HL7 implementations since 2000, both v2.4/2.5 and v3<br />Worked with Canada Health Infoway as a Standards Subject Matter Expert (SME) and a Jurisdictional SME<br />Current Modeling facilitator for Pharmacy, Past Publishing facilitator for Patient Care<br />Co-chair of Modeling & Methodology, Implementable Technology Specifications, and Tooling workgroups<br />Currently involved in HL7 activities in Canada, United States, and Europe<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />4<br />
    5. 5. Outline<br />Pharmacy Defined<br />Pharmacy at HL7<br />Pharmacy ArchitecturalApproaches<br />Implementations Aroundthe World<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />5<br />
    6. 6. Pharmacy Defined<br /><ul><li>What it is, what it isn’t (as it relates to this presentation)</li></ul>Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />6<br />
    7. 7. Major Pharmacy Functions<br />Prescription management<br />Script definition (what is an Rx?)<br />Create, stop, suspend, resume scripts<br />Dispense management<br />Administration (institutional)<br />Drug interaction checking<br />Adverse events<br />Medication history (for a patient)<br />Health System Use or secondary use<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />7<br />
    8. 8. Pharmacy Defined - Not<br />For our discussion today, we do not include:<br />Drug safety<br />Structured product labelling<br />Automated Pharmacy dispensers (robots)<br />Pharmacovigilance<br />Drug development, testing and recalls<br />Pharmacy claims & claims management<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />8<br />
    9. 9. Pharmacy at HL7<br />Content Review<br />Documents, Messages, Services<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />9<br />
    10. 10. Pharmacy Workgroup<br />Handles two domains:<br />Medications – representing Medication in a clear and unambiguous way<br />Pharmacy – describing processes related to medications<br />Making of a prescription or a medication order<br />Organizing of a supply of a medication<br />Administration of the medication to a patient<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />10<br />
    11. 11. Medication Model<br />Clinical information about the product<br />Identifiers and codes (NDC, GTIN, etc.)<br />Form and Strength information<br />Ingredients, Moieties, and Packaging<br />Approval and Policy information<br />Over-the-counter vs prescribed<br />Product Approval guidelines<br />Territorial and organization-specific guidelines<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />11<br />
    12. 12. Pharmacy Topics<br />Prescription Ordering<br />Create<br />Discontinue/Reactivate<br />Hold/Release<br />Medication Dispense<br />Broken into the processing of a dispense and the actual pickup by the patient<br />Includes Refusal To Fill and Pharmacy Transfers<br />Medication Administration<br />Currently focused on medication statements<br />Starting to include institutional use cases around administrations <br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />12<br />
    13. 13. Messages vs. Documents vs. Services<br />The focus has been on pharmacy messages<br />All of the content has been creating interactions<br />Various projects are using the information models as underpinnings for service operations<br />Documents are another story…<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />13<br />
    14. 14. Document Metaphor<br />Clinical Document have the following characteristics:<br />Persistence<br />Stewardship<br />Potential for authentication<br />Context<br />Wholeness<br />Human readability<br />Clinical documents are not:<br />data fragments, unless signed<br />birth-to-death aggregate records<br />electronic health records<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />14<br />
    15. 15. Pharmacy in Documents<br />CDA R2 uses the “Clinical Statement” pattern<br />Substance Administrations, Supplies, and Medications are represented differently in the CDA model than in the messaging models<br />CDA R3 is a new project that is trying to minimize those differences by using the models that workgroups are creating<br />This will effectively remove all differences in content between messages, services, and documents<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />15<br />
    16. 16. Interactions/Services vs. Documents<br />Creating a system that sends and receives Pharmacy information via Clinical Documents can provide a low barrier to the exchange of information<br />Workflow can not be adequately expressed using documents<br />I can send the prescription that was ordered or the dispense that was processed<br />I can not send a document indicating that a prescription should be put on hold<br />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<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />16<br />
    17. 17. Let’s not forget IHE<br />IHE are working on a pharmacy profile<br />Based on Pharmacy v3 messages but following the CDA paradigm<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />17<br />
    18. 18. Pharmacy Architectural Approaches<br />Many Different Approaches…<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />18<br />
    19. 19. Architectural Approaches<br />Many different approaches are in place<br />Institutional<br />Community<br />National<br />Each has pros/cons and is very much business driven<br />Here we introduce 3 sample architectures & some variants<br />More exist!<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />19<br />
    20. 20. But First, some of our words…<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />20<br />
    21. 21. Arch 1: Institutional<br />Primarily used with an order entry system within an institution<br />Aids in Rx workflow<br />All medication information for the patient is retained in the Pharmacy system<br />Central control<br />Variant 1: Integrated<br />Systems are connected to one another<br />Variant 2: Integration Broker<br />OE, Rx & admin systems may not be compatible<br />Integration brokers may be inserted between systems<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />21<br />Order Entry<br />Orders, Queries<br />druginteractionchecking<br />Pharmacy<br />Integrationbrokers<br />Variation<br />Admin requests<br />Nursing Admin<br />Pyxis Robot<br />
    22. 22. Arch 2: Point to Point<br />Prescriber systems are directly connected to Rx systems<br />No centralized repository of medications<br />Variation 1: Point to Point<br />Variation 2: P2P with Central Index<br />Aids in the location of records<br />Connection points are additive<br />Connect #3 to #2<br />Connect #1 to #4, #3 to #4<br />Etc.<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />22<br />druginteractionchecking<br />druginteractionchecking<br />Prescriber<br />IndexQueries<br />3<br />1<br />Prescriber<br />Orders<br />Orders<br />Central Index<br />Variation<br />druginteractionchecking<br />druginteractionchecking<br />Pharmacy<br />IndexQueries<br />Pharmacy<br />4<br />2<br />
    23. 23. Arch 3: Central Hub/Repository<br />Central system manages communications between systems<br />Variation 1 – Store & Forward<br />Simple router<br />No consolidated medication record<br />Prescriptions are managed at the Pharmacy once dispensed<br />Variation 2 – Passive Repository<br />Prescriptions and dispenses stored on the repository for a full medication record<br />No drug interaction checking at the repository<br />Variation 3 – Active Repository<br />Seen as authority for electronic prescription<br />Adds drug interaction checking at repository<br />Adds active management of identifiers<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />23<br />druginteractionchecking<br />druginteractionchecking<br />Prescriber<br />Prescriber<br />OrdersQueries<br />OrdersQueries<br />druginteractionchecking<br />Variation<br />Central Hub/Repository<br />Medicat’nRecord<br />Variation<br />DispensesQueries<br />DispensesQueries<br />druginteractionchecking<br />druginteractionchecking<br />Pharmacy<br />Pharmacy<br />
    24. 24. Architectures in Contrast<br />Each of the previous architectures have intrinsic benefits <br />And costs to implement!<br />Contrast architectures along the following dimensions:<br />Patient’s Comprehensive Medication Record<br />Identifier Management<br />Drug Interaction Checking<br />Prescribing Workflow<br />Dispensing Workflow<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />24<br />
    25. 25. Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />25<br />1. Patient’s Comprehensive Medication Record<br />The ability to create, manage and provide access to a patient’s comprehensive medication record. A complete and comprehensive medication records of orders, dispenses and administrations will provide for the most effective management of drug interaction checking (coupled with adverse event management and access to ancillary systems such as lab information systems).<br />How<br />Implications<br />Institutional<br />Variation 1: Integrated<br />Variation 2: Integration Broker<br /><ul><li>A complete medication record, as it pertains to the institutional setting, is maintained by the Pharmacy system
    26. 26. Input of community medications may be a feature
    27. 27. Full interaction checking with only those prescriptions that are part of the Pharmacy systems’ scope</li></ul>Point to Point<br />Variation 1: Point to Point<br />Variation 2: P2P with Central Index<br /><ul><li>Prescriptions, dispenses and administration events are not shared amongst systems
    28. 28. A Central Index will assist in assembling the complete record
    29. 29. A comprehensive record does not exist in 1 location
    30. 30. Queries to source systems must be undertaken to assemble the record, each time (for most up-to-date information)</li></ul>Central Hub/Repository<br />Variation 1: Store & Forward<br />Variation 2: Passive RepositoryVariation 3: Active Repository<br /><ul><li>For variation 1, prescriptions, dispenses and administration events are not shared among systems
    31. 31. For other variations, central source of this information
    32. 32. For variation 1, no support for full medication record
    33. 33. Central location for full record that can be used for comprehensive drug interaction checking</li></li></ul><li>Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />26<br />2. Identifier Management<br />To share prescriptions, dispenses and administration events effectively across organizations, an identifier strategy must be instituted. This includes, at a minimum, the use of universal identification schemes such as Object Identifiers (OIDs).<br />How<br />Implications<br />Institutional<br />Variation 1: Integrated<br />Variation 2: Integration Broker<br /><ul><li>Identifiers are created by source systems (e.g. Order Entry for orders, Pharmacy for admin instructions)
    34. 34. Target systems create identifiers, swapped during exchanges of orders/admin instructions
    35. 35. No central assignment of identifiers implies that there will be multiple identifiers for the same object (e.g. prescription), suggesting that systems need to track multiple identifiers for communications (e.g. queries)</li></ul>Point to Point<br />Variation 1: Point to Point<br />Variation 2: P2P with Central Index<br /><ul><li>Identifiers are created by source systems (e.g. Order Entry for orders, Pharmacy for admin instructions)
    36. 36. Target systems create identifiers, swapped during exchanges of orders/admin instructions
    37. 37. No central assignment of identifiers implies that there will be multiple identifiers for the same object (e.g. prescription), suggesting that systems need to track multiple identifiers for communications (e.g. queries)</li></ul>Central Hub/Repository<br />Variation 1: Store & Forward<br />Variation 2: Passive RepositoryVariation 3: Active Repository<br /><ul><li>See above for Store & Forward and Passive Repository variants
    38. 38. Identifiers can be created by repository (Active Repository), and only once the object is “valid” (e.g. prescription)
    39. 39. If identifiers managed by hub / repository, then only 1 identifier required per object</li></li></ul><li>Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />27<br />3. Drug Interaction Checking<br />The process of drug interaction checking is critical from a patient safety perspective. This checking can be performed at time of prescription and / or dispense, as well as the patient’s medication record (in whatever state it is in).<br />How<br />Implications<br />Institutional<br />Variation 1: Integrated<br />Variation 2: Integration Broker<br /><ul><li>Order entry systems typically do not have access to a patient’s medication record
    40. 40. Drug interaction checking is performed by the Pharmacy system
    41. 41. Drug interaction checking is limited to orders dispensed by the Pharmacy system
    42. 42. This can be augmented by access to an external medication record</li></ul>Point to Point<br />Variation 1: Point to Point<br />Variation 2: P2P with Central Index<br /><ul><li>Drug interaction checking is performed by source and target systems
    43. 43. Drug interaction checking is limited to data at each system
    44. 44. Management of same contraindications may be duplicated</li></ul>Central Hub/Repository<br />Variation 1: Store & Forward<br />Variation 2: Passive RepositoryVariation 3: Active Repository<br /><ul><li>For Store & Forward and Passive Repositories, performed by either source or target systems
    45. 45. For Active Repository systems, performed by the central repository
    46. 46. Management of same contraindications may be duplicated
    47. 47. Active Repository may remove requirement to perform drug interaction checking by prescribing and / or dispensing systems</li></li></ul><li>Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />28<br />4. Prescribing Workflow<br />The prescribing workflow commences with patient identification, selection of drug (at therapeutic or physical levels), verification of drug (i.e. drug interaction checking), transfer of prescription and querying for status of prescription.<br />How<br />Implications<br />Institutional<br />Variation 1: Integrated<br />Variation 2: Integration Broker<br /><ul><li>Managed by Order Entry system, with direct connection of Order Entry to Pharmacy system
    48. 48. Closed loop system suggests simple workflow
    49. 49. Order Entry will likely not have access to prescription status, for which the Pharmacy system must be queried</li></ul>Point to Point<br />Variation 1: Point to Point<br />Variation 2: P2P with Central Index<br /><ul><li>Prescribing system sends prescription to a targeted pharmacy (as there is no central repository to hold the prescription until dispensed)
    50. 50. No central (singular) location for complete medication record
    51. 51. Once prescription is sent to pharmacy, may not be able to access prescription history (e.g. dispenses)</li></ul>Central Hub/Repository<br />Variation 1: Store & Forward<br />Variation 2: Passive RepositoryVariation 3: Active Repository<br /><ul><li>For Store & Forward variant, Prescribing system sends prescription through the repository to a targeted pharmacy
    52. 52. For other variants, prescription remains on repository (as well as dispense events)
    53. 53. For Store & Forward variant, no central (singular) location for complete medication record
    54. 54. For other variants, complete medication record in one repository is possible</li></li></ul><li>Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />29<br />5. Dispensing Workflow<br />The dispensing workflow commences with receipt of a prescription (by the patient, directed by the prescriber), selection / confirmation of drug (at therapeutic or physical levels), verification of drug (i.e. drug interaction checking), dispense and pickup / delivery.<br />How<br />Implications<br />Institutional<br />Variation 1: Integrated<br />Variation 2: Integration Broker<br /><ul><li>Managed by Pharmacy system
    55. 55. Closed loop system suggests simple workflow</li></ul>Point to Point<br />Variation 1: Point to Point<br />Variation 2: P2P with Central Index<br /><ul><li>For Store & Forward variant, Dispensing system does not send dispenses to Prescribing system
    56. 56. No central (singular) location for complete medication record
    57. 57. Management of prescription is handed to Pharmacy as soon as it delivered / accepted</li></ul>Central Hub/Repository<br />Variation 1: Store & Forward<br />Variation 2: Passive RepositoryVariation 3: Active Repository<br /><ul><li>For Store & Forward variant, Dispensing system does not send dispenses to Prescribing system
    58. 58. For other variants, dispense events sent to repository to create full medication record
    59. 59. For Store & Forward variant, no central (singular) location for complete medication record
    60. 60. For other variants, complete medication record in one repository is possible</li></li></ul><li>Implementations Around the World<br />Netherlands, Canada, United Kingdom, epSOS (Europe)<br />Others…<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />30<br />
    61. 61. Canada<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />31<br />
    62. 62. Large Country, Small Population<br />2nd largest country<br />32.6 million people -- 3.3/km2 -- among lowest density in world<br />Population concentrated in 4 broad areas:<br />“Golden Horseshoe”, Ontario (Toronto, Ottawa)<br />Montreal, Quebec<br />Lower Mainland (Vancouver and surroundings), British Columbia<br />Calgary-Edmonton, Alberta<br />Ethnically diverse <br />46% British Isles/French<br />19% other European<br />13% non European (esp. Chinese & East Indian)<br />22% mixed ethnic heritage<br />Image Source: Canadian Tourism Commission<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />32<br />
    63. 63. Health Care in Canada<br />CDN$142 Billion business<br />60% of cost for hospitals,drugs and physicians<br />A system that is substantially publiclyfunded (70%)<br />38% of provincial budgets are devoted to healthcare expenditures (average)<br />Source: http://www.oecd.org/dataoecd/19/13/36956887.pdf<br />Source: Canada Health Infoway<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />33<br />
    64. 64. Infoway Programs<br />$500 million added in 2009, with the major portionto aid EMR adoption by Physicians - the last mile!<br />Source: Canada Health Infoway<br />Oct 28, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />34<br />
    65. 65. Infoway Drug Systems Strategy<br />Program Funding: $185M (Generation-3) 75:25 Funding<br />Solution Objectives<br />Comprehensive collection of All People All Drugs (ADAP)<br />Patient’s Medication Profile (MP) is viewable electronically by the physicianand pharmacist (Portal or Message-based)<br />Physician can generate and send a patient’s Rx electronically<br />Pharmacist can view the order online and to fill the prescription <br />Automatic notification to the attendingphysician and pharmacist of Adverse Drug Events (ADE)<br />Expected Results<br />$613M annual savings, Canada wide,avoiding adverse drug reactions and drug compliance issues<br />Source: Canada Health Infoway<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />35<br />
    66. 66. Evolution of EHR<br />Generation 4<br />The Mentor<br />Generation 3<br />The Helper<br />Generation 2<br />Functionality and Value Chain Optimization<br />The Documenter<br />Generation 1<br />The Foundation<br />e.g. Physical infrastructure to support the EHR such as data centers and networking <br />Enablers<br />End of 2009<br />Generation 3 plus complex Decision Support<br /><ul><li>Order entry and results viewing for laboratory tests, medications and images
    67. 67. Alert notification (e.g. duplicate tests, drug interaction)
    68. 68. Provisioning of Clinical Practice Guidelines
    69. 69. Patient demographics
    70. 70. Provider demographics
    71. 71. Location demographics</li></ul>Results Viewing<br /><ul><li>Laboratory test results
    72. 72. Dispensed medications
    73. 73. Diagnostic image results</li></ul>Source: Canada Health Infoway<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />36<br />
    74. 74. Drug Program Investment Strategy<br />Support Drug Information System (DIS) solutions:<br />Generation 3 Drug Information Systems that will:<br />Capture data on All Drugs for All People<br />Support viewing of drug profiles, as well as ePrescribing<br />Generation 2 systems as a stepping stone to a Gen-3<br />Support the establishment of replicable COTS (“Commercial Off-The-Shelf”) Solutions (e.g., NL Procurement)<br />Invest in HL7v3 pan-Canadian message standard (i,e., CeRx, NeCST)<br />Engage with key stakeholders to foster engagement/adoption.<br />Excludes funding for Drug Claims Processing system components<br />Source: Canada Health Infoway<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />37<br />
    75. 75. Clinical Drug Information Systems<br />Provider Access<br />Clinical Management<br />Claims Administration<br />Client<br />Client<br />Registry<br />Registry<br />Network<br />Client<br />Client<br />Domain Repository (Pharmacy)<br />Provider<br />Client<br />Registry<br />Registry<br />Registry<br />Registry<br />Public and<br />Private Claims<br />Adjudication<br />and<br />Administration<br />Pharmacy<br />System<br />Pharmacy<br />Access<br />Dispensing<br />Support<br /> Dispensing <br />Message<br />EMR<br />MD<br />Access<br />Claims Message<br />Prescribing <br />Message<br />Prescribing<br />Support<br />Prescribing<br />Support<br />CIS<br />Hospital <br />Access<br />Existing Systems<br />Pharmacy/MD/<br />Hospital <br />Access<br />Clinical<br />Viewer<br />Existing Messages<br />New Messages<br />Source: Canada Health Infoway<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />38<br />
    76. 76. Adoption will be key to success…<br />Drug Information System is highly dependent on collaboration with...<br />Private sector stakeholders - i.e. retail pharmacies (Rx) - to implement core parts of the technology solution<br />Professional colleges - i.e. colleges of pharmacists and physicians - to support changed professional roles and work processes<br />Ministries of Health - to align with their drug benefit systems<br />Standards Projects - National electronic Claims Standard (NeCST) and Clinical Message development (CeRx)<br />Pan-Canadian deployment is highly dependent on supporting provinces to evolve their pharmacy networks <br />Deployment of Gen 3 Drug is highly dependent on physician connectivity and adoption.<br />Source: Canada Health Infoway<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />39<br />
    77. 77. Current Status<br />Pharmacy dispensing<br />Newfoundland, PEI, Alberta, Saskatchewan, Quebec<br />HL7 v2-like system in BC for 15 years (PharmaNet)<br />Project underway in Ontario to address ePrescribing (& eDispensing)<br />Claims support for BC, Newfoundland & PEI<br />Source: Canada Health Infoway<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />40<br />
    78. 78. Netherlands<br />Acknowledgement to Tom de Jong, NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />41<br />
    79. 79. Population: 16 million<br />Capital: Amsterdam<br />Hospitals: about 100<br />General Practitioners: 8000<br />Community Pharmacies: 1700<br />Some Background on the Netherlands…<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />42<br />
    80. 80. Current Challenges in Dutch Healthcare<br />Increased demand; shortage in budget and staff, leafs to long waitlists for care<br />Restructuring of healthcare financing<br />Shift from intra-institutional to trans-institutional cooperation and a resulting need to share information throughout the ‘chain of care’<br />Very little central coordination in the application of technology standards<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />43<br />
    81. 81. Can IT solve all this?<br />Definitely not, but it’s an important instrument<br />To create more efficiency (and thus reduce cost)<br />But also to increase quality (and thus save lives)<br />In the medication domain alone, estimates are:<br />€ 300 million worth of preventable cost<br />> 90.000 preventable admission days<br />due to medication-related errors in the Netherlands…<br />Not all of these errors can be prevented by IT, but accurate, up-to-date, shared information throughout the chain of care is essential <br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />44<br />
    82. 82. 45<br />CHI DIS Workshop Toronto, January 17/18 2006<br />
    83. 83. 46<br />CHI DIS Workshop Toronto, January 17/18 2006<br />
    84. 84. Current situation: Regional Care Networks<br />Intra-institutional prescriptions, but almost no trans-institutional interfaces (either to other hospitals or to primary care)<br />Hospital<br />Hospital<br />General Practitioners<br />Community Pharmacies<br />HL7 v2 interfaces<br />HL7 v2 interfaces<br />OZIS server(Master Patient Index)<br />Patient Data (LDAP)<br />Medication Data (EDIFACT)<br />E-Prescriptions (EDIFACT)<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />47<br />
    85. 85. Problems with Current Situation<br />No shared patient ID <br />Fixed!<br />No common authorization scheme (security)<br />Vendor-based, no stakeholder participation<br />Proprietary EDIFACT data exchange standard<br />Based on SMTP (e-mail): relatively slow<br />Many-to-many connections  high set-up & maintenance costs; high error rate; complex<br />No international harmonization & cooperation<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />48<br />
    86. 86. The Problem of the ‘critical mass’ <br /><ul><li>It takes a long time before there are enough source pharmacies to make it interesting to connect(if there is a hit for only 10% of patients, there is no motivation to use)
    87. 87. Solution: achieve high connectivity in at least one region early in the process
    88. 88. Challenge: vendors are spread around the country</li></ul>% of connected pharmacies<br />time<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />49<br />
    89. 89. NICTIZ <br />National Information & Communication Technology Institute for Healthcare <br />Not-for-profit organisation<br />Founded by healthcare stakeholders:<br />Ministry of Healthcare<br />Organisation of HC Providers<br />Organisation of IT Vendors in HC<br />Dutch HC Insurers Organisation<br />Patient representation groups<br />Funding by Ministry of Health (for a 5-year ‘trial’ period)<br />Based on cooperation with ‘the marketplace’ but without a legal mandate to enforce solutions<br />Very similiar to Canada Health Infoway, but with a much lower budget<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />50<br />
    90. 90. Nationwide Switching Point<br />Well Managed Care System (GBZ)<br />Well Managed Care System (GBZ)<br />Well Managed Care System (GBZ)<br />Well Managed Care System (GBZ)<br />Well Managed Care System (GBZ)<br />Nationwide Switching Point (LSP)<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />51<br />
    91. 91. Well Managed Care System<br />Set of requirements for systems that want to attach to the national infrastructure <br />Non-stop dependable operation & access<br />Safe storage and repeatable query results<br />Retrievable audit trail, logging of all access<br />Guaranteed ‘semantic interoperability’<br />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<br />Describes behavior, not technology<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />52<br />
    92. 92. Hierarchy of Care Information Brokers<br />Nationwide Switching Point (LSP)<br />Regional level<br />Well Managed Care System (GBZ)<br />SubsystemPharmacy 1<br />HL7 version 3<br />SubsystemPharmacy 2<br />Local Care Information Broker (ZIM)<br />proprietary standards<br />SubsystemPharmacy 3<br />National level<br />SubsystemPharmacy 4<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />53<br />
    93. 93. Status update 2009<br />Nationwide Switching Point (LSP) is operational, acting as the national Care Information Broker<br />Big delays because of original method for secure transmission  move to token authentication<br />National Patient ID and Provider ID have been implemented in care provider organizations<br />Increasing number of software vendors are ready to update and access the LSP with their software<br />NICTIZ runs qualification tests for ‘well managed care systems’ (procedural and technical criteria)<br />Source: NICTIZ<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />54<br />
    94. 94. United Kingdom<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />55<br />
    95. 95. Architechture – ETP Focussed<br />Reimbursement Agency<br />MQ<br />NCRS SPINE<br />SDS<br />LRS<br />CSA<br />ETP<br />PSIS<br />SSB<br />PDS<br />TMS<br />N3<br />LSP<br />Prescribing<br />System<br />(ESP)<br />Prescribing<br />System<br />(LSP)<br />Dispensing<br />System<br />(ESP)<br />Source: NHS/Blue Wave Informatics<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />56<br />
    96. 96. Scale – Some Stats<br />650 million prescriptions <br />5 interactions per prescription (minimum)<br />3250 million per year<br />300 working days per year<br />10 million interactions per day<br />6 hours account for most of flow (guess)<br />Peak<br />1.7 million per hour (peak)<br />300 000 per minute (peak)<br />50 000 per second (peak)<br />@ 10 k bytes per interaction, 500 Mb per second (peak)<br />Source: NHS/Blue Wave Informatics<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />57<br />
    97. 97. UK Architecture<br />All messages are stored and returned as Clinical Statements<br />Only message fragments are stored – the contents are not parsed out<br />Local databases arenot considered<br />Source: NHS/Blue Wave Informatics<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />58<br />
    98. 98. Why Does UK Use This Architecture?<br />High throughput is required and hence minimal processing<br />Parsing out messages is costly and should be minimised<br />A common pattern for all stored messages makes for more efficient processing<br />Common patterns impose structures on message designs<br />High throughput message design is NOT independent of the architecture<br />Source: NHS/Blue Wave Informatics<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />59<br />
    99. 99. epSOS - EU<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />60<br />
    100. 100. epSOS – a European eHealth Project<br />epSOS is the first European eHealth project connecting counties<br />Look to support the following use cases for pharmacy:<br />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<br />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<br />Technical approach<br />Use the CDA (document) standard for providing information on current prescriptions (not medication history)<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />61<br />Source: www.epsos.eu<br />
    101. 101. Wrap Up & Q&A<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />62<br />
    102. 102. Outline - REVIEW<br />Pharmacy Defined<br />Pharmacy at HL7<br />Pharmacy ArchitecturalApproaches<br />Implementations Aroundthe World<br />Nov 2, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />63<br />
    103. 103. March 3, 2010<br />© 2010, Gordon Point Informatics Ltd.<br />64<br />Thanks!<br />Michael van Campen<br />Gordon Point Informatics Ltd.<br />Michael.vancampen@gpinformatics.com<br />Jean Duteau<br />Gordon Point Informatics Ltd.<br />Jean.duteau@gpinformatics.com<br />gpi<br />

    ×