1 / 32

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

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 19 2007. Agenda. Approach e-locum record “the movie” Status Tips: Strategy and awareness Architecture and design

janina
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing e-locum recordGP-oriented patient summary for out-of-office hours GP care NICTIZLinda Mook, product managerTom de Jong, HL7v3 expertSeptember 19 2007

  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 2007-2011 • Staff 35 fte + 5-10 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

  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 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 tolocum GP’s (extrapolation) (Jan 2005, TNS/NIPO )

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

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

  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 • 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

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

  12. Tips: strategy and awareness • Try to keep commitment on scope and agreements made in project even when programs, organizations, people and strategies change (contradiction?) • Separate strategy from product for stakeholders • Address stakeholder concerns

  13. Tips: architecture and design • Umbrella organizations describe and publish ‘interactions’ in guidelines for consensus • Architecture designs and implementation guides with lots of examples • Use prototyping and provide test tools and test cases • SSL end-to-end authentication ? • Organize vendor ‘connectathons’

  14. Tip’s 1st implementation • Organize Issue management and transparent decision-making • vendor ‘connectathons’ and/or feedback/educational sessions with/by vendors • Quick response to potential showstoppers in pilots • 1 contract for vendors / HCP’s • Publish list of qualified vendors and planning qualifications • Coordinate communication from involved organizations • Work out version control and consequences for all parties

  15. DMIM PriCa

  16. Interactions

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

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

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

  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 analysis3/3

  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 www.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

  32. Thank you. • If you have more questions don’t hesitate to contact us Linda Mook mook@nictiz.nl Tom de Jong tom@nova-pro.nl

More Related