Wat zijn de belangrijkste kenmerken van een EPD-oplossing waar GGZ-organisaties wél gelukkig van worden? Op 29 oktober 2015 verzorgde de Zorginformatiegroep in samenwerking met GGZ Friesland op het tweejaarlijkse Medisch Informatica Congres een visievormende sessie om deze vraag te beantwoorden.
DTplan Demodagen_10 10 2013_3_randvoorwaarden voor systeemintegrator in de zo...
20151029 ggz epd mic2015
1. Klik om de stijl te bewerken
GGZ-EPD: een nieuw recept voor geluk
De belangrijkste kenmerken van een EPD-oplossing waar GGZ-
organisaties wél gelukkig van worden
Medisch Informatica Congres 2015
2. Klik om de stijl te bewerken
Even voorstellen…
Hielko Ophoff
- Manager Informatiemanagement
GGZ Friesland
Jorrit Spee
- Oprichter Zorginformatiegroep
- Projectleider en adviseur EPD-
en andere informatietrajecten in
de zorg
- Oprichter EPDmeter.nl
5. Klik om de stijl te bewerkenVeel middelgrote en grote GGZ-organisaties
zijn ontevreden over hun EPD
• Lage gebruiksvriendelijkheid
• Systeem ondersteunt processen slechts zeer beperkt
• Gebrekkige innovatie
• Vendor lock-in
• Het is lastig om andere applicaties op bestaande systemen aan te sluiten
• Overstappen ‘lijkt’ moeilijk.
• Hoge kosten
Het referentiemodel epd-ggz van GGZ Nederland
blijkt geen adequaat recept voor geluk
6. Klik om de stijl te bewerken
Wat willen we nou eigenlijk?
A. Ondersteuning primair proces
• Wat is gebruiksvriendelijkheid?
• Ondersteuning voor samenwerken (multidisciplinair en met patiënt/
systeem/ partners)
• Ondersteuning bij behandelproces en behandeladministratief proces
B. Mee kunnen bewegen met veranderingen
• De manier van (samen)werken en de processen die dienen te worden
ondersteund, wijzigen geregeld, kijk bijvoorbeeld naar de vlucht die E health
neemt
• Flexibiliteit van epd-oplossing is essentieel oor structurele invulling
gebruiksvriendeijkheid
C. Kostenbeheersing
• “Gelijkblijvende” kosten over de levensduur van de oplossing
8. Klik om de stijl te bewerkenWaarom kunnen de klassieke applicaties dit
niet bieden?
A. Ondersteuning primair proces
• Vaak administratieve invalshoek (waar is het primair proces?)
• Gebrek aan aandacht voor samenwerking
• Gebrek aan aandacht workflow-ondersteuning
• Suboptimale oplossingen door te brede focus van leverancier
• Ondersteuning van behandelaar is heel wat anders dan zorgadministratieve ondersteuning (2
verschillende expertises)
• 80% van ontwikkelcapaciteit gaat verloren aan aanpassingen wet- en regelgeving
B. Mee kunnen bewegen met veranderingen
• Producten zijn weinig flexibel
• Producten zijn gebaseerd op oudere platformen (spaghetti-architectuur). Niet geschikt voor
verandering. Geen modulariteit
• Gesloten (de leverancier bepaalt met welk stuk van de applicatie je wel of niet mag praten),
vaak wel lezen niet schrijven
• In voorkomende gevallen samenstelsel van verschillende deelsystemen
C. Kostenbeheersing
• Meeste aanbieders werken met groeiend kostenmodel
• Over de levensduur wordt de oplossing steeds duurder per behandelaar/patiënt
• Veel on-premise met alle gevolgen van dien (hardware-updates nodig bij nieuwe versies etc)
9. Klik om de stijl te bewerken
Perspectief van de huidige leveranciers
Er verschijnen nieuwe versies van pakketten Impulse, PinkRoccade, Nexus en
Chipsoft
A. Ondersteuning primair proces
• Wordt waarschijnlijk minder slecht (mooie knopjes, nieuwe functies)
• Verbetering voornamelijk aan buitenkant. Verbeterpotentieel beperkt door
architectuur
B. Mee kunnen bewegen met veranderingen
• Verbetert nauwelijks/niet
• Blijft lastig want de onderliggende architectuur blijft hetzelfde
C. Kostenbeheersing
• Verbetert nauwelijks/niet
• Voorkant product verandert, leverancier niet. Risico op toename complexiteit en
daarmee toename kosten.
We komen er hoogstwaarschijnlijk niet door
met dezelfde pakketten te blijven werken!
10. Klik om de stijl te bewerkenWat zijn de belangrijkste kenmerken van
een EPD dat wel gelukkig maakt?
1. Applicaties moeten integratie met andere
applicaties voorop hebben staan
• Alle data in de applicatie moet via
integratiestandaarden (HL7, SOAP) inzichtelijk en
bewerkbaar zijn.
• Opslag van patiëntgegevens bij voorkeur via open
standaarden
2. Generieke opbouw van applicaties
• Datalaag losgekoppeld van informatielaag (DIKAR)
3. Splitsen van dossier en ZIS
• Het zijn 2 gescheiden werelden met beperkte
integratie (voornamelijk agenda).
• Splitsing voorkomt blokkade innovatie dossier
door zware ontwikkeldruk wet- en regelgeving
• Voorkomen van vendor lock-in
4. SaaS
A. Ondersteuning
primair proces
B. Mee kunnen
bewegen met
veranderingen
C. Kostenbeheersing
11. Klik om de stijl te bewerken
GGZ Friesland
Keuze voor:
• Code24: dossier + cliëntportaal (met Infosupport) + behandelarenportaal
• Careweb van 12Care: zorgregistratie en –facturatie
Doelen:
A. Ondersteuning primair proces: focus + visie
B. Mee kunnen bewegen met veranderingen: fundament en opbouw
C. Kostenbeheersing: vaste terugkerende kosten
Middelen:
1. Applicatie-integratie: Code24 intrinsieke openheid, Careweb waar mogelijk
2. Generieke opbouw: Code24 OpenEHR, Careweb vanuit visie
3. Splitsen van dossier en ZIS: zie boven
4. SAAS: Code24 nog niet, Careweb multi-tenant
12. Klik om de stijl te bewerken
EPD is samenspel
Cliëntenportaal
Medische Database (Base24)
Zorgverlenersportaal
(mConsole)
Medicatie
eHealth
ROM Metingen
Careweb
(cloud)
administratief portaal
Cliënt apps
Derdenportaal
Apps voor
zorgverleners
Notes de l'éditeur
JS
JS en HO
0:00 – 0:05 (inclusief iets later beginnen)
JS
JS
HO
0:05 – 0:10 inclusief plaatjes
Voice over:
Voorbeelden gebrekkige innovatie;
Moeizame integratie met e health
Vendor lock-in
Epd leveranciers pushen clientportalen
Hoge kosten:
- Nieuwe functionaliteit brengt extra structurele kosten met zich mee.
HO
0:10 – 0:15
Voice-over:
Wat is gebruiksvriendelijkheid?
Ondersteuning van het proces/ weinig klikken
Zelf controle houden maar wel goed ondersteund worden
JS
JS
0:15 – 0:20
Producten zijn gebaseerd op oudere platformen (spaghetti-architectuur). Niet geschikt voor verandering. Geen modulairiteit
Voorbeeld Pleegzorg Voorbeeld WMO
Gesloten (de leverancier bepaalt met welk stuk van de applikcatie je wel of niet mag praten), vaak wel lezen niet schrijven
Geen open datamodel: Voorbeeld: eigen clientportaal geen adreswijziging mogelijk
JS
0:20 – 0:25
HO
0:25 – 0:30
Het zijn 2 gescheiden werelden met beperkte integratie (voornamelijk agenda).
Metafoor: Auto en caravan
Datalaag losgekoppeld van informatielaag (DIKAR)
Voorbeelden Generieke opbouw van financiering bij Careweb,
Niet-Generieke opbouw van dossier-data bij USER (Oracle Forms)
HO
Careweb visie over opbouw: conceptuele financieringsvarianten, privacy en normen, vanuit feiten
HO
0:30 – 0:35
Niet in plaatje: koppeling met laboratoria, met verwijzers, met HR/salarissysteem
eHealth: geen eigen portaal
Niet één database, maar EPD verdeelt over databases