Presentation is loading. Please wait.

Presentation is loading. Please wait.

Implementing e-locum record Implementing e-locum record GP-oriented patient summary for out-of-office hours GP care NICTIZ Linda Mook, product manager.

Similar presentations


Presentation on theme: "Implementing e-locum record Implementing e-locum record GP-oriented patient summary for out-of-office hours GP care NICTIZ Linda Mook, product manager."— Presentation transcript:

1 Implementing e-locum record Implementing e-locum record GP-oriented patient summary for out-of-office hours GP care NICTIZ Linda Mook, product manager Tom de Jong, HL7v3 expert September

2 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

3 NICTIZ 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 Staff 35 fte fte hired expertise

4 Approach 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

5 Basic EHR Request Source GPSpecialistPharmacistAmbulancePatientParamedic GP E-locum record e-Emergencye-Medication+e-EmergencyPatient Access PS-Paramedic Out-patient, Refer-info. Pharmacist e-Medication Specialist PS-Spec-HAPS-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 Patient Access Return information 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

6 e-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

7 Some numbers Population (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%) visits to locum GP’s (extrapolation) (Jan 2005, TNS/NIPO )

8 Organizations involved in implementation Pilots and start national roll-out Registries :UZI-cards & patient nrs. Design, maintenance and management of switchpoint Policy

9 EHR roll-out Organisational Focus Time  Strategy & Awareness Architecture & design 1st Implementation National Roll-out Governance & Maintenance

10 Current 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 2 nd ‘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

11 Vendor application qualified for e-locum* * Consists of several generic and project specific HL7v3 messages and infrastructural demands

12 Tips: 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

13 Tips: 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’

14 Tip’s 1 st 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

15 DMIM PriCa

16 Interactions

17 GP Locum GP Project specific message Activate act reference Find act reference entries Response act reference entries Activate act reference Request change of custodian accept change of custodian reject change of custodian Request change of custodian Request summary Send summary Send visit report receive visit report Generic message Switch point

18 Request summary

19 GP patient summary

20 Locum Report

21 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

22 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

23 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.)

24 UZI card SSL real-time authenticatio n 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)

25 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)

26 Version control issues 1/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

27 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

28 Version control analysis 3/3 Category 0Category 1Category 2Category 3Category 4 Impact on vendor or switch point application NoYes Cross-dependent on other changes NoYes Backwards or forwards incompatible NoYes Transformation supported by switch point YesNo

29 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)

30 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

31 References follow our progress on implementation Movie can be downloaded here: The testtool can be found here: Other websites:

32 Thank you. If you have more questions don’t hesitate to contact us Linda Mook Tom de Jong


Download ppt "Implementing e-locum record Implementing e-locum record GP-oriented patient summary for out-of-office hours GP care NICTIZ Linda Mook, product manager."

Similar presentations


Ads by Google