The Electronic Medication Record in The Netherlands

1
The Electronic Medication Record in The
Netherlands
A co-production by NICTIZ HL7 the Netherlands
Healthcare stakeholders IT industry
Tom de Jong Nova Pro Consultancy
2
Some background on me

• Co-founder of ChipSoft, which grew from 5 to 150
  people and became dominant HIS vendor
• Background in software development, then
  management of the implementation division
• Longstanding interest in HL7, international
  participation since HL7 v3 was in its infancy
• Currently lead HL7 consultant on the Dutch
  National Medication Record project for NICTIZ

3
Some background on the Netherlands
Population 16 million Capital
Amsterdam Hospitals about 100 General
Practitioners 8000 Community Pharmacies 1700
4
Outline of this presentation

• Current challenges in Dutch healthcare
• Pharmacy-related IT in the Netherlands
• NICTIZ (comparable to National Program for IT)
• AORTA (infrastructure) and HL7 v3
  (infostructure)
• Pilot projects based on gateways
• The ambitions for 2007 and beyond
• The politics of national IT projects

5
Current challenges in Dutch healthcare

• Increased demand shortage in budget and staff ?
  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.

6
Can IT solve all this?

• Definitely not, but its 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
• gt 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

7
(No Transcript)
8
(No Transcript)
9
Pharmacies in the Netherlands (3-layer model)
inpatient
flow of prescriptions
flow of patients
10
Pharmacy IT(the vital signs)

• All 1700 community pharmacies and all 100
  hospital pharmacies use software systems
• About 50 of all GPs, but only 10 of all
  hospital specialists use e-prescribing
• About 6 major pharmacy system vendors, most
  specialized in either community or hospital
• All of the GP system vendors and most of the HIS
  vendors have e-prescribing functions(many are
  now moving towards ASP solutions)
• Regional pharmacy networks are operational in
  most parts of the country (OZIS regions)
• Nationally adopted set of code systems for drugs
  (down to package level) and all related concepts!

11
Current situation Regional (primary) care
networks (OZIS)
OZIS sever(Master Patient Index)
Patient Queries and Updates
Medication Profile Queries and Updates
E-Prescriptions
12
Problems with current situation

• No shared patient ID (but thats being worked on)
• No common authorisation scheme (security)
• Vendor-based, no stakeholder participation
• Proprietary EDIFACT data exchange standard
• Many-to-many connections ? high set-up and
  maintenance costs high error rate complex
• Based on SMTP (e-mail) relatively slow
• No international harmonization and cooperation
• But most of all

13
Overlapping regions
14
(No Transcript)
15
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 NPfIT, but with a much much
  lower budget

16
NICTIZ, aims and activities

• Creation of the right conditions for nationwide
  and transparent access to real-time healthcare
  information about every patient
• Nationwide infrastructure in the healthcare
  sector to ensure fast, secure and transparent
  information exchange ? AORTA!
• Software interfaces to achieve seamless
  inter-operability, leading to a virtual EHR ?
  HL7 v3
• Initial focus on single, well-understood domain
  national electronic medication record

17
Possible solutions for the network infrastructure

• Option 1 One big EHR database with healthcare
  info for 16 million people
• Option 2 Leave data at the source, but register
  a reference to it in a central repository (a
  so-called Act Registry)

? AORTA!

• (Option 3 Somewhere in between core data in the
  repository details at the source)

18
AORTA Nationwide IT infrastructure for healthcare
19
The essence of AORTAThe Care Information Broker
(ZIM in Dutch)

• Data itself it not copied in the registry
• Source systems upload a reference to their data
• GPs and specialists upload prescription
  references
• Pharmacies upload dispense references
• All references are based on a (currently
  available) national patient ID and a national
  care provider ID
• Interested parties use a pull mechanism (query)
  instead of notification messages between
  systems(although subscription mechanism is also
  supported)

20
There are pros and cons to every solution

• Advantages
• Always the most recent data from the virtual DB
• No risk of inconsistencies due to duplication
• No exponential growth in of interactions
• Centralized access makes enforcing standards
  easier
• Challenges
• Performance is as yet a very uncertain factor
• Centralized model requires a lot of coordination
• ? making deadlines really becomes a challenge
• The ZIM itself will have to be built by an IT
  vendor(since the government has no intention to
  operate it)

21
Care Information Broker functions
Forward query to source HC systemsand combine
results
Care Information Broker
Act Registry
Care Provider Registry
(gateway for) patient identification
(national) patient ID xxxtype of
information DISPinfo source (system)
yyy Optionaldate/time of info
dd/mm/yyunique act ID zzz

• Identification Authentication of users based on
  national care provider ID (called UZI)
• Authorisation
• Logging

Verification of national patient ID (called BSN)
Process queries from healthcare systems
Process queries from healthcare systems
Process queries from healthcare systems
Process updates from healthcare systems
Technical infrastructure based on (encrypted) VPN
22
Future situation with a Care Information Broker
Care Information Broker (Act Registry) PRESC GP1
PAT1 PRESC GP1 PAT2 PRESC HOSP1 PAT1 DISP
PHARM1 PAT1 DISP PHARM2 PAT2
E-Prescriptions
Dispense References
Dispense and Prescription Queries
23
Why HL7 v3 as the common interface?

• Huge install base for HL7 v2 within hospitals
  (even though v3 is fundamentally different)
• Tremendous international interest, both in
  development and (potential) implementation
• ? close cooperation between Canada/NL/UK
• Excellent framework for message design
• Vendor driven community
• XML-based ? off-the shelf tools
• Last not but least, HL7 v3 is a hype

24
What HL7 v3 has provided

• Specifications for the most essential
  interactions
• Prescription message
• Dispense message
• Associated queries (medication profile
  dispense history)
• Following soon
• Intolerances, allergies, contra-indications,
  detected issues
• Messages to allow for revision, termination etc.
  of prescriptions
• Implementation guide has been set since 2004.
• Pilot projects have provided proof of concept.
• International harmonization will occur in 2007/8.
• Click for example information model
• Click for example XML message

25
Challenges in interoperability

• Definition of concepts (like clinical dispense)
• Definition of application roles and events
• Dosage specifications
• Timing (schedule)
• Quantity/Strength
• Preconditions/instructions
• Vocabularies
• Some defined within HL7 (e.g. abort reasons)
• Some defined locally (most notably drug codes)

26
Original milestones in the NICTIZ plan
Level 3 Nationwide medication record
Level 2 Regional preparation for nationwide
medication record
Level 1 (acceleration programs) Regional
medication record(migrate existing networks to
HL7v3)
Nov. 2003 Showcase event at MIC 12 IT vendors
presented integration of their medication
information
2006
2003
2004
2005
27
Major challengemigration of existing regional
infrastructures

• How to migrate regional networks to AORTA
• ...without breaking what was already working fine
• ...without creating too much of a barrier to
  enter
• ...without annoying vendors who had invested in
  it
• ...with added marketing potential for innovators
• In mid 2004, there was no Care Information Broker
  yet (let alone a national one), but the HL7 v3
  specifications were ready to be used
• Solution create HL7 v3??OZIS gateways
• ...Pharmacy systems could remain unchanged
• ...OZIS infrastructure could remain operational
• ...but new parties (hospitals, GPs) could join
• ...while evaluating HL7 v3 at the same time

28
Example of regional implementation based on HL7
v3 West-Friesland project

• Builds upon existing regional infrastructure
  (OZIS) between community pharmacies
• Extends this by providing a gateway for
  transformation between EDIFACT (pharmacies) and
  HL7 v3 (hospital and other care providers)
• 1st step exchange of dispense information
  (bidirectional community ?? hospital)
• 2nd step sending electronic prescriptions from
  hospital to community pharmacies

29
(No Transcript)
30
Barriers that were overcome by pilot projects
building upon existing solutions

• Pharmacists were protective of the medication
  profiles they had built up and shared for years
  (within the OZIS region)
• Past sensitivities led to mistrust between
  community pharmacies and hospital (which has an
  associated outpatient pharmacy)
• Technical challenge was the least trouble
  (transforming data was relatively
  straight-forward, integrating process was harder)

31
Examples of practical solutions to issues

• Q What is a dispense in a hospital setting?A
  Every order confirmed by the hospital pharmacy.
• Q When should hospital medication be interfaced?
  A No sooner than at the time of
  discharge.(This has now been revised due to new
  input).
• Q How to prevent information overflow with
  hospital medication in community pharmacies? A
  Filters based on interaction relevancy.
• Q How to prevent extra work by doctors?A
  Automated pre-fetching of medication profiles.

32
The ambitions for 1/1/2008(this was 1/1/2007
until 2 months ago-)

• Nationwide Switching Point (LSP) should be in
  place, acting as the national Care Information
  Broker. Status up and running, but no realistic
  tests yet.
• National Patient ID and Provider ID should be
  ready for use in all care provider organizations.
  Status Patient ID still in senate, but
  organizations prepare anyway. Provider ID (and
  associated UZI passes) available, but not widely
  rolled out.
• Two regions will have served as
  pilots/showcases.Status in preparatory stages
  (Amsterdam/Rotterdam). Major software vendor is
  racing to get software ready.
• All software vendors should be ready for
  uploading references, querying the LSP and
  processing the results within their software.
  Status early adopters took part in regional
  projects or national Proof of Concept, rest to
  follow.
• All systems should behave as well managed care
  systems.Status time will tell how realistic
  that demand is

33
Nationwide Switching Point(ZIM on nationwide
scale)
34
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
• 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
• GBZ describes behavior, not technology

35
Hierarchy of Care Information Brokers
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
36
The Dutch cooperative model

• Dutch politics is well-known for its so-called
  Polder Model, where government rarely dictates
  but aims to achieve consensus through compromise
• This has worked quite well to achieve harmony
  between opposing political forces
• It is a project managers nightmare though,
  because it means that deadlines may shift until
  consensus has been reached

37
The politics of national IT projects

• Deadlines often seem more inspired by election
  headlines than by practical feasibility
• There is a strong patient lobby warning against
  the potential privacy hazards
• On the bright side there is considerable
  enthusiasm about the goals of an EMR investment
  is not disputed (although minimal compared to
  comparable projects worldwide)

38
The EMR project approach(taking two steps
forward)

• Gain trust by generating enthusiasm about the
  underlying technology (bottom-up stimulus)
• This was aided by early-adopter demos pilot
  projects
• Some seized this opportunity with new products
• Frustration too many gaps in continuity of
  vendor involvement (? fuel for cynicism and
  mistrust)
• Optimism the common goal is set, the first steps
  taken local implementations based on the common
  specs!
• Gain support by encouraging innovation as a
  strategic success factor (top-down stimulus)
• To be honest not very well managed stakeholder
  involvement should have been stronger and more
  direct
• Lesson learned if you want consensus, youd
  better make sure that parties feel connected to
  the effort

39
Recent developments (slipping one step back)

• The vendor that is now building the LSP was
  selected only quite recently (due to a lengthy
  European proposal acquisition procedure)
• There was considerable friction when vendors with
  a strategy based on gateways were told that they
  wouldnt be Well Managed Care Systems
• The Minister of Health used the need for a
  perfect authorization scheme as an excuse to
  postpone ánd to shift the responsibility for
  implementation
• The vendors and NICTIZ got most of the blame, but
  they were used as scapegoats for unrealistic
  project goals (the best was clearly an enemy of
  the good)

40
Lessons learned from the project so far

• Bring vendors in the loop as early as possible ?
  there is now an expert team and regular
  informal vendor meetings
• Have a very limited number of pilot projects/
  regions, so you dont have to deal with lots of
  implementation details simultaneously
• Make sure that technical requirements are
  practically feasible and allow for a stepwise
  migration (with some slack in requirements)
• Maintain an atmosphere of cooperative innovation

41
Challenges for NICTIZ (and HL7 Netherlands)

• Diplomacy conflicting interests and historical
  sensitivities (e.g. prescribers ?? dispensers)
• Motivationwithout major financial incentives or
  legislation, challenge is to keep the marketplace
  moving
• Guidancepublication of implementation
  guidelines, education and maintenance for HL7 v3
  messages

42
Summary

• NICTIZ has a clear vision of where it wants to be
  in 2006
• They have waited long to provide a roadmap for
  these goals ? most companies had a wait and see
  policy
• Yet, the market slowly embraces many aspects of
  the framework (especially HL7 v3) and create
  strategies for it
• Regional initiatives make many compromises, but
  have served as a proof of concept and stimulated
  enthusiasm
• A lot of missionary work and diplomacy (or
  legislation!) is still needed to keep everybody
  going in the same direction
• NICTIZ has not made its deadlines, but both
  vendors and providers are convinced that the
  goals will be reached? nationwide implementation
  is likely to occur gt 2006

43
Contact information

• NICTIZ
• www.nictiz.nl
• info_at_nictiz.nl
• HL7 Netherlands
• www.hl7.nl
• info_at_hl7.nl
• author
• tom_at_nova-pro.nl

44
Questions