Implementing e-locum recordImplementing e-locum record GP-oriented patient summary for out-of-office hours GP care

NICTIZLinda Mook, product managerTom de Jong, HL7v3 expert

September 19 2007

Agenda

• Approach• e-locum record• “the movie”• Status• Tips:

• Strategy and awareness

• Architecture and design

• First implementation

• Overview used DMIM, RMIM’s and supported interactions

• Implementation challenges

• Implementation successes

NICTIZNICTIZ

• Nation-wide and neutral; founded in 2002

• All parties involved take part • umbrella organizations of care

providers, patients, healthcare insurers, IT providers

• Funding by the government 2007-2011• Staff 35 fte + 5-10 fte hired expertise

ApproachApproach

• Electronic Patient Record will be virtual:• Care provider requests data

from Nationwide Switch Point• Reference index to data sources• Switch point forwards requests, gathers data and

acts like a virtual patient record• Unique patient identifier (BSN)• Demands ‘Qualified Healthcare Information systems’

• Incremental development of Electronic Patient Record

• Killer applications: e-Medication Record & e-Locum Record

Basic EHR Request Source

GP Specialist Pharmacist Ambulance Patient Paramedic

GP E-locum record

e-Emergency e-Medication+ e-Emergency Patient Access

PS-Paramedic

Out-patient, Refer-info.

Pharmacist e-Medication e-Medication e-Medication e-Medication e-Medication e-Medication

Specialist PS-Spec-HA PS-Spec-Specialist

PS-Spec-Pharmacist

PS-Spec-Ambulance

Patient Access

PS-Spec-Paramedic

e-Medication+ Patient Access

Hospital-lab e-Lab,

e-Radiology, e- Pathology

e-Lab,

e-Radiology,

e- Pathology

e-Lab,

e-Radiology

e- Pathology

e-Lab,

e-Radiology

e- Pathology

Patient Access

e-Lab,

e-Radiology e- Pathology

ER/Ambu. e-Emergency e-Emergency e-Emergency e-Emergency Patient Access

Return information

Patient e- Patient e- Patient e- Patient e- Patient Patient Access

Patient Summary

Paramedic PS-Paramed.-GP

PS-Paramed.-Spec.

PS-Paramed.-Apotheker

PS-Paramed.-Ambulance

Patient Access

PS-Paramed.-Paramedic

e-Locum Recorde-Locum Record

• Provides access to key medical data during out-of-office hours by locum GP

• Locum GP’s are often organized and physically located in ‘GP posts’ (‘huisartsenposten’ in Dutch)

• 8495 GP’s /3871 GP practices and 127 GP posts in the Netherlands

• 7% of GP posts have (electronic) access to patient’s medical record (based on Edifact not HL7v3)

• 87% of patients expect the availability of the information during out-of-office hours

Some numbersSome numbers

• Population 16.372.715 (June 2007, source CBS)

• Subjective experience health • “How do you assess your general state of health?”• 80,9% ‘Healthy’ or ‘very healthy’ (2006)

• Preliminary figures 2006 about costs• Total expense € 66 billion

• € 4017 per capita

• 13,4 % GDP

• % persons contact with GP in year • 2006 :72,6 % ↓ (2001 :76,1%)

• 2.330.000 visits to locum GP’s (extrapolation) (Jan 2005, TNS/NIPO )

Organizations involved in Organizations involved in implementationimplementation

Pilots and start national roll-out

Registries :UZI-cards & patient nrs.

Design, maintenance and managementof switchpoint

Policy

EHR roll-outEHR roll-outO

rgan

isat

ion

al F

ocu

s

Time

Strategy & Awareness

Architecture& design

1st Implementation

National Roll-out

Governance & Maintenance

Current StatusCurrent Status

• Nationwide switch point operational• Pilot in Twente (Enschede) started

• 5 GP practices and 1 GP post connected to nationwide switch point

• Vendor qualifications• 5 vendors qualified

• 2nd ‘pilot’ in Nijmegen scheduled to start soon• Legislation on use of EHR

• End 2007 draft text for law submitted to advisory bodies and Dutch parliament effective 1/1/2009

• Possible financial incentives to promote use of EHR

Vendor application qualified for e-locum*

* Consists of several generic and project specific HL7v3 messages and infrastructural demands

Tips: strategy and awarenessTips: strategy and awareness

1. Try to keep commitment on scope and agreements made in project even when programs, organizations, people and strategies change (contradiction?)

2. Separate strategy from product for stakeholders

3. Address stakeholder concerns

Tips: architecture and designTips: architecture and design

1. Umbrella organizations describe and publish ‘interactions’ in guidelines for consensus

1. Architecture designs and implementation guides with lots of examples

2. Use prototyping and provide test tools and test cases

3. SSL end-to-end authentication ?

4. Organize vendor ‘connectathons’

Tip’s 1Tip’s 1stst implementation implementation

1. Organize Issue management and transparent decision-making

2. vendor ‘connectathons’ and/or feedback/educational sessions with/by vendors

3. Quick response to potential showstoppers in pilots

4. 1 contract for vendors / HCP’s

5. Publish list of qualified vendors and planning qualifications

6. Coordinate communication from involved organizations

7. Work out version control and consequences for all parties

DMIM PriCa

Interactions

PrimaryCare EHR ExtractQueryPlacer

PrimaryCare EHR ExtractQueryResponse Provider

QUPC_IN990001NL Primary Care EHR Extract Query

QUPC_IN990002NL Primary Care EHR Extract Query Response

REPC_IN990003NL Primary Care Locum Report

GP LocumGP

Project specific message

Activate act reference Find act

reference entries

Response act reference entries

Activate act reference

Request changeof custodian

accept changeof custodian

reject changeof custodian

Request changeof custodian

Request summary

Send summary Send summary

Send visit reportreceive visit report

Generic message

Switchpoint

Request summary

GP patient summary

Locum Report

Implementation Challenges

• Selecting appropriate vendors for pilot• Stakeholder commitment• UZI card (availability, access times)• SSL real-time authentication• Keeping vendors committed to updates• Version control issues• Standards harmonization issues

Selecting appropriate vendors for pilot

• Pilot came at time when not many mainstream vendors had committed to the AORTA infrastructure and HL7 v3

• Required active ‘lobbying’• Eventually both roles in pilot were

played by the same company• Currently, several other vendors have

followed suit, so the pilot had not only technical but also marketing effects

Stakeholder commitment

• It took quite a bit of lobbying to keep stakeholders (GP’s and their umbrella organization) on board

• This had to do with technical challenges that made use of pilot software quite inefficient at first (see next slide)

• Political discussions have been the source of much confusion (national patient identifier, data ownership, etc.)

UZI card SSL real-time authentication

• Essential element in national identification, authentication and authorization scheme

• Acquiring a card is a laborious process• The accompanying interface software suffered

from long access times (has improved)• Use of real-time authentication is controversial• It is hard to implement, especially in an

architecture that includes an intermediate layer between client and national infrastructure (like a communication engine)

Keeping vendors committed to updates

• Technical specification are always ahead of current implementations

• Result is that new innovations are ‘out of scope’ for implementers (they focus on current challenges)

• Effort is needed to actively engage vendors in update process (stakeholder organizations can help in achieving this)

Version control issues1/3

• This first arose when new technical spec’s were published in May of 2007

• One change was an optional link to ‘episode of condition’ in locum report

• This is not forwards compatible (i.e. an old implementation might reject a message that has the episode link)

• Just one example of the enormous importance of version management

Version control ‘rules’2/3

• Changes in message structure or process should have minimal impact on all stakeholders (and their software)

• Design messages (especially cardinality of new elements) with migration strategies in mind

• If possible fix centrally (at nationwide switch point)• Support for multiple versions at switch point• Where possible: automated message transformation

(depending on authority for switch point to ‘see’ payload)• Analyze impact of each change in new release of

specifications (i.e. supply ‘release notes’) Stress differences (in doc and xml) by listing them explicitly Describe motivation and discussion relating to changes Describe migration strategy Wherever possible: provide style sheet for XML transformation

Version control analysis3/3

Category 0 Category 1 Category 2 Category 3 Category 4

Impact on vendor or switch point application

No Yes Yes Yes Yes

Cross-dependent on other changes

No Yes Yes Yes

Backwards or forwards incompatible

No Yes Yes

Transformation supported by switch point

Yes No

Standards harmonization issues

• D-MIM for this project was based on Patient Care models (with some changes made to adopt to local requirements)

• Several other v3 projects also based on PC, but with slightly other variations;-)

• Universal Patient Care models have continued to change after project start

• Challenge to harmonize at some point:• Within Dutch projects (horizontal)• With universal standard (vertical)

(including possible feedback into universal std)

Implementation Successes

• HL7 v3 adoption has been increasingly smooth (vendors are still critical, but don’t want to miss the boat)

• Technical qualification process has been ‘a pain’ for vendors, but ensured strict adherence to standards (including OID management)

• Switch point paradigm (distributed virtual patient record) is still under scrutiny, but enthusiasm prevails

References

follow our progress on implementationwww.minvws.nl/en/themes/ict-in-healthcare/default.asp

Movie can be downloaded here:www.uziregister.nl/english/

The testtool can be found here:www.testtool.nl/

Other websites:www.nictiz.nl , www.invoering-epd.nl , www.minvws.nl, www.uziregister.nl, www.sbv-z.nl

Thank you.

• If you have more questions don’t hesitate to contact us

Linda Mookmook@nictiz.nl

Tom de Jongtom@nova-pro.nl