Elektronisch Medicatie Dossier o.b.v.. HL7 versie 3 - statusupdate -

Transcriptie

1 Elektronisch Medicatie Dossier o.b.v.. HL7 versie 3 - statusupdate - Tom de Jong Nova Pro Consultancy

2 2

3 3

4 Verpleeghuizen, GGZ instellingen, etc. Medicatiegegevens in de zorgketen Interne apotheek Derde lijn Lab, Radiologie, etc. Medisch Specialisten klinisch Ziekenhuis apotheek Tweede lijn Huisartsen Openbare (deels apotheekhoudend) Apotheken Tandartsen etc. Eerste lijn Stroom van voorschriften patiëntenstroom 4

5 Medicatie en IT (de vitale gegevens) Alle 1700 openbare apotheken en alle 100 ziekenhuisapotheken gebruiken softwaresystemen Ongeveer 50% van alle huisartsen, maar slechts 10% van de ziekenhuizen schrijft elektronisch voor Ca. 6 leveranciers van (Z)AIS en, gespecialiseerd in openbare dan wel ziekenhuisapotheken Regionale OZIS netwerken voor uitwisseling binnen de 1 e lijn zijn in veel regio s operationeel G-Standaard biedt landelijke gebruikte set van coderingen voor medicatie en aanverwante zaken 5

6 OZIS netwerk Hospital Bijna geen uitwisseling tussen ziekenhuizen, spaarzaam tussen ziekenhuizen en 1 e lijn Hospital OZIS sever (Centrale Patient Index) Huisartsen Patient Queries en Updates Medicatie Profiel Queries en Updates Openbare Apotheken Elektronische Voorschriften 6

7 Problemen met de huidige situatie Geen gemeenschappelijke patient ID (maar dat is binnenkort verleden tijd ) Geen universeel autorisatieschema Gedreven door leveranciers, niet door koepels EDIFACT standaard nauwelijks onderhouden Many-to-many verbindingen foutgevoelig Overlappende regio s meerdere connecties Gebaseerd op SMTP ( ): relatief langzaam Geen internationale harmonisatie/samenwerking 7

8 8

9 De essentie van AORTA: De Zorg Informatie Makelaar Data wordt *niet* gekopieerd naar centraal register Bronsystemen melden een verwijzing ernaar aan Voorschrijvers melden voorschriften aan Apotheken melden verstrekkingen aan Alle aanmeldingen zijn gebaseerd op BSN en UZI Bevragende systemen gebruiken een query (in plaats van onderlinge updates) om actuele gegevens op te halen bij bronsystemen via de ZIM Alle autorisatie is gebaseerd op UZI (via SSL verb.) 9

10 Elk voordeel heb z n nadeel... Voordelen Altijd de meest recente gegevens uit het virtuele EPD Geen kans op inconsistentie door duplicering van data Geen exponentiele groei van aantal verbindingen Centraal bevraagpunt stimulans voor standaardisatie Uitdagingen Performance is nog een onzekere factor Centraal model vergt concensus of wetgeving Hollands poldermodel maakt deadlines lastig haalbaar De landelijke ZIM (LSP) moet geraliseerd worden door een leverancier, want de overheid beheert het niet zelf 10

11 Care Information Broker functions Forward query to source HC systems and combine results Act Registry (national) patient ID xxx type of information DISP info source (system) yyy Optional: date/time of info dd/mm/yy unique act ID zzz Care Provider Registry Identification & Authentication of users based on national care provider ID (called UZI) Authorisation Logging (gateway for) patient identification Verification of national patient ID (called BSN) Process updates from healthcare systems Process queries from healthcare systems Process queries from healthcare systems Process queries from healthcare systems Technical infrastructure based on (encrypted) VPN 11

12 Hoe werkt dat straks Hospital Hospital ZIM (Verwijsindex) PRESC GP1 PAT1 PRESC GP1 PAT2 PRESC HOSP1 PAT1 DISP PHARM1 PAT1 DISP PHARM2 PAT2 Huisartsen Elektronische Voorschriften Openbare Apotheken Aanmelding Verstrekkingen Verstrekkingsqueries 12

13 EMD Doelstelling voor fase I: Opvragen van medicatieverstrekkingen bij verstrekkende systemen (openbare apotheken, ziekenhuisapotheken, apotheekhoudende huisartsen) Doelstelling voor fase II: Verzenden van medicatievoorschriften tussen voorschrijvers en verstrekkers, gerouteerd via het LSP of direct geadresseerd via AORTA. Vervolg in de vorm van EMD plus: Contra-indicaties en andere medicatiebewakingssignalen, inclusief intoleranties/allergieën. 13

14 HL7 versie 3 specificaties voor het EMD Zijn behoorlijk stabiel sinds 2004, recente update in 2006 Uitgebreide domeinanalyse in overleg met zorgkoepels (NHG, KNMP, Orde, NVZA) Review met betrokken leveranciers Uiteindelijk vier essentiële interacties Voorschrift (= recept = MO) Verstrekking (= aflevering) Twee bijbehorende queries Beschreven in stijl van HL7 v3 ballot (HTML) Inmiddels ook beschikbaar als afdrukbare PDF Niet 100% gericht op exclusief gebruik van LSP, maar geschreven als algemene richtlijnen voor implementatie 14

15 Status van de implementatie Eerste diverse voortrajecten (versnellingsprogramma s, regionale oplossingen, etc.) Begin dit jaar: overdracht van coördinatie implementatie naar ministerie van VWS Vanaf 31 mei 2006: Proof of Concept, met daarin 5 leveranciers voor het domein EMD: ChipSoft (voorschrijver en klinisch verstrekker) Farmedvisie (klinisch verstrekker) VAL (ambulant verstrekker) Isala klinieken (voorschrijver) Infotechnology (ambulant verstrekker) 15

16 Verloop Proof of Concept Doel: Toetsen van de technische en functionele werking van het AORTA architectuurmodel met de daarbij opgestelde standaarden en specificaties voor het uitwisselen van EMD en WDH berichten tussen zorgsystemen. Scope/fasering: Inhoudelijke toetsing HL7 berichten Technische integratie (TIT) Functionele integratie (FIT) Regressietest Gebruikerstest (ETE) 16

17 Opzet van de HL7 analyse (voor voorschrijvers ) EMD Voorschrijver HIS/ZIS/HAP Berichtnaam Verwerking Bevindingen leverancier Bevindingen HL7 experts Opmerkingen Opvragen/verifiëren Patiënt Identificatie QUPA_IN Aanmaken Opleveren Patiënt Identificatie QUPA_IN Ontvangen en verwerken Opvragen Index QUMT_IN Aanmaken Opleveren Index QUMT_IN Ontvangen Opvragen Medicatieverstrekkingen QURX_IN NL Aanmaken Opleveren Medicatieverstrekkingen QURX_IN NL Ontvangen 17

18 Opzet van de HL7 analyse (voor verstrekkers ) EMD Verstrekker AIS/ZAIS Berichtnaam Verwerking Bevindingen leverancier Bevindingen HL7 experts Opmerking en Opvragen/verifiëren Patiënt Identificatie QUPA_IN Aanmaken Opleveren Patiënt Identificatie QUPA_IN Ontvangen en verwerken Aanmelden Gegevens MFMT_IN Aanmaken Heraanmelden Gegevens MFMT_IN Aanmaken Afmelden Gegevens MFMT_IN Aanmaken Opvragen Index QUMT_IN Aanmaken Opleveren Index QUMT_IN Ontvangen Opvragen Medicatieverstrekkingen QURX_IN990011NL Aanmaken, ontvangen en verwerken Opleveren Medicatieverstrekkingen QURX_IN990013NL Aanmaken en ontvangen 18

19 Aandachtspunten proces Wat moet je opleveren als een Verstrekkingsquery wordt gesteld? Uitgangspunt is volledige verstrekkingshistorie indien alleen BSN nummer als parameter wordt meegegeven. Filtering is mogelijk (door de vrager) o.b.v. actualiteit. Wenselijk is vlag of filter o.b.v. bronsysteem (om te voorkomen dat je je eigen data terug krijgt via LSP). Wie bepaalt wat volledig is? Praktijk kan zijn dat dit beperkt is tot actuele medicatie of de actuele medicatie plus een beperkte historie. Bij migratie van OZIS regio is dit (tijdelijk) acceptabel. Lijn voor de toekomst is: geen filtering bij de bron. 19

20 Aandachtspunten proces Belangrijk is dat een verstrekkende partij alleen die verstrekkingen rapporteert waarvoor het zelf het bronsysteem is (d.w.z. dat de informatie daar ontstaan moet zijn en niet in het kader van dienstwaarneming moet zijn overgenomen). een dienstwaarneemapotheek moet zelf de verstrekkingen rapporteren die het in het kader van dienstwaarneming heeft verstrekt een thuisapotheek moet die verstrekkingen die tijdens dienstwaarneming zijn verstrekt, niet rapporteren (om dubbelen te voorkomen) 20

21 Aandachtspunten proces (klinische verstrekking) In het geval van een klinische patiënt is er sprake van een verstrekking op het moment dat de ziekenhuisapotheek een voorschrift bevestigt. Dit kan zelfs betekenen dat de toediening heeft plaatsgevonden vanuit de afdelingsvoorraad. In tegenstelling tot bij ambulante verstrekkingen is er niet sprake van een vaste verstrekte hoeveelheid: MO loopt tot deze gestaakt wordt Ook lopende MO s kunnen echter relevant zijn, bijv. bij verlofpatiënten die bij huisartspost komen 21

22 Aandachtspunten proces (prefetching) In het geval van prefetchen wordt een Verstrekkingsquery vooraf uitgevoerd: door een spreekuurassistent of geautomatiseerd o.b.v. BSN nummer (mag dit?) en opgeslagen in een lokale cache. Hierbij spelen twee autorisatievragen: Moet een UZI pas in het systeem zitten tijdens een prefetch? Ja, elke query moet te herleiden naar een (op dat moment) aangemelde UZI pas houder (niet o.b.v. systeemcertificaat). Mag iedere gebruiker de opgeslagen medicatiehistorie inzien? Ja en nee, de opvragende UZI pas houder is verantwoordelijk voor alle inzage van n.a.v. de query opgeslagen gegevens (cache = query resultaat). 22

23 HL7 v3 = XML: Validatie tegen schema s Bij de medicatieberichten hoort een aparte (sinds april) bevroren set XML schema s. De ontvanger moet er van uit kunnen gaan dat de verzender alleen gevalideerde berichten verstuurt (en kan dit checken). Schemavalidatie checkt alleen structuur (incl. cardinaliteit), maar geen identificatie, codering en gegevensinhoudelijke zaken. Hiertoe zijn wel scripts opgezet, die een foutrapportage opleveren voor een bericht. 23

24 HL7 v3: De on-line testtool 24

25 Implementatie: Transformatie van XML via XSLT Voordeel van XML is dat het eenvoudig te transformeren is naar een ander formaat. Hiervoor worden XSLT stylesheets gebruikt. Deze worden o.a. toegepast in gateways: Tussen HL7 v3 berichtvarianten (versies) Tussen HL7 v3 en bijv. EDIFACT berichten Ook binnen applicatie toepasbaar als patch : Als quick-fix bij migratie naar nieuwe versie. In LSP als er straks parallelle versies zijn! NICTIZ levert dergelijke XSLT patches bij updates. 25

26 Implementatie: Omzetting tussen tabel 25 en HL7 Is lastig, maar absoluut te doen. Versnellingsprogramma in Haarlem heeft 95% dekking van tabel 25 naar HL7 v3, zolang je maar geen enge b codes toepast gebruik van vrije tekst als fallback (altijd!) 95% dekking van HL7 v3 naar tabel 25: bij gebruik van vaste GTS structuren met verlies van specifieke toedientijden met verlies van intervalschema s met max. 3 aparte deelinstructies gebruik van vrije tekst als fallback (altijd!) Stylesheets zijn beschikbaar (public domain) 26

27 Inhoudelijke issues EMD (bijzonderheden klinische medicatie) Wat is een verstrekking in de klinische context? Een door de ziekenhuisapothe(e)k(er) bevestigde klinische medicatieopdracht! Losser maken van verplichting om feitelijk verstrekte hoeveelheid door te geven (wordt nu vaak achteraf berekend bij klinische medicatie). Verwachte gebruiksperiode is lang niet altijd bekend, o.a. bij open ended klinische MO s (net als bij ambulante zo nodig recepten). Wat scheidt verstrekkingen van elkaar? Is er een verstrekking per uitgedeelde dosis? Per doseerinstructie? Per opname per medicatie? 27

28 Inhoudelijke issues EMD (doseerinstructies: GTS = General Timing Specification) Diverse mogelijkheden om zelfde schema door te geven (= taal i.p.v. vast formaat). Dit is niet erg voor de zender (maakt zelf keuze), maar erg lastig voor ontvangers (deze moet alle formaten herkennen ). Zelfde probleem speelt bij vertaling naar tabel 25, want die vergt ook herkenning van alle mogelijke (klinische) schema s. 28

29 Inhoudelijke issues EMD (doseerinstructies: GTS = General Timing Specification) Voorstel is om voor alle gangbare doseerschema s vaste patronen af te spreken. Gevolg is dat zender zich aan deze vaste patronen moet houden, maar dat ontvanger dus ook minder variaties hoeft te herkennen. Bijbehorende tabel 25 transformaties (XSLT) worden compleet gemaakt kunnen alle geldige variaties omzetten, en ongeldige variaties worden geweigerd met foutmelding. Transformatie moet ook 100% dekkende omzetting van en naar tabel 25 codes omvatten. 29

30 Voorbeeld van regionale initiatieven o.b.v. HL7 v3 Regionaal EMD West-Friesland 30

31 31

32 Een OZIS regio als GBZ? Regionaal LSP Goed Beheerd Zorgsysteem (GBZ) Apotheek Landelijk HL7 versie 3 OZIS Gateway EDIFACT Apotheek Apotheek Apotheek 32

33 Lessen uit het traject tot nu toe Betrek leveranciers continu bij ontwikkeling er zijn nu regelmatig bijeenkomsten Werk met een beperkt aantal pilottrajecten beheersbare afhandeling restpunten Zorg voor haalbare technische vereisten en versoepel eisen eventueel tijdelijk om stapsgewijze migratie mogelijk te maken Behoud een sfeer van constructieve samenwerking met het veld 33

34 Vragen 34