HL7 versie 3 Medicatieberichten t.b.v.. AORTA (a.k.a. BEMO) Tom de Jong

Transcriptie

1 HL7 versie 3 Medicatieberichten t.b.v.. AORTA (a.k.a. BEMO) Tom de Jong

2 Opzet van deze presentatie Proces: BEMO HL7 versie 3 berichtspecificaties Storyboards en het procesmodel Aandachtspunten proces Data: Het gebruik van de wrappers De opbouw van de payload Verstrekkingsgegevens (beoogd en feitelijk) Medicatiegegevens (incl. magistrale receptuur) Voorschriftgegevens (incl. verwijzing daarnaar) Gebruiksinstructies (incl. doseringsschema) Coderingssystemen XML: Het gebruik van Object Identifiers Validatie tegen schema s De on-line testtool Implementatie: Transformatie van XML via XSLT Omzetting tussen tabel 25 en HL7 Gebruik van gateways naar OZIS

3 BEMO HL7 versie 3 berichtspecificaties v2.2 van sept. 2004, update v2.4 van november 2005 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

4 De vier basisinteracties Het Voorschriftbericht (PORX_IN932000NL) Van voorschrijver (arts) naar verstrekker (apotheek) Gaat samen met aanmelding gegevenssoort PRESC bij verwijsindex van het LSP Het Verstrekkingsbericht (PORX_IN924000NL) Van verstrekker (apotheek) naar geïnteresserde Gaat samen met aanmelding gegevenssoort SUBSUP bij verwijsindex van het LSP De Voorschriftquery (QURX_IN990001NL) en het antwoord erop (QURX_IN990003NL) Wordt vooral belangrijk bij ophalen ongeadresseerde voorschriften Wordt mogelijk gecombineerd met Verstrekkingsquery (één result set) De Verstrekkingsquery (QURX_IN990011NL) en het antwoord erop (QURX_IN990013NL) Komt overeen met het ophalen van het medicatieprofiel (historie) Meest essentiële interactie bij eerste fase medicatiedossier

5 Waarom nog niet meer interacties? Het is al moeilijk genoeg om het geregeld te krijgen met de vier gekozen basisinteracties. Mutaties op lopende voorschriften zijn al foutgevoelig in een gesloten omgeving, maar nog lastiger in een gedistribueerde omgeving. Uitbreidingen volgen begin volgend jaar: Intoleranties, allergieën, contra-indicaties, (afgehandelde) medicatiebewakingssignalen, adverse events (incidenten) Mutaties op lopende voorschriften (staken, wijzigen) Toedieningsberichten, incl. entadministratie Verdere ondersteuning van klinische interacties

6 Aandachtspunten proces Verstrekkingsquery (result set) 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. Belangrijke factor is of er sprake is van OZIS gateway. Lijn voor de toekomst is: geen filtering bij de bron.

7 Aandachtspunten proces Verstrekkingsquery (bronsysteem) 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)

8 Aandachtspunten proces Verstrekkingsquery (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. Het moment van (potentieel) aanmelden bij de VWI is ook het moment waarop het gerapporteerd kan worden in de query response.

9 Aandachtspunten proces Verstrekkingsquery (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).

10 Aandachtspunten proces Verstrekkingsquery (foutmeldingen) Wat is antwoord als er geen gegevens zijn? De query acknowledgement bevat NF i.p.v. OK. Het aantal geretourneerde antwoorden is 0. En als je geen toestemming hebt? Query acknowledgement is AE (application error). De DetectedIssueEvent bevat de code NAT. En als het bronsysteem niet benaderbaar is? Of als het de gegevens niet heeft? Query acknowledgement is AE (application error). Nog geen specifieke codes voor DetectedIssueEvent. Details staan (tekstueel) in AcknowledgementDetail.

11 Aandachtspunten proces Voorschriftbericht (routering via LSP) LSP fungeert als router voor voorschriften. Een voorschrijvend systeem hoeft alleen het netwerkadres van de LSP te kennen, plus een manier om de juiste ontvanger te identificeren (dit is de apotheek en niet een specifieke apotheker of een applicatie). Dit kan zelfs voor intramurale voorschriften (dus binnen hetzelfde ziekenhuis).

12 Aandachtspunten proces Voorschriftbericht (terugkoppeling) Aflever/verstrekkingsbericht n.a.v. voorschrift is strikt genomen niet nodig in pull model, aangezien actuele status altijd via LSP kan worden opgevraagd. Indien een verstrekkend systeem dit echter wel wil ondersteunen, dan moet dit buiten het LSP om geregeld worden.

13 Aandachtspunten proces Voorschriftbericht (audit trail) De Control Act is belangrijk voor transactiegebonden informatie, die gebruikt wordt om een audit trail bij te houden van het object (voorschrift) bij revisies. Mutatieberichten op lopende voorschriften worden nog niet ondersteund! Dit betekent dus ook dat de meerwaarde van de Control Act nu nog beperkt is.

14 Storyboards en het procesmodel (uitgangspunten) Wat is er nodig voor fase I? Strikt genomen: alleen Verstrekkingsquery via LSP. In de praktijk eisen koplopers vaak ook implementatie Voorschriftbericht (geadresseerd aan apotheek). Uitgangspunten voor deze beschrijving: Voorschriftbericht wordt via LSP gerouteerd. Verstrekkingsbericht is optioneel en loopt niet via LSP. Intramurale communicatie loopt niet via LSP. Aanmelding bij LSP kan zowel categoraal (eenmaal per bron per gegevensoort per patiënt) als atomair zijn.

15 Storyboards en het procesmodel (1 e lijn) (Nieuwe) patiënt komt bij huisarts: Huisarts haalt Verstrekkingshistorie op (leeg) bij LSP Huisarts verstuurt Voorschriftbericht naar apotheek (via LSP) Huisarts meldt gegevensoort PRESC aan bij VWI Patiënt komt bij de (openbare) apotheek: Apotheek haalt Verstrekkingshistorie op (leeg) bij LSP Apotheek verwerkt het Voorschriftbericht en levert af (Apotheek verstuurt Verstrekkingsbericht naar huisarts (direct)) Apotheek meldt gegevenssoort SUBSUP aan bij VWI (Huisarts verwerkt het Verstrekkingsbericht in het HIS)

16 Storyboards en het procesmodel (poliklinisch) Patiënt komt bij specialist: Assistent(e) dokter A doet van te voren Verstrekkingsquery (met afgeleverd medicijn uit 1 e lijn) Patiënt wordt doorverwezen: Assistent(e) dokter B doet van te voren Verstrekkingsquery (mogelijk nieuwe medicijnen uit de 1 e lijn) Dokter B verstuurt Voorschriftbericht naar apotheek (via LSP) EVS meldt gegevenssoort PRESC aan bij VWI Patiënt komt bij (openbare) apotheek: Apotheek haalt Verstrekkingshistorie op bij LSP Apotheek verwerkt het Voorschriftbericht en levert af (Apotheek verstuurt Verstrekkingsbericht naar huisarts (direct)) (Apotheek verstuurt Verstrekkingsbericht naar dokter B (direct)) (Apotheek meldt gegevenssoort SUBSUP aan bij VWI) (Huisarts verwerkt het Verstrekkingsbericht in het HIS) (Dokter B verwerkt het Verstrekkingsbericht in het EVS)

17 Storyboards en het procesmodel (dagbehandeling) Patiënt gaat in dagbehandeling (bijv. cytostatica): Assistent(e) dokter B doet van te voren Verstrekkingsquery Dokter B voert klinische MO in ( Voorschriftbericht van EVS naar ziekenhuisapotheek) (EVS meldt gegevenssoort PRESC aan bij VWI) Verwerking in de ziekenhuisapotheek: Apotheek haalt Verstrekkingshistorie op bij LSP Apotheek bevestigd de MO en levert (t.z.t.) af ( Verstrekkingsbericht van ziekenhuisapotheek naar EVS) ZAIS meldt gegevenssoort SUBSUP aan bij VWI (Dokter B verwerkt het Verstrekkingsbericht in het EVS)

18 Storyboards en het procesmodel (tijdens opname) Patiënt wordt opgenomen: In-take verpleegkundige haalt Verstrekkingsquery op bij LSP Drie opties voor lopende medicatie: Medicatie wordt gestaakt: nog geen HL7 v3 bericht gespecificeerd Dokter C voert klinische MO in ( Voorschriftbericht van EVS naar ziekenhuisapotheek) Medicatie wordt in eigen beheer gebruikt (mag eigenlijk niet) Dokter C voert klinische MO in voor lopend én nieuw medicijn ( Voorschriftberichten van EVS naar ziekenhuisapotheek) (EVS meldt gegevenssoort PRESC aan bij VWI) Verwerking in de ziekenhuisapotheek: Apotheek haalt Verstrekkingshistorie op bij LSP Apotheek bevestigd de MOs en levert (t.z.t.) af ( Verstrekkingsbericht van ziekenhuisapotheek naar EVS) (ZAIS meldt gegevenssoort SUBSUP aan bij VWI) (Dokter B verwerkt Verstrekkingsberichten in het EVS) Etc. tijdens opname (nog geen mutatieberichten)

19 Storyboards en het procesmodel (bij verlof of ontslag) Patiënt gaat met verlof en komt in weekend bij HAP: Huisarts haalt Verstrekkingsquery op bij LSP (incl. klinisch verstrekte medicatie!) Patiënt wordt uiteindelijk ontslagen: Alle klinische MOs worden gestaakt (geen HL7 v3 berichten, maar bij query wel zichtbaar voor vrager) Drie opties voor opgeschorte medicatie: Medicatie wordt gestaakt: nog geen HL7 v3 bericht gespecificeerd Medicatie wordt doorgebruikt (evt. in aangepaste vorm): idem Dokter C verstuurt Voorschriftbericht naar openbare apotheek (EVS meldt gegevenssoort PRESC aan bij VWI) Patiënt komt bij (openbare) apotheek: Etc. etc.

20 Wat gaat er (potentieel) over de lijn (= AORTA)? Huisarts Informatie Systeem Apotheek Informatie Systeem Landelijk Schakel Punt Ziekenhuis Apotheek EVS Eerste lijn Huisartsconsult Poliklinisch consult Dagbehandeling Opname Verlof (bezoek aan HAP) Ontslag Verstrekkingsquery (QURX_IN990011NL) Antwoord hierop (QURX_IN990013NL) Voorschriftbericht (PORX_IN932000NL) ZIM update met gegevenssoort PRESC Verstrekkingsbericht (PORX_IN924000NL) ZIM update met gegevenssoort SUBSUP Ziekenhuis

21 Het gebruik van de wrappers (algemeen) Elk HL7 v3 bericht heeft volgende structuur: <QURX_IN990011NL> && interactie && transmission wrapper <receiver/> <sender/> <ControlActProcess> && trigger event control act <authororperformer/> <subject> && payload (message type) </subject> </ControlActProcess> </QURX_IN990011NL>

22 De transmission wrapper bij het Voorschriftbericht <QURX_IN932000NL> && interactie (voorschrift) <receiver> <device> <id extension= 1 root= /> <name>landelijk Schakel Punt</name> <agencyfor> <representedorganization> <id extension=uzi_abon2 root=" /> <name>de Verstrekkende Apotheek</name> </representedorganization> </agencyfor> </device> </receiver> <sender> <device> <id extension=uzi_sys root=" /> <name>het Elektronisch Voorschrijf Systeem</name> <agencyfor> <representedorganization> <id extension=uzi_abon1 root=" /> <name>de Voorschrijvende Organisatie</name> </representedorganization> </agencyfor> </device> </sender>

23 De Trigger Event Control Act wrapper Verschillende participanten aanwezig: AuthorOrPerformer (verplicht) DataEnterer (optioneel, door wie ingevoerd?) Overseer (nieuw, i.v.m. verlengde arm ) Soms informatie dubbelop in het bericht: Bij Voorschriftbericht voorschrijver (author) Bij Verstrekkingsbericht verstrekker (performer) Hier is transactieinformatie (control act) gelijk aan de (persistente) objectgebonden informatie

24 De query parameters Gegevenssoort wordt bepaald door de aard van de interactie. Query parameters (patiënt. interval) vormen payload van query. LSP kijkt dus alleen in het geval van query in de payload (want moet kunnen selecteren op patiënt en evt. actualiteit). Verder is het LSP vooral doorgeefluik van query en resultaten. queryid statuscode patientid effectivetimeinterval verplicht en uniek active verplicht, BSN optioneel

25 De opbouw van de payload (algemeen) Structuur is afhankelijk van entry point in het model (R-MIM) van het message type In het algemeen geldt: structuur van payload Voorschrift/Verstrekkingsbericht is gelijk aan structuur van antwoord op bijbehorende query (maar andere interactie, want andere wrappers) Bij voorschrift/verstrekking: betreft één medicatie voor één patiënt in elk bericht Bij antwoord op queries: payload herhaalt voor elk gevonden voorschrift/verstrekking

26 De verstrekking (=aflevering) (MedicationDispenseEvent) in Verstrekkingsbericht en antwoord op Verstrekkingsquery id verplicht en uniek statuscode completed effectivetime moment van verstrekking (klinisch = bevestiging MO) quantity afgeleverde hoeveelheid (incl. vertaling naar thes. 2) expectedusetime verwachte gebruiksduur repeatnumber aantal resterende iteraties performer verplicht ID apotheker/assistent verplicht ID apotheek (URA/AGB) optioneel naam/adres apotheek responsibleparty ID apotheker

27 id statuscode effectivetime quantity expectedusetime repeatnumber performer Het verstrekkingsverzoek (MedicationDispenseRequest) in het Voorschriftbericht optioneel (niet zinvol) active niet gebruiken af te leveren hoeveelheid (evt. vertaling naar thes. 2) verwachte gebruiksduur aantal toegestane iteraties optioneel

28 De verstrekte cq. te verstrekken medicatie (MedicationKind) code verplicht aanwezig (niet per se gevuld) in Voorschriftbericht: GPK, PRK of HPK primair in Verstrekkingsbericht: Z-Index artikelnr. primair optioneel: omschrijving (displayname) bij primaire code optioneel: vertaling (translation) naar secundaire codes Wat te doen bij magistrale receptuur (inclusief nummers)? Twee opties: <code nullflavor= NA displayname= /> <code code=eigen_code codesystem=oid_eigen_codes/> Essentie is dat er onderscheid is met een echte code. <desc>een omschrijving van de magistrale samenstelling en/of bereiding, eventueel met carriage returns/line feeds of zelfs tabs.</desc>

29 Het voorschrift (Prescription) id verplicht gevuld in Voorschriftbericht verplicht aanwezig in Verstrekkingsbericht indien niet bekend: nullflavor= UNK (vaak het geval bij verstrekkingshistorie) statuscode= active subject Patient Person id verplicht gevuld (nu nog lokaal, straks BSN) rest optioneel (adres, naam, geslacht, geboortedatum) zie XML voorbeeld voor toepassing attributen author AssignedPerson time verplicht gevuld in Voorschriftbericht verplicht aanwezig in Verstrekkingsbericht (indien niet bekend: nullflavor= UNK ) id verplicht gevuld (nu nog AGB, straks UZI)

30 De gebruiksinstructies (MedicationAdministrationRequest) text niet verplicht, maar altijd nuttig interpretatie van het gebruik door zendende systeem indien dosering ook gecodeerd aanwezig: secundaire info indien niet te coderen: garantie dat betekenis behouden blijft statuscode active effectivetime alles m.b.t. tijd (looptijd/doseerschema) dosequantity doseerhoeveelheid routecode toedieningsweg (optioneel, G-Standaard) support2 aanvullende instructies precondition zo nodig gebruik Wanneer zijn er meerdere herhalingen van MedAdmReq? Wisselende doseerschema s/hoeveelheden in de tijd (opbouw/afbouw) Wisselende randvoorwaarden (bijv. 2-4 maal daags = 2x + 2x zo nodig) In de toekomst: meerdere opties voor toediening (bijv. afh. van toed.weg)

31 Hoe vul je attribuut effectivetime? GTS: taal voor definitie van tijdsverzameling Gebruikt set operatoren: A, I, E Illustratie aan de hand van voorbeelden: alleen looptijd alleen frequentie allebei vaste tijden intervalschema

32 Hoe vul je attribuut dosequantity? Primaire aanduiding komt altijd uit UCUM (hierin bestaan geen telbare eenheden) Vertaling (translation) mogelijk m.b.v.: G-Standaard thesaurus tabel 2 (basiseenheden) Tabel 25 a codes (eenheden gebruiksadvies) Juiste interpretatie is hier essentieel: meest voorkomende bron van miscommunicatie

33 Hoe ga je om met variabele dosering? m1-m2 x per dag n1-n2 tabletten: gebruik van IVL<PQ> binnen dosequantity (wisselende doseerhoeveelheid: n1-n2 tabletten) opsplitsen van doseerinstructie in 2 herhalingen (m1-m2 x m1 x vast + m2-m1 x zonodig) Illustratie aan de hand van voorbeeld

34 Aanvullende instructies en precondities In principe allebei gebaseerd op b codes van tabel 25 (aanvullende gebruiksteksten) Uitgesplitst in verschillende categorieën Bewaarinstructies (niet gebruiken) Gebruiks/toedieningsinstructies Precondities Aanvullende instructie kan ook met nullflavor= NA en omschrijving in displayname Preconditie met nullflavor= NA betekent per definitie zo nodig zonder verdere specificatie

35 Coderingssystemen Waar mogelijk wordt overal gebruik gemaakt van tabellen uit G-Standaard (synchronisatie vereist) GPK/PRK/HPK/artikelnr. (MedicationKind.code) toedieningswegen (routecode) basiseenheden (quantity/dosequantity) NHG tabel 25 codes alleen gebruikt voor: b codes voor aanvullende instructies en precondities a codes als translation voor dosequantity ATC codes voor ingrediënten EAN codes voor verpakkingen

36 XML: Het gebruik van Object IDentifiers OIDs worden gebruikt voor aanduiding van: Identificatiesystemen OID is de root BSN register UZI persoonsregister " " UZI systeemregister " " UZI abboneeregister " " Identificatie acts (bericht IDs, query IDs, lokaal (deel)voorschriftnrs., verstrekkingsnrs.) gedefinieerd Coderingsystemen OID is codesystem G-Standaard (incl. tabel 25) vaste OIDs (zie tabel)

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

38 XML: De on-line testtool Demonstratie van

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

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

41 Vragen