Digitaal aanvragen van PAMM-‐onderzoeken bij Máxima Medisch Centrum
Digitaal aanvragen van PAMM-‐onderzoeken bij Máxima Medisch Centrum
van Christine van der Aa 5 september 2014
One year project presented to Eindhoven University of Technology towards the degree of Professional Doctorate in Engineering in Design and Technology of Instrumentation
A catalogue record is available from the Eindhoven University of Technology Library ISBN: 978-‐90-‐444-‐1329-‐8 (Eindverslagen Stan Ackermans Instituut ; 2014/071)
Samenvatting
Het project Digitaal Aanvragen PAMM heeft als doel het realiseren van een volledig digitale orderkoppeling vanuit Ezis, het EPD van het Máxima Medisch Centrum (MMC), naar de informatiesystemen van de Stichting PAMM. Stichting PAMM is een laboratorium voor aanvullend onderzoek op het gebied van pathologie en medische microbiologie, en staat los van het MMC. Het MMC laat dit aanvullende onderzoek door de PAMM uitvoeren. Digitaal aanvragen is onderdeel van ordermanagement, zoals hieronder gevisualiseerd. Het beslaat het bovenste deel, het indienen van de aanvraag door de aanvrager, het ontvangen daarvan bij de uitvoerder, en het uitwisselen van de orderstatus tussen beide systemen.
Het project valt uiteen in twee deelprojecten. Het eerste omvat het ontwerp van de architectuur voor de benodigde orderkoppelingen. Daarnaast heb ik een analyse gemaakt van het (halfdigitale) aanvraagproces zoals het op dit moment is vormgegeven. Voor het gehele project ben ik als projectleider opgetreden, en heb ik in de rol van architect meegewerkt aan het ontwerp. Ontwerp architectuur orderkoppelingen Digitaal aanvragen van PAMM-‐onderzoeken vergt drie verschillende orderkoppelingen, voor de aanvragen ten behoeve van onderzoek naar pathologie, bacteriologie en virologie, en serologie en bloedkweek. De orderkoppelingen voor pathologie en serologie en bloedkweek lopen tussen MMC en PAMM, en het ontwerp daarvoor volgt in grote lijnen het schema hierboven. Dit ontwerp wordt gerealiseerd door de implementatie van de best practices van Chipsoft voor deze aanvraagtypen. Bij serologie en bloedkweek is het onderzoeksmateriaal bloed. Bloedafname wordt grotendeels uitgevoerd door het Klinisch Lab (KL). Bij dit type aanvragen zijn dus drie partijen betrokken. In het ontwerp wordt een order uitgestuurd van Ezis naar Labosys (informatiesysteem van het KL), resulterend in bloedafname. Bij aanmelden van het materiaal in Labosys wordt de order doorgestuurd naar Molis (informatiesysteem van de PAMM). Hiervoor is een interlabkoppeling tussen Labosys en Molis nodig; deze zal door Philips gebouwd worden. Implementatie van de drie orderkoppelingen gaat in september van start. Analyse inrichting aanvraagproces In 2013 is reeds een halfdigitaal aanvraagproces voor PAMM-‐onderzoeken ingericht en in productie genomen bij enkele pilotafdelingen. De gebruikers kunnen een aanvraag digitaal indienen in Ezis, maar de order moet handmatig bij de PAMM van een werklijst in Ezis gehaald worden in ingevoerd worden in Molis. Dit proces heb ik bij alle betrokken afdelingen en organisaties onderzocht. De bevindingen hebben geresulteerd in een advies voor herinrichting van het proces, waarbij de handelingen rond het aanvragen, etiketteren en afnemen van materiaal fysiek zoveel mogelijk bij elkaar worden gehouden. Idealiter gaat dit gepaard met een systeem voor eenduidige identificatie van zowel patiënt als zorgverlener.
1
Inhoudsopgave
1 Inleiding ............................................................................................................................................................ 5 1.1 Doel van dit document .............................................................................................................................. 5 1.2 Leeswijzer .................................................................................................................................................. 5 1.3 Aanleiding en achtergrond van het project ............................................................................................... 6 1.4 Ordermanagement in een ziekenhuis ....................................................................................................... 7 1.4.1 Ordermanagement in essentie ........................................................................................................... 7 1.4.2 Ordermanagement in de context van PAMM-‐aanvragen bij het MMC ............................................. 7 2 Projectdefinitie ................................................................................................................................................. 9 2.1 Context ...................................................................................................................................................... 9 2.1.1 Het Máxima Medisch Centrum ........................................................................................................... 9 2.1.2 Het applicatielandschap ..................................................................................................................... 9 2.1.3 Betrokken organisaties en afdelingen ................................................................................................ 9 2.1.4 Scope en raakvlakken met andere projecten ................................................................................... 10 2.2 Projectdoelen .......................................................................................................................................... 10 2.2.1 Projectdoel: evaluatie pilot .............................................................................................................. 10 2.2.2 Projectdoel: functionele specificatie ................................................................................................ 10 2.2.3 Projectdoel: overige specificaties ..................................................................................................... 12 2.3 Projectorganisatie .................................................................................................................................... 12 2.3.1 Opbouw projectorganisatie .............................................................................................................. 12 2.3.2 Projectaanpak ................................................................................................................................... 13 3 Analyse inrichting digitaal aanvragen tijdens de pilot .................................................................................... 14 3.1 Evaluatie pilot .......................................................................................................................................... 14 3.2 Analyse inrichting digitaal aanvragen ...................................................................................................... 14 3.2.1 Inleiding ............................................................................................................................................ 14 3.2.2 Aanpak .............................................................................................................................................. 14 3.2.3 Aanvraagproces – basis en varianten ............................................................................................... 15 3.2.4 Processen en ervaringen bij uitvoerders (PAMM en KL) .................................................................. 16 3.3 Overzicht geconstateerde issues ............................................................................................................. 16 3.4 Conclusies en aanbevelingen inrichting aanvraagproces ........................................................................ 17 3.4.1 Organisatie ....................................................................................................................................... 17 3.4.2 Proces ............................................................................................................................................... 18 3.4.3 Informatie ......................................................................................................................................... 19 3.4.4 Applicatie .......................................................................................................................................... 20 3.4.5 Infrastructuur ................................................................................................................................... 21 3.5 De ideale situatie en de mogelijkheden in de praktijk ............................................................................ 21 4 Detaillering projectdoel: programma van eisen ............................................................................................. 23 4.1 Functionele eisen ..................................................................................................................................... 23 4.2 Niet-‐functionele eisen ............................................................................................................................. 23 4.3 Technische eisen ...................................................................................................................................... 24 4.4 Beheereisen ............................................................................................................................................. 24 5 Ontwerpen ..................................................................................................................................................... 25 5.1 Inleiding ................................................................................................................................................... 25 5.1.1 De werkwijze in fase 1 (pilot) ........................................................................................................... 25 5.1.2 Aanpak voor het ontwerpen van een architectuur voor de koppelingen ........................................ 25 5.2 Koppelingen voor aanvragen Pathologie en Bacteriologie en virologie .................................................. 26 5.3 Koppeling voor aanvragen serologie en bloedkweek .............................................................................. 27 5.3.1 RFC ingediend bij iZiekenhuis ........................................................................................................... 27 5.3.2 Koppeling SBK -‐ Ontwerp 1 ............................................................................................................... 27 5.3.3 Koppeling SBK -‐ Ontwerp 2 ............................................................................................................... 28 5.3.4 Koppeling SBK -‐ Ontwerp 3 ............................................................................................................... 29 5.4 Bevindingen andere ziekenhuizen ........................................................................................................... 29 5.5 Risicoanalyse ontwerpen ......................................................................................................................... 30 5.5.1 Koppeling SBK – Ontwerp 1 .............................................................................................................. 30
2
5.5.2 Koppeling SBK – Ontwerp 2 .............................................................................................................. 31 5.5.3 Koppeling SBK – Ontwerp 3 .............................................................................................................. 31 5.5.4 Koppeling SBK -‐ algemeen ................................................................................................................ 31 5.6 Keuze ontwerp ......................................................................................................................................... 32 6 Architectuurontwerp ...................................................................................................................................... 33 6.1 Detailontwerp PA en BV .......................................................................................................................... 33 6.2 Detailontwerp SBK ................................................................................................................................... 35 6.3 Risicoanalyse detailontwerp .................................................................................................................... 37 6.4 Business Case ........................................................................................................................................... 38 6.4.1 Projectresultaat ................................................................................................................................ 38 6.4.2 Kosten en inzet ................................................................................................................................. 38 7 Implementatie ................................................................................................................................................ 39 7.1 Technische implementatie ...................................................................................................................... 39 7.2 Functionele implementatie ..................................................................................................................... 39 8 Verificatie/validatie: vergelijk met programma van eisen ............................................................................. 40 8.1 Functionele eisen ..................................................................................................................................... 40 8.2 Niet-‐functionele eisen ............................................................................................................................. 41 8.3 Technische eisen ...................................................................................................................................... 42 8.4 Beheereisen ............................................................................................................................................. 42 9 Conclusies en aanbevelingen .......................................................................................................................... 43 9.1 Haalbaarheid ........................................................................................................................................... 43 9.1.1 Technisch .......................................................................................................................................... 43 9.1.2 Functioneel ....................................................................................................................................... 43 9.2 Behalen van projectdoelen ...................................................................................................................... 43 9.2.1 Kwaliteit van de aanvragen en verhogen efficiëntie ........................................................................ 43 9.2.2 Optimalisatie van het proces ............................................................................................................ 44 9.2.3 Gebruiksvriendelijkheid .................................................................................................................... 44 9.2.4 Werken volgens standaarden en onderhoud codetabellen ............................................................. 44 9.3 Oplossing knelpunten .............................................................................................................................. 44 9.4 MFN-‐ en ADT-‐koppelingen ...................................................................................................................... 44 10 Discussie ....................................................................................................................................................... 45 10.1 Gehanteerde aanpak ............................................................................................................................. 45 10.2 Projectorganisatie .................................................................................................................................. 45 10.3 Communicatie met de PAMM ............................................................................................................... 45 11 Relevantie ontwerp voor anderen ................................................................................................................ 46 12 Reflectie ........................................................................................................................................................ 47 12.1 Persoonlijke reflectie ............................................................................................................................. 47 12.2 Projectmanagement .............................................................................................................................. 47 12.3 Gebruikte kennis uit het curriculum ...................................................................................................... 48 12.4 Zorginformatie ....................................................................................................................................... 48 13 Referenties en gebruikte externe kennis ..................................................................................................... 49
3
Overzicht figuren
Figuur 1 Gehanteerde kleurcodering ...................................................................................................................... 5 Figuur 2 Ordermanagement in essentie .................................................................................................................. 7 Figuur 3 Ordermanagement bij MMC i.g.v. aanvragen Serologie en bloedkweek .................................................. 8 Figuur 4 Uitleg What’s new functie ....................................................................................................................... 11 Figuur 5 Projectorganisatie ................................................................................................................................... 12 Figuur 6 Aanvraagproces basis .............................................................................................................................. 15 Figuur 7 Aanvraagproces basis met actoren ......................................................................................................... 15 Figuur 8 Aanvraagproces klinisch SBK -‐ cito .......................................................................................................... 15 Figuur 9 Architectuurmodel Nictiz gegevensuitwisseling in de zorg ..................................................................... 17 Figuur 11 MFN-‐koppeling ...................................................................................................................................... 20 Figuur 12 Concept weergeven workflow ............................................................................................................... 21 Figuur 13 Typen PAMM-‐onderzoeken .................................................................................................................. 25 Figuur 14 Model orderuitwisseling PA en BV ........................................................................................................ 26 Figuur 15 Koppeling SBK – ontwerp 1 ................................................................................................................... 28 Figuur 16 Koppeling SBK -‐ ontwerp 2 .................................................................................................................... 28 Figuur 17 Koppeling SBK -‐ ontwerp 3 .................................................................................................................... 29 Figuur 18 Architectuurontwerp BV en PA ............................................................................................................. 33 Figuur 19 Actiediagram BV en PA .......................................................................................................................... 34 Figuur 20 Architectuurontwerp SBK ...................................................................................................................... 35 Figuur 21 Actiediagram SBK .................................................................................................................................. 36
4
1 Inleiding 1.1
Doel van dit document
Dit document is het eindverslag van het project "Digitaal Aanvragen PAMM", het digitaliseren van het aanvraagproces vanuit MMC voor aanvullend onderzoek bij de PAMM. Ik heb dit project uitgevoerd als jaarproject voor mijn opleiding tot Klinisch Informaticus. Deze ontwerpersopleiding heeft als doel mensen op te leiden voor het ontwerpen, optimaliseren en implementeren van informatieoplossingen in de zorg. Bij deze tweejarige opleiding hoort een jaarproject van een omvang van circa 1200 uur, waarin de trainee zowel de rol van ontwerper ("architect") als de rol van projectleider vervult.
1.2
Leeswijzer
In dit document beschrijf ik de aanpak van mijn jaarproject, en de behaalde resultaten op het gebied van architectuurontwerp voor de digitale orderkoppelingen en analyse van het aanvraagproces. Ook heb ik een aantal aanbevelingen voor de toekomst opgesteld. Het document sluit af met reflecties over het project en mijn rol daarin, en mijn belangrijkste leerpunten. Kleurcodering In de figuren die in dit verslag voorkomen worden voor de verschillende betrokken organisaties of afdelingen de volgende standaardkleuren gebruikt:
Figuur 1 Gehanteerde kleurcodering
Uiteraard hoort het Klinisch Laboratorium ook bij het MMC, maar het heeft een eigen kleur gekregen om het te kunnen onderscheiden van aanvragende afdelingen, die paars gekleurd zijn. Gebruikte afkortingen BV aanvullend onderzoek Bacteriologie & Virologie EPD elektronisch patiëntendossier HL7 Health Level 7, een internationale standaard voor elektronische uitwisseling van medische, financiële en administratieve gegevens tussen zorginformatiesystemen KL Klinisch Chemisch Laboratorium, ofwel Klinisch Lab LIS Laboratorium Informatie Systeem MMC Máxima Medisch Centrum NVZ Nederlandse Vereniging van Ziekenhuizen PA aanvullend onderzoek pathologie PAMM Stichting PAMM, Laboratorium voor Medische Microbiologie en Laboratorium voor Pathologie RDZ Referentiedomeinenmodel Ziekenhuizen SBK aanvullend onderzoek Serologie & Bloedkweek ZIS Ziekenhuis Informatie Systeem Ezis Elektronisch Ziekenhuis Informatie Systeem, dit is het ZIS annex EPD van Chipsoft
5
1.3
Aanleiding en achtergrond van het project
Al enige jaren bestaat de wens om de aanvragen voor onderzoeken bij de stichting PAMM (Laboratorium voor Pathologie en Bacteriologie en virologie) digitaal te laten verlopen. Dit past in de voortschrijdende digitalisering van alle ziekenhuiscommunicatie: na de invoering van het EPD (Ezis van Chipsoft) en het bouwen van digitale orderkoppelingen naar het Klinisch Laboratorium en de Radiologie is dit een logisch vervolg. 1 Hiertoe heeft in 2010 een vooronderzoek plaatsgevonden. Hierin worden voor het project twee fasen gedefinieerd. In de eerste fase wordt het mogelijk gemaakt om vanuit Ezis aanvragen te versturen. Deze worden op een werklijst voor de PAMM geplaatst, die de orders uitprint en middels een 2D-‐barcode invoert in Molis, het Laboratorium Informatiesysteem (LIS) voor Bacteriologie en virologie. Er is in deze fase dus nog geen sprake van een digitale orderkoppeling tussen beide systemen. De scope van deze eerste fase omvat de 2 aanvragen voor Serologie en bloedkweek (SBK) en voor Bacteriologie en virologie (BV) . In de tweede fase wordt een volledig digitale orderkoppeling voor alle drie de aanvraagtypen (SBK, BV en pathologie, PA) gerealiseerd; bij de inrichting van de eerste fase is al rekening gehouden met wat de gemaakte keuzes voor een tweede fase zouden betekenen. In 2013 is een project opgestart om de eerste fase bij een aantal pilotafdelingen in te voeren, met als 3 uiteindelijk doel deze werkwijze in het hele ziekenhuis uit te rollen. In het projectplan voor fase 1 is beschreven welke activiteiten er zijn uitgevoerd om tot een pilot te komen, en hoe de planning voor de pilot eruitziet. Deze pilot is in november 2013 van start gegaan bij de specialismen Kindergeneeskunde, Interne en MDL. Eind 2013 heeft een kort overleg ter evaluatie van de pilot plaatsgevonden. De conclusie was dat zich diverse knelpunten voordeden die niet meteen opgelost konden worden . Dit was aanleiding om deze halfdigitale werkwijze niet verder in het ziekenhuis uit te rollen, maar eerst de tweede fase op te starten. Hierin dienen de knelpunten geïdentificeerd en aangepakt te worden, onder andere door het ontwikkelen van een architectuur voor de digitale orderkoppelingen. Dit vervolgproject is mijn jaarproject geworden. In januari 2014 ben ik hiermee gestart. Het is mijn eerste ervaring als projectleider van een groot project met meerdere stakeholders. Ik heb hierbij gewerkt volgens de PRINCE2-‐methodiek voor projectmanagement. De projectmanagementdocumenten die hierbij opgeleverd zijn, zijn te vinden op Sharepoint. In dit project heb ik ook een architectenrol gehad. Ik heb onderzoek gedaan naar de mogelijkheden voor de digitale orderkoppelingen voor elk type aanvraag, resulterend in een architectuurontwerp. Dit ontwerp zal in het najaar van 2014 worden geïmplementeerd. Verder heb ik een analyse gemaakt van de huidige inrichting van het aanvraagproces. Op basis van deze analyse heb ik een aantal aanbevelingen ter verbetering opgesteld, aan de hand van het architectuurmodel voor interoperabiliteit van Nictiz.
1
PAMM_def.doc (R:\Zorg Informatie\Projecten ZI\Projecten\PAMM\fase 1 - pilot) Pathologie-aanvragen zijn bij de pilot nog niet meegenomen. Rond deze tijd is namelijk het Landelijk Bevolkingsonderzoek Darmkanker gestart. Het MMC heeft een module van Chipsoft aangeschaft om aan te kunnen sluiten bij ColonIS, het informatiesysteem van het LBO Darmkanker. De verwachting was dat met deze module alle pathologie-onderzoeken aangevraagd konden worden maar later bleek dit alleen voor endoscopisch onderzoek bedoeld te zijn. 3 Projectplan digitale PAMM aanvraag (R:\Zorg Informatie\Projecten ZI\Projecten\PAMM\fase 1 - pilot) 2
6
1.4
Ordermanagement in een ziekenhuis
1.4.1
Ordermanagement in essentie
Dit project betreft het digitaal aanvragen van aanvullend onderzoek. Dit is een onderdeel van ordermanagement. Het onderstaande plaatje toont hoe ordermanagement in de basis eruitziet.
Figuur 2 Ordermanagement in essentie
De aanvrager dient een aanvraag in, de uitvoerder voert het onderzoek uit en verstuurt het resultaat. Een aanvraag kan aanvullend onderzoek als radiologie-‐ of laboratoriumonderzoeken betreffen, maar ook verpleegkundige activiteiten of een policonsult kunnen aangevraagd worden. Een aanvraag wordt ingediend als onderdeel van een order. Een order kan aanvragen voor meerdere onderzoeken bevatten. Een orderbericht bevat daarnaast nog allerlei andere informatie, bijvoorbeeld gegevens over de aanvrager en diens organisatie, de uitvoerder, datum en tijd, patiëntgegevens, opname-‐ en medicatiegegevens. Om te waarborgen dat het resultaat ook gelezen wordt, moet een signaal naar de aanvrager gestuurd worden dat aangeeft dat het resultaat beschikbaar is. Intussen moet het aanvragende systeem op de hoogte gehouden worden hoe het met de afhandeling van de aanvraag staat. De uitvoerder moet deze orderstatus, bijvoorbeeld “verzonden”, “in bewerking”, “voltooid”, naar de aanvrager versturen. Bij "voltooid" kan een openstaande order afgesloten worden. Overigens worden de termen “aanvraag” en “order” regelmatig door elkaar gebruikt. In principe staat aanvraag voor een bepaald onderzoek dat een arts wil laten uitvoeren. Een order is het complete bericht dat verstuurd wordt om deze aanvraag uit te kunnen laten voeren. Naast de aanvraag (of aanvragen) bevat het onder andere informatie over de afzender, de geadresseerde, datum en tijd, NAW-‐gegevens van de patiënt, maar ook klinische gegevens als opnamedatum, diagnose of medicatie. In dit document wordt doorgaans over aanvraag gesproken in de betekenis van complete order. 1.4.2
Ordermanagement in de context van PAMM-‐aanvragen bij het MMC
Bij aanvragen voor aanvullend onderzoek op lichaamsmateriaal van de patiënt is bovenstaand plaatje niet toereikend. Het laat niet zien hoe de afname van materiaal tot stand komt. Bij PAMM-‐onderzoeken komt deze omissie vooral naar voren als het gaat om PAMM-‐onderzoek in bloed (serologie en bloedkweek). Bloedafname wordt bij het MMC door het Klinisch Lab uitgevoerd. Hiermee wordt dus een tweede "uitvoerder" geïntroduceerd, die ook een aanvraag moet ontvangen, namelijk om tot materiaalafname over te gaan. Dit maakt het plaatje meteen aanzienlijk gecompliceerder. Er zijn nu drie partijen, en dus systemen betrokken waartussen de ordercommunicatie geregeld moet worden, inclusief het bijhouden van de orderstatus. Daarnaast moeten aanvraag en materiaal ondubbelzinnig aan elkaar gekoppeld kunnen worden, binnen elk van die drie systemen.
7
Figuur 3 Ordermanagement bij MMC i.g.v. aanvragen Serologie en bloedkweek
Het huidige project richt zich alleen op de bovenste helft van de plaatje: de orderkoppelingen en de inrichting van het aanvraagproces. Het versturen van het resultaat en de notificatie daarvan middels een signaal zijn onderdeel van een ander project ("Waterdicht werken").
8
2 Projectdefinitie 2.1
Context
2.1.1
Het Máxima Medisch Centrum
Het MMC is met ruim drieduizend medewerkers, waaronder tweehonderd specialisten, het grootste medisch centrum in Zuidoost-‐Brabant. Het is gevestigd op twee locaties. In Eindhoven wordt de planbare en laagcomplexe zorg geleverd en zijn de themapoliklinieken gevestigd. In Veldhoven vinden complexe operaties, intensieve zorg en spoedeisende (hart)hulp plaats. Ook is hier een centrum voor zorg voor vrouw, moeder en kind gebouwd. Máxima Medisch Centrum is lid van de Vereniging Samenwerkende Topklinische opleidings Ziekenhuizen (STZ), een samenwerkingsverband van de twintig grootste opleidingsziekenhuizen in Nederland. Het heeft diverse topklinische functies toegewezen gekregen, waaronder de NICU, dialyse en derdelijns verloskunde. 2.1.2
Het applicatielandschap
Zoals bij veel ziekenhuizen telt het MMC veel verschillende applicaties. Men wil deze versnippering tegengaan door het invoeren van een aantal ICT-‐principes, namelijk "Microsoft, tenzij" en "Ezis, tenzij". In principe kiest men voor Microsoftproducten voor de infrastructuur, en voor modules van Ezis van Chipsoft voor zorginformatie, tenzij er overtuigende redenen zijn waarom dit niet kan. Deze keuzes moeten tot meer standaardisatie leiden, en uiteindelijk ook de beheerbaarheid verhogen. MMC beschikt al geruime tijd over een elektronisch patiëntendossier, de projectgroep EPD is al vanaf 2009 actief. Deze projectgroep is opgegaan in de afdeling Zorginformatie / Functioneel beheer. Er zijn al veel onderdelen van het zorgproces gedigitaliseerd, het huidige project is een onderdeel van het EPD-‐programma. 2.1.3
Betrokken organisaties en afdelingen
Diverse afdelingen en organisaties zijn bij dit project betrokken. Binnen het MMC gaat het om: Zorg Aanvragen voor de PAMM worden zowel vanuit de kliniek als vanuit de polikliniek gedaan. Zowel artsen als verpleegkundigen, doktersassistenten en polimedewerkers kunnen een aanvraag in Ezis invoeren. De logistieke afhandeling van het te onderzoeken materiaal wordt ofwel door de laatste drie groepen gedaan, ofwel door de patiënt zelf, of (in het geval van bloedafname) door het Klinisch Lab. Afdeling Zorginformatie Het beleid van het MMC is om zoveel mogelijk zorgprocessen in het EPD te digitaliseren. Digitaal aanvragen van PAMM-‐onderzoeken is hierin een van de laatste projecten, en is ook een wens van de PAMM (zie par. 2.2). De afdeling Zorginformatie heeft het project geïnitieerd, en levert de opdrachtgever en projectleider. De functioneel applicatiebeheerder van Ezis is verantwoordelijk voor het realiseren van de digitale aanvraagmogelijkheden in CS Order, en alle bijkomende technische en procesmatige ontwikkelingen. Klinisch Chemisch Laboratorium Het Klinisch Lab is bij de SBK-‐aanvragen betrokken doordat het de materiaalafname (bloed) verzorgt. Hiervoor is een order in Labosys, het LIS van het Klinisch Lab, nodig. De functioneel beheerder van Labosys maakt deel uit van het projectteam. Afdeling MIT Bij de afdeling Medische en Informatietechnologie is de koppelingenspecialist van MMC werkzaam. Hij is verantwoordelijk voor HL7-‐berichtdefinities en een correcte afstemming van de communicatie tussen de verschillende betrokken systemen. PAMM De stichting PAMM is een zelfstandige organisatie, het valt niet onder het MMC. Dit is de reden dat er geen sprake is van één Laboratorium Informatie Systeem. Het hoofd van de afdeling automatisering fungeert als projectleider voor hun kant van het project. De functioneel beheerders en applicatiebeheerders, en de medische administratie zijn betrokken bij de inrichting van hun LIS met betrekking tot de koppelingen. Voor de microbiologen en pathologen is de kwaliteit van de aanvragen van belang om hun werk optimaal te kunnen uitvoeren.
9
2.1.4
Scope en raakvlakken met andere projecten
De scope van het project was in het projectvoorstel als volgt gedefinieerd: -‐ Het realiseren van een volledig digitale aanvraag en orderkoppeling voor microbiologie, serologie en bloedkweken, en pathologie. Dit omvat onderzoek naar en ontwerp van de te ontwikkelen technische architectuur, en vervolgens implementatie hiervan. -‐ Een procesbeschrijving van de te volgen werkwijze. -‐ Uitrol van de nieuwe functionaliteit bij twee pilotafdelingen. -‐ Evaluatierapport van de eerste fase. Buiten scope was: -‐ Volledige implementatie ziekenhuisbreed. -‐ Digitalisering ENT-‐formulieren (in gebruik bij gynaecologie). -‐ Notificatie (uitslagberichtgeving) met behulp van What’s new knop. -‐ Decision support op basis van klinische gegevens en vraagstelling. Raakvlakken met andere projecten: -‐ Digitalisering pathologie-‐aanvraag voor het bevolkingsonderzoek darmkanker. Dit project wordt door een andere medewerker van Zorginformatie geleid. De resultaten daarvan op het gebied van de koppelingen kunnen bijdragen aan het ontwikkelen van de koppelingen voor het onderhavige project. -‐ Het project Waterdicht werken, dit betreft de notificatie aan een arts via de What's new knop (zie plaatje hieronder) dat er een resultaat beschikbaar is. -‐ Optimalisatie poliklinieken: doel van dit project is te zorgen voor een efficiencyslag. Het onderhavige project draagt hieraan bij.
2.2
Projectdoelen 4
Bij aanvang van het project waren de projectdoelen al grotendeels vastgelegd. In het projectvoorstel zijn deze 5 doelen en de beoogde aanpak van het project globaal beschreven, en verder uitgewerkt in het projectplan . De doelen vallen uiteen in drie delen: een evaluatie van de pilot uit de eerste fase, de functionele specificaties voor de tweede fase, en specificaties met betrekking tot standaarden en beheer. De evaluatie van de pilot is onderwerp van Hoofdstuk 3. Hierin komt ook de detailanalyse van de inrichting van het aanvraagproces van de pilot aan bod, met bijbehorende conclusies en aanbevelingen. De doelen op het gebied van specificaties worden verder uitgewerkt in de daaropvolgende hoofdstukken. 2.2.1
Projectdoel: evaluatie pilot
In dit traject moet een verslag opgesteld worden van de pilot, waarin de bevindingen worden gepresenteerd. Dit dient als uitgangspunt voor het vaststellen of een verdere uitrol mogelijk is, en aan welke randvoorwaarden dan voldaan moet worden. 2.2.2
Projectdoel: functionele specificatie
Kwaliteit van de aanvragen Het hoofddoel van dit project is het verbeteren van de patiëntveiligheid door het verhogen van de kwaliteit van de PAMM-‐aanvragen. Digitaal aanvragen ondervangt de volgende kwaliteitsproblemen van aanvragen op papier: -‐ Slechte leesbaarheid -‐ Ontbreken van klinische gegevens: Deze gegevens zijn van belang voor een optimale uitvoering van het aanvullend onderzoek. Aan de hand van deze context bepaalt een arts-‐microbioloog of en welke onderzoeken er nodig zijn. Als bijvoorbeeld niet bekend is dat er antibiotica zijn toegediend, kan bij een laag aantal bacteriën in een urinekweek onterecht besloten worden dat dit niet verder onderzocht hoeft te worden. Het niet leesbaar of incompleet invullen van het aanvraagformulier kan dus tot risico's voor de patiëntveiligheid leiden. Dit in tegenstelling tot gewone labonderzoeken bij het KL, waar deze gegevens niet nodig zijn. -‐ Ontbreken van de naam van de aanvragende arts. 4 5
Projectvoorstel DA_PAMM v1.1 PP_DA_PAMM_v0.3
10
Dit zorgt ervoor dat de What's new functie niet werkt, waarmee artsen van de uitslag van een onderzoek op de hoogte worden gesteld. Hiervoor moet de aanvrager bekend zijn en in de artsentabel van Ezis 6 voorkomen . Het borgen dat een resultaat daadwerkelijk wordt ingezien is onderdeel van een apart project, Waterdicht werken.
Figuur 4 Uitleg What’s new functie
Efficiëntie Een tweede doel is verhoging van de efficiëntie, zowel bij MMC als bij de PAMM. De volgende elementen kunnen bijdragen aan de efficiëntie: -‐ Er hoeven geen voorraden papieren formulieren aangehouden te worden, en bij actualisering opgehaald en vernietigd te worden. -‐ Aanpassing van elektronische formulieren kan veel eenvoudiger en sneller dan op papier. -‐ Patiëntgegevens hoeven bij de PAMM niet meer handmatig overgenomen te worden. -‐ Gegevens uit het artsenbestand hoeven niet meer handmatig overgenomen te worden. -‐ Aanpassen van een ingediende order is op papier niet mogelijk als formulier eenmaal verzonden is. Met digitale orders kan dat wel, tot order in behandeling is genomen. -‐ Met papieren orders kan PAMM geen overzicht genereren van de werkvoorraad. -‐ Er kunnen niet makkelijk ordersets aangemaakt of gewijzigd worden. Optimalisatie proces Op basis van de bevindingen van de pilot moet gekeken worden waar het proces verbeterd kan worden. De te ontwikkelen werkwijze moet helder en eenduidig zijn. Gebruiksvriendelijkheid Digitaal aanvragen biedt de volgende mogelijkheden: -‐ Aanvraagmogelijkheid op elke werkplek (formulieren zijn maar op enkele plaatsen beschikbaar). -‐ Overzicht van alle aangevraagde onderzoeken beschikbaar. -‐ Mogelijkheid tot opvolgen van de orderstatus. -‐ Minimaal dezelfde functionaliteit in digitale applicatie als met de papieren formulieren. -‐ Het gebruiksgemak van de applicatie moet zodanig zijn dat het geen fouten in de hand werkt. -‐ Het aanbieden van ordersets kan overwogen worden.
6
Evaluatie pilot whats new definitief (R:\Zorg Informatie\Projecten ZI\Projecten\Waterdicht werken)
11
2.2.3
Projectdoel: overige specificaties
Werken volgens standaarden 7,8 De ordercommunicatie dient volgens de berichtenstandaard HL7 v2.5 of hoger te verlopen. Alle systemen moeten daarvoor geschikt zijn. Vanaf versie 2.5 wordt OML (Laboratory Order Message) ondersteund, een berichttype in HL7 dat specifiek voor laborders ontwikkeld is. Ook het gebruik van Ezismodules is binnen het MMC een standaard. De aanvragen worden in Ezis gedaan, en 9 het Ezis-‐ordernummer is leidend. De standaard NEN7510 voor beveiliging van gegevensuitwisseling in de zorg is van belang omdat er sprake is van transmuraal berichtenverkeer. Onderhoud codetabellen Omdat er drie systemen bij dit berichtenverkeer betrokken zijn, is een procedure nodig om de codetabellen synchroon te houden. Als er vanuit de PAMM wijzigingen doorgevoerd moeten worden, moet dit afgestemd worden met het functioneel beheer van Ezis en van Labosys.
2.3
Projectorganisatie
2.3.1
Opbouw projectorganisatie
Bij de start van het project is de volgende projectorganisatie geformeerd:
Figuur 5 Projectorganisatie
7
ICT-standaarden in de zorg. Een praktisch overzicht. Nictiz, Den Haag Documentatie HL7 v2.4 – v2.6 9 NEN7510-2011 Medische informatica – Informatiebeveiliging in de zorg (okt 2011) 8
12
De stuurgroep is samengesteld uit vertegenwoordigers van de verschillende betrokken afdelingen / organisaties. Mark de Wette: projectmanager, Zorginformatie (opdrachtgever) Dirk Bakkeren: klinisch chemicus, Klinisch Lab (senior user) Jeroen Tjhie: arts-‐microbioloog, PAMM (senior user) John Stikkelbroeck: hoofd automatisering, PAMM (senior leverancier) Tijdens het project wordt op regelmatige basis de klankbordgroep geconsulteerd, bestaande uit verschillende typen users: artsen, verpleegkundigen, unithoofden, en baliemedewerkers, om verschillende aspecten van het proces uit te vragen en toe te lichten. De projectteams bestaan uit verschillende samenstellingen van onderstaande personen. Bij sommige teams is ook een lid van de stuurgroep aanwezig. Peter Verhaegh: functioneel applicatiebeheerder Ezis, Zorginformatie Peter Kerkhofs: informatietechnoloog, koppelingenspecialist, MIT Marcel de Vries: functioneel applicatiebeheerder Molis, PAMM Maria van de Ven: functioneel beheerder Molis, PAMM Casper Bastings: functioneel beheerder Molis, PAMM Frans van der Waals: functioneel applicatiebeheerder Sympathy, PAMM 2.3.2
Projectaanpak
Als projectleider heb ik gewerkt volgens de PRINCE2 projectaanpak. Er is een stuurgroep samengesteld met vertegenwoordigers uit de betrokken afdelingen of organisaties. Omdat we ons in eerste instantie vooral richtten op het ontwerpen van de technische koppelingen zijn eindgebruikers niet vertegenwoordigd in de stuurgroep of projectteams. Zij zijn wel op regelmatige basis geconsulteerd over hun wensen en ervaringen. Bij aanvang van de bouw en implementatie van de verschillende koppelingen zijn zij uitgenodigd om deel te nemen aan de projectteams. De stuurgroep is circa eens per maand samengekomen voor overleg. Het architectuurteam heeft gedurende de ontwerpfase ongeveer eens per twee weken overleg gehad, tot het ontwerp goedgekeurd was door de stuurgroep en voorgelegd kon worden aan de betrokken leveranciers. De overige projectteams gaan van start zodra begonnen wordt met de daadwerkelijke implementatie. Als voorzitter heb ik alle vergaderingen voorgezeten en voorzien van projectmanagementdocumentatie als agenda’s, notulen, voortgangsrapporten en afwijkingsrapporten. Als teamlid heb ik meegewerkt aan de ontwerpkeuzes voor de digitale koppelingen en de voor-‐ en nadelen van iedere keuze tegen het licht gehouden. Dit heb ik gepresenteerd aan de stuurgroep, met een advies voor de uiteindelijke ontwerpkeuze. Dit advies is overgenomen. Met teamleden uit de PAMM heb ik een inventarisatie gemaakt van de verschillende werkwijzen bij het aanvragen van PAMM-‐onderzoeken, en de issues die zich daarbij voordoen. Hiervan heb ik een analyse 10 gemaakt en gerapporteerd in een verslag . De resultaten van deze analyse worden in het volgende hoofdstuk behandeld.
10
Analyse inrichting digitaal aanvragen PAMM-onderzoeken
13
3 Analyse inrichting digitaal aanvragen tijdens de pilot Dit hoofdstuk bevat een analyse van de processen rond het digitaal aanvragen aan de gebruikerskant, bij het Klinisch Lab en de ervaringen bij de PAMM. Omdat dit aansluit bij het eerste projectdoel, de evaluatie van de pilot, is de analyse op deze plaats in het verslag opgenomen.
3.1
Evaluatie pilot 11
Het eerste projectdoel was het opstellen van een verslag waarin de pilot geëvalueerd werd . De eerste bevindingen waren zodanig dat al snel de conclusie is getrokken dat verdere uitrol met deze werkwijze (de halfdigitale koppeling uit fase 1) onwenselijk was. De belangrijkste reden daarvoor was een probleem met het gelijktijdig binnenkomen bij het Klinisch Lab van meerdere orders voor dezelfde prikronde. Voor de PAMM gaat dit om aanvragen voor serologisch onderzoek en bloedkweek (SBK). Deze zijn van hetzelfde ordertype als de aanvragen voor onderzoek bij het KL. Als er meerdere aanvragen binnenkomen voor dezelfde prikronde, voegt Labosys deze samen onder het ordernummer van de eerst binnengekomen aanvraag. Dit wordt gedaan om meerdere prikacties bij dezelfde patiënt te voorkomen: prettiger voor de patiënt, en van de NZa mag ook maar één ordertarief gerekend 12 worden . Het benodigde materiaal voor beide orders wordt vervolgens onder dit eerste ordernummer verzameld. Echter, als een tweede order PAMM-‐aanvragen bevat, komt dit onder dit tweede ordernummer in het LIS van de PAMM te staan, waardoor het niet meer met het materiaal gekoppeld kan worden. Daarnaast vormde het aanvragen van onderzoeken voor verschillende materialen in één order een knelpunt. Molis kan dit niet splitsen in deelorders, waardoor later binnengekomen materiaal ook niet meer met een order gekoppeld kan worden. Verder werd geconstateerd dat het etiketteren een probleem vormt. Dit betreft onder andere ontbrekende etiketten, verwisselingen, en zoveel over elkaar geplakte etiketten dat ze niet meer goed gescand kunnen worden. Het verslag van de evaluatie van de pilotfase beschrijft de knelpunten en problemen die toen naar voren kwamen in meer detail.
3.2
Analyse inrichting digitaal aanvragen
3.2.1
Inleiding
Bovenstaande bevindingen zijn door het architectuurteam meegenomen in de discussies over de meest geschikte architectuur voor de koppelingen. Het oplossen van de genoemde problemen was een belangrijk doel bij de uiteindelijke ontwerpkeuze. Na het vaststellen van het ontwerp was directe implementatie niet mogelijk vanwege beperkte capaciteit bij de betrokken leveranciers. Dit bood de gelegenheid om een bredere analyse van het hele aanvraagproces uit te voeren, om problemen te identificeren die meer te maken hebben met de organisatie, gehanteerde werkwijze en de user interface, dan met hoe de technische koppelingen aan de achterkant precies gerealiseerd worden. 13 Van deze analyse is een apart verslag gemaakt . In de volgende paragrafen neem ik daaruit enkele onderdelen over. 3.2.2
Aanpak
De problemen die gerelateerd lijken te zijn aan het aanvraagproces, zijn onderzocht bij de volgende afdelingen: Kindergeneeskunde: poli kindergeneeskunde; verpleegafdeling kindergeneeskunde, NICU Interne en MDL: poli Interne, MDL en MOC; dialyse; verpleegafdeling 2B, 3C en 3D Overig: AOA, SEH, Klinisch Lab, medische administratie PAMM Daarnaast is er met de PAMM afgesproken dat er een beheerproces wordt ingeregeld waarbinnen incidenten gestructureerd vastgelegd worden. Dit biedt zicht op aard en omvang van de fouten, en in hoeverre ze als risico beschouwd moeten worden. 11 12 13
verslag pilot Digitale PAMM-aanvragen fase 1 v0.4 BR/CU-2121 Prestaties en tarieven medisch specialistische zorg. NZa, 05-05-2014 Analyse inrichting digitaal aanvragen PAMM-onderzoeken v0.3
14
3.2.3
Aanvraagproces – basis en varianten
Het basisproces voor digitale PAMM-‐aanvragen bevat de volgende elementen:
Figuur 6 Aanvraagproces basis
Dit basisproces kent echter veel varianten, op basis van variabelen als het type onderzoek (SBK of BV), de setting (poliklinisch of klinisch, wat ook weer onder te verdelen is in prikronde, cito en zelfafname) en de keuze 14 15 wie de aanvraag invoert (bijvoorbeeld arts-‐assistent of secretaresse ). Deze varianten kennen ieder hun eigen werkwijze, wat van invloed is op bovenstaand basisproces. Zo kunnen de actoren die een onderdeel uitvoeren per variant verschillen, zoals in onderstaande figuur is uitgewerkt:
Figuur 7 Aanvraagproces basis met actoren
In het analyserapport worden de meest voorkomende varianten in detail besproken, met de issues die zich hierbij voordoen. Hier volsta ik met één voorbeeld daaruit:
Figuur 8 Aanvraagproces klinisch SBK -‐ cito
Issues die zich hierbij kunnen voordoen: -‐ De etiketten worden op de balie gelegd zodat de opgeroepen analist dit vindt. Bij meerdere aanvragen en / of bij verschillende patiënten kan dit tot verwisseling van etiketten leiden. -‐ Voor dit type aanvraag moet een labetiket geprint worden, het labsysteem van het KL herkent geen PAMM-‐ etiketten. Het overplakken met een PAMM-‐etiket gebeurt niet altijd zorgvuldig. 14
“Invoeren” of “indienen” van een aanvraag gaat over het daadwerkelijke invoeren van de aanvraag in Ezis. Dit moet onderscheiden worden van het begrip “aanvragend arts”, dit is de arts die verantwoordelijk is voor de aanvraag en op wiens naam de aanvraag dus wordt ingediend. 15 Met secretaresses worden hier ook polimedewerkers bedoeld.
15
3.2.4
Processen en ervaringen bij uitvoerders (PAMM en KL)
Ook met het KL en de PAMM zijn de processen en ervaringen besproken. Het KL heeft alleen met de SBK-‐ aanvragen te maken. Bij de PAMM komen alle orders en materialen binnen. De digitale aanvragen blijken vaker tot problemen met het matchen van materiaal met order te leiden dan de aanvragen op papier. In het analyserapport worden de bevindingen bij KL en PAMM nader beschreven.
3.3
Overzicht geconstateerde issues
De lijst met issues is in onderstaande tabel gezet. Achter elk issue staat de afdeling waar dit voorkomt of geconstateerd is, of waar we tijdens de analyse een risico in de werkwijze hebben onderkend.
issue PAMM-‐etiket voor poliklinische BV-‐aanvragen wordt niet geplakt, omdat het niet vanzelf wordt geprint. VRE-‐screening wordt op papier aangevraagd omdat dit sneller gaat. Voor allerlei afdelingen zijn “eigen” workflows ingericht, zonder dat hier een overzicht van bestaat. De aanvullende klinische gegevens blijken bij SBK-‐aanvragen overgeslagen te kunnen worden Secretaresse print etiketten en legt die ergens neer; de verpleging neemt het materiaal af en plakt de etiketten op de potjes. Dit is foutgevoelig, verwisseling tussen patiënten zou kunnen plaatsvinden. Bloedkweek stond voorheen op het BV-‐formulier, maar is nu bij de serologie-‐ aanvragen gevoegd. Gebruikers weten het niet altijd te vinden. Bij klinische cito SBK-‐aanvragen moet een labetiket geprint worden. Een secretaresse of verpleegkundige moet daarvoor een andere aanvraagoptie kiezen dan normaal. Dit is niet bij iedereen duidelijk. Bij klinische cito SBK-‐aanvragen moet het geprinte labetiket op de balie gelegd worden, zodat de opgeroepen analist deze kan vinden. Dit is foutgevoelig, verwisseling tussen patiënten zou kunnen plaatsvinden. Secretaresse of verpleging moet medische gegevens invullen, terwijl dat niet binnen hun bevoegdheden valt. Medische gegevens kunnen niet vanuit het dossier gevuld worden, het is niet voor iedereen duidelijk waar ze dit kunnen vinden. Analist krijgt op prikronde ad hoc de vraag om ook een bloedkweek af te nemen, zonder dat er een order voor wordt ingevuld. Sommige artsen dienen een KL-‐labaanvraag in, en schrijven bij de opmerkingen alleen “PAMM”. KL moet nabellen wat de bedoeling is. Etiketten voor verschillende materialen zijn verwisseld. Voor verschillende materialen zijn wel aparte orders aangemaakt, maar allemaal beplakt met etiketten van de eerste order. Serologie en bloedkweek mogen niet op één aanvraag, maar gebeurt wel. Verschillende materialen mogen niet op één BV-‐aanvraag, maar gebeurt wel. Secretaresses kunnen BV-‐aanvragen ook voor niet-‐pilotartsen aanvragen. Dit zorgt voor verwarring bij de PAMM. Labetiketten moeten op het KL overgeplakt worden met een PAMM-‐etiket. Dit overplakken gebeurt niet altijd netjes waardoor de barcode niet te scannen is. Materiaal komt binnen met alleen patiëntetiket
bron poli Interne, Dialyse Dialyse Dialyse, SHE Dialyse, SEH afdeling 3C Interne
afdeling 3C Interne verpleegafdelingen
verpleegafdelingen
verpleegafdelingen verpleegafdelingen KL KL PAMM PAMM PAMM PAMM PAMM PAMM
PAMM
16
3.4
Conclusies en aanbevelingen inrichting aanvraagproces
Digitaal aanvragen als onderdeel van ordermanagement behelst uitwisseling van informatie tussen organisaties, namelijk de aanvragende afdeling en het Klinisch Lab in het ziekenhuis, en de PAMM. Om uitwisseling tussen organisaties mogelijk te maken is samenwerking op verschillende niveaus nodig. Nictiz gebruikt onderstaand architectuurmodel om de verschillende lagen aan te duiden die van belang zijn in deze 16 uitwisseling .
Figuur 9 Architectuurmodel Nictiz gegevensuitwisseling in de zorg
Aan de hand van dit model is een analyse gemaakt van bovenstaande bevindingen. Een algemeen uitgangspunt 17 is dat als diverse gebruikers dezelfde fouten maken, er waarschijnlijk iets mis is met het design . In dit geval lijken bij het aanvraagproces zelf twee dingen vooral van belang te zijn bij de fouten die worden gemaakt: -‐ scheiding tussen invoer, printen van etiket, en materiaalafname (proces) -‐ variatie in werkwijze in Ezis en resulterende printopdrachten (applicatie) Daarnaast zijn er ook elementen op het niveau van organisatie en informatie (en enigermate infrastructuur) die bijdragen aan de foutgevoeligheid van het aanvraagtraject. De bevindingen zijn hieronder naar architectuurlaag uitgesplitst en samengevat. 3.4.1
Organisatie
Samenwerking MMC en PAMM De PAMM is een externe organisatie, los van het MMC. Hierdoor is er geen sprake van een geïntegreerd systeem, bij de PAMM wordt met andere labinformatiesystemen gewerkt dan bij het Klinisch Lab. Dit gegeven noopt tot goede afspraken op managementniveau tussen beide organisaties. Het MMC heeft de PAMM als partner voor het uitvoeren van aanvullend onderzoek. Om het gevraagde aanvullend onderzoek optimaal uit te voeren vraagt de PAMM om een aantal aanvullende gegevens, waaronder medische gegevens. Het handhaven hiervan gebeurt nu nog in onvoldoende mate. De administratie moet vaak nabellen bij onduidelijkheden, en als een order ontbreekt, wordt die bij de PAMM aangevuld. Ook het ontbreken van relevante klinische gegevens wordt doorgaans geaccepteerd. Het is aan het management van zowel MMC als PAMM om heldere afspraken hierover te maken. Het MMC verwacht betrouwbare resultaten van het onderzoek, de PAMM verwacht juiste en volledige aanvragen, inclusief aanvullende gegevens. De verantwoordelijkheden van beide organisaties voor een goed resultaat moeten opnieuw vastgesteld worden en vastgelegd in een Service Level Agreement (SLA). Bijvoorbeeld 16
Een checklist voor informatie-uitwisseling in de zorg. Nictiz, Den Haag, 13 november 2012 Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY.
17
17
aanvragend artsen zijn gehouden een juiste en volledige aanvraag in te dienen; de PAMM kan dit faciliteren door informatie te geven over hun onderzoeken en nut en noodzaak van de daarbij gevraagde gegevens. Het KL heeft bijvoorbeeld een dergelijke lijst via het intranet beschikbaar gesteld. Ook moet vastgelegd worden wat de consequenties zijn van onvolledige aanvragen. Dit zou kunnen zijn het terugsturen van een aanvraag, of de uitslag voorzien van een voorbehoud dat de uitslag tot stand is gekomen zonder te kunnen beschikken over de gevraagde klinische gegevens. De PAMM moet de verantwoordelijkheid op zich nemen de gemaakt afspraken hierover te handhaven. Daarnaast is er een verschil in opvatting tussen de PAMM en het MMC over wie als aanvragend arts mag 18 optreden, alleen een interne specialist, of ook arts-‐assistenten, coassistenten en verpleegkundig specialisten ? Op dit moment mogen al deze groepen in het MMC een PAMM-‐aanvraag doen, dit is niet voorbehouden aan interne artsen (al moeten die een aanvraag uiteindelijk wel autoriseren). In de artsentabel die de PAMM hanteert staan nu al uitsluitend interne artsen. De PAMM heeft als beleid dat zij alleen resultaten verstuurt naar deze specialisten. Bij aanvragen door een arts-‐assistent resulteert dit in het versturen van de uitslag naar “de maatschap”. Er is echter nog niet geborgd dat de uitslagen dan ook door iemand gezien worden. Het management van PAMM en MMC moeten afspraken maken welke procedures gehanteerd moeten worden om te voorkomen dat uitslagen niet worden gezien. Overigens overweegt de Raad van Bestuur van het MMC op dit moment om als aanvragend arts alleen interne specialisten toe te staan als “aanvragend arts". Een dergelijk besluit zou meteen gepaard kunnen gaan met duidelijke afspraken over het inzien van resultaten. 3.4.2
Proces
Herinrichting proces De huidige inrichting maakt het mogelijk dat het invoeren van de aanvraag, het printen van het etiket, en het afnemen van het materiaal op verschillende plaatsen worden uitgevoerd. Uit de analyse blijkt dat deze scheiding van acties vaak tot fouten leidt. Bijvoorbeeld bij de polikliniek en de dialyse wordt bij BV-‐aanvragen een patiëntsticker geplakt omdat er niet vanzelf een PAMM-‐etiket geprint wordt en de workflow niet aangeeft dat dit geprint kan en moet worden. Voor de eindgebruiker is dus niet altijd duidelijk dat digitale orders gepaard gaan met een eigen etiket, terwijl dit op papier evident was. Er is daarnaast een grote variabiliteit in processen, er is niet één proces “digitale PAMM-‐aanvragen”. Dit maakt het moeilijker voor medewerkers moeilijker de werkwijze voor ieder subproces te onthouden. Ook wordt het lastiger een eenduidige interface te ontwerpen, terwijl dit een correcte werkwijze zou kunnen faciliteren. Het verdient de voorkeur om met name de handelingen rond het printen van het etiket en het afnemen van het materiaal bij elkaar te houden. Bij de poliklinische bloedafname is dit ook het geval: na scannen van de orderbon wordt een PAMM-‐etiket gegenereerd die de analist meteen op de buizen voor de betreffende patiënt kan plakken. Dit traject veroorzaakt dan ook nagenoeg geen fouten, in tegenstelling tot de kliniek Om dit ook bij klinische aanvragen mogelijk te maken moet het printen van etiketten en de materiaalafname bij elkaar plaatsvinden. Ook moeten in het proces de patiënt en bij voorkeur ook de zorgverlener eenduidig geïdentificeerd worden. Een COW (computer on wheels) voor ordermanagement biedt daarvoor de mogelijkheid. Met een scanner wordt de patiënt geïdentificeerd middels diens barcode, zodat uitsluitend orderinformatie van die patiënt op het beeldscherm getoond wordt. De zorgverlener wordt op dezelfde wijze geïdentificeerd, zodat altijd te herleiden is wie de afname van het materiaal heeft uitgevoerd. Het selecteren van de order resulteert in het printen van de juiste etiketten. Op het scherm is ook het juiste type buis te lezen. De etiketten worden geplakt waarna de materiaalafname plaatsvindt. Op deze manier is verwisseling van etiketten of patiënten vrijwel uitgesloten. Deze manier van werken kan veel van de bij het MMC voorkomende problemen ondervangen. Dit zou wel de nodige investeringen vergen (zie ook onder applicatie en infrastructuur). Het houdt tevens een proceswijziging in, hetgeen goed gecommuniceerd en geïntroduceerd moet worden. Dit vereist investeringen in onder andere tijd, verandermanagement, en het toewijzen van verantwoordelijkheden.
18
De "aanvragend arts" is degene die het aanvullend onderzoek aanvraagt. Dit gaat dus niet over het daadwerkelijk in Ezis invoeren van de aanvraaggegevens.
18
Verantwoordelijkheid voor indienen aanvragen Op het procesniveau speelt ook de vraag wie de aanvraag daadwerkelijk in kan en mag voeren: alleen een arts, of ook verpleegkundigen en secretaresses? De keuze voor diverse aanvragersgroepen heeft diverse nadelen. Zo moet voor iedere groep apart de toegang tot het formulier gedefinieerd worden, wat weer tot extra variabiliteit leidt. Ook moeten verpleegkundigen en secretaresses dan de klinische gegevens (kunnen) invullen, terwijl ze daar niet altijd bekend mee zijn. Het invoeren van aanvragen zou beter voorbehouden kunnen zijn aan artsen. Verpleegkundigen en secretaresses maken terecht bezwaar dat zij een taak moeten uitvoeren waarvoor zij niet zijn opgeleid: medische gegevens behoren tot het domein van artsen. Zij moeten nu beslissen welke klinische gegevens opgevoerd gaan worden. Op de polikliniek is het doorgaans al de arts die de aanvragen invoert, dus de artsen moeten er sowieso mee bekend raken. Waar dit uitdrukkelijk niet mogelijk is, bijvoorbeeld op de OK, kan in overleg met de PAMM bepaald worden wie deze verantwoordelijkheid over mag nemen. Instructies Bij een foutgevoelig proces is het van extra belang dat de gebruikers goed geïnstrueerd worden. Nu is er eenmalig een instructie geweest, en leren nieuwe medewerkers het van de anderen. De informatieoverdracht tijdens de instructies blijkt echter onvoldoende te zijn geweest, gezien de verschillen in werkwijze bij de diverse afdelingen. In het Kwaliteitspaspoort zou een klinische les “Digitale Lab-‐ en PAMM-‐aanvragen” opgenomen kunnen worden, die iedere medewerker gevolgd moet hebben alvorens ze geautoriseerd worden tot het indienen of afhandelen van aanvragen. Op die manier blijft de kennis hierover op peil, ook als er nieuwe medewerkers komen. Daarbij moeten meteen de inhoud en vorm van de instructies geoptimaliseerd worden, in samenwerking met de PAMM. 3.4.3
Informatie
Overnemen gegevens vanuit dossier In een aanvraag moeten diverse aanvullende gegevens ingevuld worden, waaronder medische gegevens. Deze kunnen nu niet vanuit het dossier overgenomen worden. Dit moet mogelijk gemaakt worden, vanuit het principe “eenmalige registratie, meervoudig gebruik”. Dit kan niet door MMC zelf gedaan worden, maar is een wens die bij Chipsoft neergelegd zou kunnen worden. Daarbij dient een informatieanalyse plaats te vinden. De gevraagde "aanvullende klinische gegevens", omvatten namelijk zowel medische (diagnose, medicatie) als niet-‐medische gegevens (opnamedatum en –duur, aanvragend arts). Welke gegevens worden precies gevraagd, uit welk domein zijn deze afkomstig en hoe zijn deze in Ezis opgeslagen? ADT-‐ en MFN-‐koppeling Ook het (nu nog) ontbreken van een MFN-‐ en ADT-‐koppeling leidt tot meervoudige registratie, zowel van artsen als van patiënt-‐ en opnamegegevens. ADT is een type HL7-‐bericht, en staat voor Admission, Discharge en Transfer. Het bevat administratieve gegevens over de patiënt: naast NAW-‐gegevens ook informatie rond opname en ontslag. Een ADT-‐koppeling moet ervoor zorgen dat de beschikbare patiëntgegevens vanuit Ezis overgenomen worden in de informatiesystemen van de PAMM. Tussen Ezis en Labosys van het Klinisch Lab bestaat al een ADT-‐koppeling. Een ADT-‐koppeling is tot nu toe door de PAMM afgewezen omdat zij ook van andere organisatie dan het MMC 19 patiëntgegevens ontvangen . Echter, in de praktijk worden deze persoonsgegevens toch gecontroleerd en overgenomen als er een aanvraag binnenkomt, dus een ADT-‐koppeling neemt hier alleen maar werk weg. Het ADT-‐bericht levert meteen ook een deel van de gevraagde aanvullende gegevens, rond opname en de actuele locatie van een patiënt. Ook als er met andere instellingen een ADT-‐koppeling gemaakt wordt, zou dit alleen betekenen dat telkens de meest recente (en doorgaans meest correcte) informatie overgenomen wordt. Het is dan ook aan te bevelen om alsnog tot ADT-‐koppeling over te gaan.
19
bevestiging hiervan in mail John Stikkelbroeck d.d. 25-06-2014 RE: voortgang project nav reacties Philips en Chipsoft
19
20 De MFN-‐koppeling zal geen onderdeel uitmaken van dit project, dit zal in een apart project opgepakt worden . Een MFN-‐koppeling zorgt ervoor dat de gegevens uit een master bestand (in dit geval de artsentabel in Ezis) overgenomen wordt in de informatiesystemen van de PAMM. Tussen Ezis en Labosys bestaat al een MFN-‐ koppeling. De gegevens in Ezis zijn leidend.
MFN-‐koppeling
Figuur 10 MFN-‐koppeling
In een artsentabel moet onderscheid gemaakt worden tussen de rollen van autorisator, aanvragend arts (is mogelijk in de toekomst dus alleen de autorisator), en invoerder. Ook kunnen artsen verschillende artscodes hebben, bijvoorbeeld zowel kinderarts als intensivist. Dit is van invloed op het terugmelden van de uitslag. Een informatieanalyse moet dit helder maken. 3.4.4
Applicatie
Workflow Correct gebruik van een applicatie wordt bevorderd wordt door standaardisatie. Ezis biedt echter veel mogelijkheden tot personalisatie. De implementatie van de nieuwe orderkoppelingen biedt de gelegenheid om te werken aan optimalisatie van de user interface, met meer standaardisatie. Omdat de processen nu eenmaal een grote variatie kennen, zou op het niveau van de interface een eenduidige workflow ontworpen moeten worden, die voor alle PAMM-‐aanvragen (en eigenlijk liefst ook labaanvragen) geldt. Dit verhoogt de transparantie voor alle gebruikers, en faciliteert een juiste afhandeling. Het voorbeeld op de volgende pagina illustreert dit. De actieve handeling is geaccentueerd, de rest uitgegrijsd. Een balk waarin de voortgang wordt getoond (de paarse balk) is gangbaar en dus herkenbaar voor gebruikers. De informatie in de groene vakken is hier getoond om uit te leggen wat er in een bepaalde stap mogelijk is of gevraagd wordt. Bij het ontwerp van Ezis is helaas weinig rekening gehouden met vuistregels voor webontwerp vanuit het User 21 Centered Design . Er staat bijvoorbeeld te veel op een scherm, en er is geen (visueel) logisch pad dat je in een scherm doorloopt. Tegelijkertijd maakt de mogelijkheid tot aanpassingen in tabjes, kopjes, knoppen en teksten het geheel zowel ondoorzichtig als moeilijk beheerbaar. Ik ben niet bekend met de nieuwe versie van Ezis (HiX). Ik verwacht uiteraard dat in ieder geval de user interface meer is aangepast aan de huidige inzichten rond webontwerp. Of bovenstaande aanbeveling voor het volgen van een workflow daarin gerealiseerd kan worden, is mij niet bekend.
20
21
notulen stuurgroepoverleg DA PAMM 20140402; mail Mark de Wette d.d. 11-06-2014 RE: lijst functionele / technische eisen
http://en.wikipedia.org/wiki/User-‐centered_design
Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY. Norman, Donald A. (1988). The design of everyday things, The Perseus Book Group.
20
Figuur 11 Concept weergeven workflow
Kleurcodering etiketten Medewerkers blijken het lastig te vinden om labetiketten en PAMM-‐etiketten uit elkaar te houden. Kleurcodering zou hierbij kunnen helpen. Dit is mogelijk door etiketten te gebruiken waarop onderin enkele hokjes in verschillende kleuren staan. In de etiketdefinitie worden 4 van de 5 hokjes zwart ingekleurd, waardoor er één kleur overblijft: verschillend voor Klinisch Lab en MMB. Tonen juiste context Als ervoor gekozen wordt om te werken met identificatie van patiënt en medewerker dan zijn aanpassingen in Ezis nodig. Het moet dan mogelijk zijn om met het scannen van barcodes meteen het orderoverzicht van de betrokken patiënt te tonen. Ook moet hiermee gecontroleerd kunnen worden of een medewerker geautoriseerd is tot afname van materiaal. 3.4.5
Infrastructuur
Als het advies voor herinrichting van het proces met COWs, met als doel een ondubbelzinnige relatie tussen patiënt, materiaal, order en etiket te garanderen, wordt opgevolgd, heeft dit grote consequenties voor de infrastructuur. Het Erasmus-‐ziekenhuis in Rotterdam heeft een dergelijke werkwijze al geïmplementeerd, en heeft daar speciale ordermanagement-‐COWs voor laten bouwen. Daarnaast moet voorzien worden in hardware zoals scanners, COWs, badges met barcodes voor de medewerkers, etc. Een en ander stelt ook weer eisen aan het draadloos netwerk.
3.5
De ideale situatie en de mogelijkheden in de praktijk
Op dit moment komen er regelmatig fouten in de PAMM-‐aanvragen voor, zowel in de digitale als de papieren werkwijze. Digitaal aanvragen heeft met name de etiketteerproblemen versterkt. Dit kan de patiëntveiligheid in gevaar brengen, en verdient daarom een heroriëntatie op de mogelijkheden om de foutkans te verkleinen. Binnen de huidige context kan ook zonder ingrijpende proceswijzigingen het nodige verbeterd worden. Diverse aanbevelingen uit de vorige paragraaf kunnen bijdragen aan een lagere foutkans, waarbij zeker elke mogelijkheid tot standaardisatie aangegrepen moet worden. Direct uitvoerbaar is in ieder geval het verhogen van het instructieniveau, zowel qua beschikbaarheid van instructies (bijvoorbeeld als klinische les), als qua inhoud en vorm. Instructies moeten niet alleen uitleg geven over hoe een en ander in zijn werk gaat, maar ook waarom een juiste werkwijze belangrijk is. Ook de PAMM
21
moet hierin verantwoordelijkheid nemen: zij kunnen de belangen en risico’s illustreren. Medewerkers van Functioneel Beheer of Zorginformatie kunnen de praktische uitleg verzorgen. Ook kan op korte termijn verbetering van de kwaliteit van aanvragen behaald worden door te besluiten dat een medewerker pas geautoriseerd tot aanvragen wordt na instructie. In dat geval is wel voldoende aanbod van instructies noodzakelijk. Van de overige aanbevelingen moet, bijvoorbeeld in de stuurgroep, beoordeeld worden welke op korte termijn haalbaar zijn. Voor de langere termijn acht ik deze kleinere aanpassingen niet afdoende. Zeker bij pathologie-‐ aanvragen leiden verwisseling van etiketten of onjuiste aanvraaggegevens tot grote risico's voor de patiëntveiligheid. Zo lang het printen van etiketten fysiek gescheiden blijft van het afnemen van het materiaal, zullen fouten blijven bestaan. In de ideale situatie blijven patiënt, materiaal, order en etiket ondubbelzinnig aan elkaar gekoppeld. De voorgestelde werkwijze (zie vorige paragraaf onder Proces) biedt daarvoor de mogelijkheden. Deze is nu alleen voor een prikronde beschreven, maar heeft ook meerwaarde bij bijvoorbeeld klinische en poliklinische zelfafname: als orderoverzicht, etiketprinter, buisjes of potjes en scanner op één kar op een afdeling beschikbaar zijn, kan elke zelfafname met behulp daarmee plaatsvinden. Een herinrichting biedt ook meer kans om gehoopte efficiëntievoordelen, zoals ordersets of beslisondersteuning, mogelijk te maken. Met de huidige inrichting lijkt dit onvoldoende haalbaar. Het is nu nog te veel een 1 op 1 vertaling van de bestaande situatie naar een applicatie-‐inrichting. Dit is begrijpelijk vanuit het verloop van het digitaliseringsproces, waarbij in eerste instantie vooral de papieren dossiers en bestaande werkwijzen gedigitaliseerd zijn. Echter, door de vele varianten zou er heel veel intelligentie in de applicatie ingebouwd moeten worden om één orderset aan te maken. Om dit beter mogelijk te maken is een inrichting nodig die vanuit een informatie-‐ en procesanalyse vormgegeven wordt en veel meer uniformiteit biedt. In hoeverre deze herinrichting van het proces haalbaar is verdient nader onderzoek. Zo'n wijziging is ingrijpend, maar biedt wel de beste kansen op foutreductie. Bij een onderzoek is o.a. een kwantificering van de huidige foutfrequentie nodig. Daarbij moet rekening gehouden worden met het feit dat ook papieren aanvragen regelmatig tot fouten leiden, die met deze werkwijze voorkomen kunnen worden. Een risicoanalyse moet uitwijzen of de te behalen foutreductie de benodigde investeringen rechtvaardigt.
22
4 Detaillering projectdoel: programma van eisen Het eerste projectdoel (evaluatie pilot) is in het vorige hoofdstuk aan de orde gekomen. De twee andere projectdoelen (functionele en overige specificaties) zijn in overleg met alle projectleden uitgewerkt tot onderstaande lijst met functionele en technische eisen. Deze is voorgelegd aan de stuurgroep en projectleden en goedgekeurd. M = Must have S = Should have
4.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14
4.2 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Functionele eisen omschrijving digitaal aanvragen moet aanvrager minstens dezelfde opties bieden als op papier order moet binnen zijn op moment dat materiaal bij PAMM binnenkomt mogelijkheid om ordersets / -‐pakketten aan te maken mogelijkheid om elk onderzoek ook apart aan te vragen klinische gegevens moeten altijd ingevuld zijn (afdwingen) aanvragend arts moet altijd ingevuld zijn (afdwingen) afnamedatum en tijd moet altijd ingevuld zijn (automatisch vullen, handmatig aan te passen) aanvragen voor bloedkweek en serologie moeten tegelijk met aanvragen voor bloedonderzoek van het KCL verstuurd kunnen worden proces moet dezelfde route als order volgen, bv. bloed altijd via KCL versturen een aanvraag moet, zolang die niet in bewerking is (tot het materiaal door PAMM in ontvangst is genomen), gewijzigd of geannuleerd kunnen worden systeem moet voor iedereen op elke werkplek beschikbaar zijn (i.t.t. papieren orders) ADT-‐koppeling vanuit Ezis naar PAMM MFN-‐artsenkoppeling systeem moet voor aanvrager mogelijkheid bieden tot volgen status van de aanvraag
belang M M M M S M M M S S M S S M
Niet-‐functionele eisen omschrijving geen extra kosten, anders dan eventuele aanschafkosten CS-‐module zoveel mogelijk gebruik van bestaande koppelingen zo min mogelijk nieuwe koppelingen (laten) bouwen de te ontwikkelen architectuur + werkwijze mag niet tot nieuwe problematiek qua proces leiden (zoals wel gebleken is bij fase 1) formulier moet makkelijk vindbaar zijn binnen werkcontext van aanvrager de gebruikers moeten instructie krijgen over het gebruik alle gebruikers moeten in de gelegenheid zijn om digitaal te orderen materiaal moet correct geëtiketteerd zijn geen verschillende materialen op één order handhaving afspraak rond bloedafname door KCL systeem moet gevalideerd worden door betrokken gebruikers aanvragend arts moet in actieve artsenbestand bekend zijn BSN moet ondersteund worden in de berichtuitwisseling tussen MMC en PAMM (vv). What's new moet ondersteund blijven, d.w.z. de artscode (aanvrager) die in de OML staat moet via de ORU teruggezonden worden aan EZIS het samenvoegen van orders in Labosys voor dezelfde prikronde bij het KCL mag niet (meer) leiden tot identificatieproblemen bij PAMM
belang M S S M M M M M M M S M M M M
23
4.3 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Technische eisen omschrijving orders moeten volledig digitaal van Ezis naar Molis gestuurd kunnen worden orders moeten volledig digitaal vanuit Ezis naar Sympathy gestuurd kunnen worden Labosys moet een volledige order digitaal door kunnen sturen naar Molis berichtenverkeer moet beveiligd plaatsvinden via VPN-‐tunnel koppelingen moeten verlopen via Cloverleaf (CIS) koppelingen moeten verlopen via Communicator (Ensemble) Comez koppelingen moeten voldoen aan MMC-‐standaard koppelingen moeten volgens standaarden (min. HL7 v2.4) gebouwd worden Ezis-‐ordernummer moet als MMC identificeerbaar zijn voor PAMM (voorafgegaan worden door '40') ordernummer moet uit maximaal 10 cijfers bestaan in orderbericht moet BSN patiënt staan In uitslagbericht moet Ezis-‐ordernummer staan en BSN van patiënt als deze door MMC is aangeleverd in orderbericht (OML) aan PAMM systeem moet functioneel en technisch getest worden systeem moet gevalideerd worden door betrokken partijen Ezis-‐ordernummer moet onveranderd, leidend zijn de order-‐ en uitslagberichten moeten identificeerbaar zijn met een uniek message-‐ number en moeten sending facility en sending application bevatten
belang M M M M M M M M M M M S M S M S
4.4
Beheereisen
46 47 48
omschrijving er moet een sluitende procedure voor updaten codetabellen zijn er moet na inproductiename een gelijkwaardige testomgeving zijn, met separate koppelingen naar deze testomgeving overdracht aan beheerders moet plaatsvinden voordat de koppelingen in productie gezet worden.
belang M S S
24
5 Ontwerpen 5.1
Inleiding
Dit en het volgende hoofdstuk behandelen de architectuurontwerpen voor de verschillende digitale orderkoppelingen die gebouwd moeten worden voor de PAMM-‐aanvragen. 5.1.1
De werkwijze in fase 1 (pilot)
Zoals in paragraaf 1.3 vermeld zijn er drie typen PAMM-‐aanvragen, namelijk Pathologie (PA), Bacteriologie & virologie (BV) en Serologie & bloedkweek (SBK). Deze typen kennen verschillende manieren van materiaalafname, logistiek, en orderverkeer. De aanvragen kunnen zowel uit de kliniek als de polikliniek afkomstig zijn.
Figuur 12 Typen PAMM-‐onderzoeken
22 Voor elk type is in fase 1 een aanvraagformulier in Ezis gemaakt , voorzien van een vragenlijst voor aanvullende gegevens, waaronder ook klinische gegevens. In hoofdstuk 2 is al gewezen op het belang van de aanvullende klinische gegevens voor het uitvoeren van onderzoeken bij de PAMM. Deze vragenlijst moet bij de digitale aanvragen ingevuld worden voordat de order verstuurd wordt. Voor labaanvragen (aanvragen voor onderzoeken bij het Klinisch Lab) hoeft zo’n vragenlijst niet ingevuld te worden omdat het daarvoor geen toegevoegde waarde biedt. In fase 1 is er nog geen digitale orderkoppeling ontwikkeld. De pilot werkt met een halfdigitale werkwijze, waarbij de orders wel digitaal in Ezis kunnen worden aangevraagd, maar niet rechtstreeks naar Molis (het LIS van de PAMM) worden verstuurd. De elektronische orders komen op een werklijst in Ezis waar de medische administratie van de PAMM toegang toe heeft. Zij printen alle orders uit. De print bevat een 2D-‐barcode, waarin alle ordergegevens vervat zijn. De order wordt door middel van het scannen van de barcode ingevoerd in Molis. 5.1.2
Aanpak voor het ontwerpen van een architectuur voor de koppelingen
In de projectgroep Serologie & bloedkweek is eerst besproken welke knelpunten uit de pilotfase in ieder geval in de ontwerpen voor de koppelingen opgelost moeten worden. Dit waren de knelpunten rond het samenvoegen van orders voor dezelfde prikronde, het aanvragen van onderzoek in meerdere materialen op één aanvraag, en het etiketteren. Een ander aandachtspunt betrof het ordernummer waarop de communicatie tussen de systemen verloopt. Het oorspronkelijke Ezis-‐ordernummer moet in de communicatie met de PAMM voorzien moet worden van voorloopcijfers (40). Dit om de order te kunnen onderscheiden van orders die uit andere ziekenhuizen afkomstig zijn. Bijvoorbeeld het Catharinaziekenhuis in Eindhoven gebruikt ook Ezis, dus daar kunnen potentieel dezelfde ordernummers gegenereerd worden. Mede hierdoor zijn de gewone labetiketten (waar het originele Ezis-‐ordernummer in barcode op staat) bij de PAMM niet te scannen. 22
ook voor Pathologie-aanvragen, al is dit nog niet in gebruik genomen
25
23,24 Op grond van de uitkomsten van de besprekingen van team SBK is het architectuurteam aan de slag gegaan met het ontwikkelen van een architectuurvoorstel voor de verschillende typen aanvragen. Voor de twee aanvraagtypen PA en BV is het uitgangspunt een rechtstreekse koppeling tussen CS Order (Ezis) naar Sympathy, respectievelijk Molis. Voor deze laatste twee kan dus een relatief eenvoudige architectuur getekend worden. Dit wordt in paragraaf 5.2 beschreven. Qua architectuur leveren de SBK-‐aanvragen de meeste uitdagingen op. Er moet namelijk een order naar zowel het Klinisch Lab (KL) als naar de PAMM gestuurd worden. Dit is nodig vanwege de bestaande afspraken tussen MMC en PAMM met betrekking tot de bloedafname: de PAMM zorgt niet zelf voor bloedafname, maar laat dit door het KL in het MMC doen. Het materiaal dat door het KL wordt afgenomen moet vervolgens eenduidig 25 gekoppeld kunnen worden aan de order zoals die door de PAMM is ontvangen . Voor dit type aanvraag zijn drie ontwerpen denkbaar, die in paragraaf 5.3 zijn uitgewerkt. Om de plannen te toetsen en zo mogelijk van relevante input te voorzien, heb ik overleg gehad met drie andere ziekenhuizen over hoe zij het ordermanagement voor aanvullend onderzoek hebben ingericht. Een samenvatting hiervan staat in paragraaf 5.4. In de daaropvolgende paragrafen beschrijf ik hoe we tot een keuze voor een ontwerp voor SBK-‐aanvragen zijn gekomen.
5.2
Koppelingen voor aanvragen Pathologie en Bacteriologie en virologie
Het basisproces van aanvragen voor aanvullend onderzoek Pathologie en Bacteriologie en virologie is relatief eenvoudig: er is één aanvragende en één uitvoerende instantie. Het berichtenverkeer verloopt dus 1 op 1 26 tussen twee systemen, als volgt :
Figuur 13 Model orderuitwisseling PA en BV
27 Voor dit model is gebruik gemaakt van het Referentie Domeinenmodel Ziekenhuizen (RDZ) . Het RDZ is een resultaat van iZiekenhuis, een samenwerkingsverband van NVZ-‐ziekenhuizen en Nictiz. iZiekenhuis biedt ziekenhuizen een gezamenlijk platform en kenniscentrum voor informatie en best practices rond de informatievoorziening. In dit model staat "ID" voor Informatiedomein en "BA" voor Bedrijfsactiviteit. De aanvraag wordt binnen het MMC ingediend in Ezis en verstuurd naar ofwel Molis (voor BV-‐aanvragen) ofwel Sympathy (voor PA-‐ 23 24 25 26 27
verslag overleg team 2 DA PAMM 20140227 verslag overleg team 2 DA PAMM 20140317 zie ook paragraaf 1.4.2 over ordermanagement in de context van PAMM-aanvragen bij het MMC zie ook paragraaf 1.4.1 over ordermanagemt in het algemeen Referentiedomeinenmodel ziekenhuizen versie 2.2. Nictiz, Den Haag (http://www.nictiz.nl/rdz)
26
aanvragen). De PAMM voert het onderzoek uit en verstuurt het verslag en updates over de orderstatus terug naar de aanvrager. De technische uitwerking van de ordercommunicatie voor deze aanvraagtypen staat in versie 2.3 van het 28 architectuurdocument . De procesbeschrijving en het architectuurontwerp zijn ook nader uitgewerkt aan de 29 hand van het RDZ en met behulp van de modelleertaal Archimate . De nieuwe best practice van Chipsoft voor BV-‐orders biedt de mogelijkheid om aanvragen voor verschillende materialen via een boomstructuur in te laten dienen. Eerst moet een materiaal gekozen worden, waarvoor de aanvraag wordt ingevuld, dan pas kan men een volgend materiaal kiezen. Onderliggend wordt dan voor ieder materiaal een aparte order aangemaakt. Dit lost het eerder genoemde knelpunt van meerdere materialen op 30 één aanvraag op. Daarom heeft de stuurgroep besloten deze aan te schaffen . Voor het bevolkingsonderzoek naar darmkanker is reeds de best practice van Chipsoft aangeschaft. Dit beslaat een deel van de pathologie-‐onderzoeken. Om zoveel mogelijk aansluiting hierbij mogelijk te maken is ook 18 gekozen om de algemene pathologiemodule van Chipsoft te kopen . Een bijkomend argument voor deze beide keuzes is dat Chipsoft steeds meer uitgaat van de eigen best practices, en in de toekomst steeds minder zelf aangebrachte aanpassingen zal ondersteunen. Zeker met de komst van HIX (Ezis versie 6) is het zaak om zoveel mogelijk aan te sluiten bij de best practices van Chipsoft, om verzekerd te blijven van optimale ondersteuning.
5.3
Koppeling voor aanvragen serologie en bloedkweek
Voor SBK-‐aanvragen is de situatie complexer: er zijn drie spelers betrokken bij deze aanvraag, namelijk de aanvrager, de uitvoerder voor de bloedafname (Klinisch Lab), en de uitvoerder voor de analyse (PAMM). Voor de communicatie tussen de drie betrokken systemen zijn verschillende ontwerpen mogelijk. Deze ontwerpen worden beschreven in paragraaf 5.3.2 t/m 5.3.4. 31 De gedachtegang achter de drie ontwerpen is uitgewerkt in een presentatie voor de stuurgroep . Met deze presentatie is inzichtelijk gemaakt wat elke optie voor consequenties zou hebben. In de notities bij elke slide staat een gedetailleerde omschrijving van de werkwijze. 5.3.1
RFC ingediend bij iZiekenhuis
Voor de modellering van de SBK-‐aanvragen is opnieuw gebruik gemaakt van het RDZ. Hierin kwam naar voren dat de bedrijfsactiviteit "Uitvoeren aanvullend onderzoek" zowel op de materiaalafname als op het daadwerkelijk uitvoeren van het onderzoek blijkt te slaan. Dit is vreemd, omdat het twee wezenlijk verschillende activiteiten betreft. Ik heb in juni een wijzigingsvoorstel bij Fred Smeele van iZiekenhuis 32 ingediend, waarin ik voorstel hier verschillende BA's van te maken . Dit zal eind 2014 behandeld worden. 5.3.2
Koppeling SBK -‐ Ontwerp 1
Het eerste ontwerp gaat uit van volledige digitalisering van de huidige halfdigitale werkwijze. Dit betekent dat er een order naar zowel Labosys (voor de bloedafname) als naar Molis (voor de daadwerkelijke analyse) gestuurd moet worden. Dit heeft als belangrijk nadeel dat er geen eenduidige orderstatusvoering mogelijk is. Ezis zou in dit geval namelijk van twee systemen statusupdates over dezelfde order moeten kunnen verwerken; dit is echter niet mogelijk. Ook wordt hiermee het probleem van samenvoegen van orders niet opgelost. Andere voor-‐ en nadelen zijn in de presentatie benoemd en worden in paragraaf 5.5 samengevat.
28 29 30 31 32
2014 0281 PAMM order Ontwerp Architectuur en inrichting_v2.3 Uitwerking opdracht B1 – B2 notulen stuurgroepoverleg DA PAMM 20140402 voor- en nadelen architectuuropties v3 https://service.projectplace.com/pp/pp.cgi/0/1016954077?direct=1016955181
27
Figuur 14 Koppeling SBK – ontwerp 1
5.3.3
Koppeling SBK -‐ Ontwerp 2
Aanvankelijk leek het logisch om de verantwoordelijkheid voor de materiaalafname bij de PAMM te leggen. Zij zijn immers de uitvoerder van de order vanuit het MMC voor aanvullend onderzoek. In dit ontwerp wordt de aanvraag vanuit Ezis naar Molis verstuurd. Van daaruit gaat een order voor bloedafname naar het Klinisch Lab.
Figuur 15 Koppeling SBK -‐ ontwerp 2
Zoals in de presentatie echter wordt duidelijk gemaakt, blijft ook in dit ontwerp het probleem met samenvoegen van orders bestaan. Ook zou er een interlabkoppeling vanuit Molis naar Labosys gebouwd moeten worden, terwijl niet duidelijk werd of de leverancier van Molis hiertoe in staat is. Zie paragraaf 5.5 voor de overige voor-‐ en nadelen.
28
5.3.4
Koppeling SBK -‐ Ontwerp 3
Bij ontwerp 3 wordt de aanvraag vanuit Ezis naar Labosys verstuurd. Bij het Klinisch Lab leidt deze order tot het afnemen van bloed. Pas als deze bloedafname daadwerkelijk heeft plaatsgevonden, wordt de order doorgestuurd naar Molis.
Figuur 16 Koppeling SBK -‐ ontwerp 3
Het probleem van samenvoegen van orders wordt hiermee dus opgelost, aangezien het samenvoegen voorafgaat aan het doorsturen van de order (zie presentatie). Ook is de communicatie rond de orderstatus nu helder: eenduidig berichtenverkeer tussen telkens twee systemen. Een bijkomend voordeel is dat er geen orders in Molis blijven openstaan als ze in Ezis al geannuleerd zijn: een order komt pas in Molis als het materiaal al is afgenomen, dus het onderzoek zal dan in ieder geval uitgevoerd kunnen worden. Zie paragraaf 5.5 voor de overige voor-‐ en nadelen.
5.4
Bevindingen andere ziekenhuizen
In de loop van het project heb ik met enkele andere ziekenhuizen overleg gehad over hoe zij het ordermanagement, en dan met name voor Bacteriologie en virologie en Pathologie, hebben ingericht. De meeste hebben echter in tegenstelling tot het MMC een intern lab voor medische microbiologie (MMB-‐lab), of zijn nog niet bezig met digitaal ordermanagement. Bij het UMC in Utrecht zijn Klinisch Lab en MMB-‐lab wel min of meer aparte afdelingen, maar ze zijn wel allebei onderdeel van het UMCU en werken beide met GLIMS. Ondanks deze relatieve nabijheid is UMCU nog niet zover dat ze al digitaal aanvragen hebben gerealiseerd. Problemen met het samenvoegen van orders kennen zij 33 niet, omdat zij besloten hebben dit niet automatisch te laten plaatsvinden . Het Erasmus-‐ziekenhuis heeft een eigen module voor digitaal ordermanagement ontwikkeld. Aangezien zij een zelfgebouwd EPD (ElPado) hebben, konden zij deze module optimaal naar eigen inzicht inrichten. In dit project zijn alle aanvragen voor aanvullend onderzoek gedigitaliseerd, en is ook het hele proces hier omheen opnieuw ingericht. Men maakt gebruik van COWs waardoor zowel patiënt als labmedewerker geïdentificeerd kunnen worden, waarna de gegevens van alleen die betreffende patiënt op de laptop verschijnen. Verwisseling is daardoor vrijwel niet meer mogelijk, de juiste etiketten worden ter plekke gegenereerd en op de buizen geplakt. De verschillende labs hebben wel allemaal hun eigen orderformulieren. Er is dus geen samenvoeging van orders mogelijk, en ook hoeven MMB-‐aanvragen niet uit een order voor het Klinisch Lab gefilterd te 34 worden . 33 34
Bespreking Ronald Swinkels UMCU 20140410 Bespreking Maarten Nagelkerke juni 2014
29
Bij het AVL NKI is de situatie met betrekking tot MMB-‐aanvragen enigszins vergelijkbaar met die van het MMC. Omdat het volume aan dergelijke vragen bij hen laag is, laten zij deze onderzoeken uitvoeren bij het MMB-‐lab van het Slotervaartziekenhuis. Ook het AVL NKI kiest ervoor om het aanvraagtraject via één lijn te laten verlopen, namelijk via hun Klinisch Lab (AKL). Alle MMB-‐orders, dus zowel gewone bacteriologie en virologie als serologie en bloedkweek worden vanuit Ezis naar GLIMS van het AKL gestuurd. Het AKL controleert de order, en stuurt deze dan door naar Slotervaart. Echter, een belangrijk verschil is dat zij voor serologie en bloedkweek een aparte aanvraag voor de bloedafname indienen, dus een losse prikorder. Men beraadt zich nog op de beste manier om de prikorder aan de onderzoekaanvraag te hangen. Waarschijnlijk zullen alle MMB-‐orders vanuit één formulier verstuurd worden, waarbij bij de SBK-‐aanvragen een aparte trigger ingebouwd moet worden 35 voor het genereren van een prikorder . Concluderend kan gesteld worden dat de situatie in andere ziekenhuizen doorgaans onvoldoende vergelijkbaar is met de onze, om er echt bruikbare inzichten uit te kunnen opdoen. Toch blijkt het ziekenhuis met de meeste overeenkomsten, het AVL NKI, ook vergelijkbare keuzes te maken: de order en het materiaal worden naar het Klinisch Lab gestuurd, en deze stuurt de order door naar het MMB-‐lab. Het lage volume bij dit ziekenhuis maakt het echter mogelijk om orders nog handmatig te controleren bij het AKL, hetgeen bij het MMC niet haalbaar is. Een voordeel daar is dat deze werkwijze voor alle MMB-‐aanvragen geldt, niet alleen voor serologie en bloedkweek. De keuze van het Erasmus om niet alleen de digitale techniek, maar het hele werkproces opnieuw in te richten blijkt voordelen te hebben. Er is een grote mate van eenduidigheid bij alle gebruikers, en het werkproces is met behulp van technische hulpmiddelen zoveel mogelijk waterdicht gemaakt. De situatie in MMC is duidelijk anders: elke afdeling of polikliniek heeft een eigen werkwijze, waardoor het lastig is een eenduidige, strakke procedure in te voeren. Overigens moet bedacht worden dat in een enkel gesprek met een ander ziekenhuis het niet mogelijk is om alle voor-‐ en nadelen van hun werkwijze te achterhalen. Binnen het MMC heb ik veel tijd kunnen besteden aan onderzoek hiernaar. Een dergelijke omvangrijke analyse bij een ander ziekenhuis is binnen het bestek van dit project niet haalbaar. Hierdoor is het mogelijk dat bepaalde nadelen van de werkwijze in het Erasmus onderbelicht zijn gebleven.
5.5
Risicoanalyse ontwerpen
Elk ontwerp heeft zowel voor-‐ als nadelen. Hieronder worden deze per ontwerp benoemd. 5.5.1
Koppeling SBK – Ontwerp 1
Voordelen: -‐ Bekende werkwijze waarvan we weten dat het voor het grote merendeel van de aanvragen werkt. -‐ Het huidige orderformulier dat in Ezis is gebouwd kan gebruikt blijven worden, inclusief protocollen. -‐ Slechts één extra koppeling nodig, van Ezis naar Molis; geen interlabkoppeling tussen Molis en Labosys nodig. Nadelen: -‐ Zeer problematisch met betrekking tot het bijhouden van de orderstatus: Ezis moet dan van twee andere systemen statusupdates verwerken, hetgeen technisch niet waterdicht geregeld kan worden. -‐ Het probleem van samenvoegen van meerdere gelijktijdige orders wordt niet opgelost. -‐ Overplakken etiketten bij Klinisch Lab blijft nodig. -‐ Voor aanvragende afdeling blijven verschillende etiketten (lab-‐ en PAMM-‐etiket) in gebruik. -‐ Verschillende werkwijzen voor SBK-‐aanvragen enerzijds, en BV-‐ en PA-‐aanvragen anderzijds. -‐ Proceswijziging in geval van zelfafname nodig: materiaal mag niet meer naar de PAMM gebracht worden, maar moet via Klinisch Lab gestuurd worden. -‐ Molis krijgt ook de labcodes voor het Klinisch Lab binnen, correcte afhandeling hiervan moet apart ingeregeld worden.
35
Bespreking Patrick Lubbers AVL NKI mei 2014
30
5.5.2
Koppeling SBK – Ontwerp 2
Voordelen: -‐ Eenduidige statusvoering tussen telkens twee systemen. -‐ Eenduidigheid in logistiek proces: alle materiaal rechtstreeks naar PAMM (SBK-‐, BV-‐ en PA-‐aanvragen). -‐ Overplakken etiket bij Klinisch Lab niet meer nodig, dus minder kans op fouten daarin. Nadelen: -‐ Het probleem van samenvoegen van meerdere gelijktijdige orders wordt niet opgelost. -‐ Proceswijziging in logistieke afhandeling nodig: alle materiaal gaat naar de PAMM. -‐ 24/7 dienst bij PAMM nodig. -‐ Huidige orderformulier moet gewijzigd worden, protocollen zijn dan niet meer te gebruiken. -‐ Twee nieuwe koppelingen nodig: interlabkoppeling van Molis naar Labosys (vooral werk voor leverancier Molis / PAMM), en extra koppeling van Ezis naar Molis. -‐ Voor aanvragende afdeling blijven verschillende etiketten (lab-‐ en PAMM-‐etiket) in gebruik. -‐ Molis krijgt ook de labcodes voor het Klinisch Lab binnen, correcte afhandeling hiervan moet apart ingeregeld worden. 5.5.3
Koppeling SBK – Ontwerp 3
Voordelen: -‐ Eenduidige statusvoering tussen telkens twee systemen. -‐ Het probleem van samenvoegen van meerdere gelijktijdige orders wordt hiermee opgelost. -‐ Het huidige orderformulier dat in Ezis is gebouwd kan gebruikt blijven worden, inclusief protocollen. -‐ Slechts één extra koppeling nodig, een interlabkoppeling van Labosys naar Molis. -‐ Order komt pas in Molis na daadwerkelijke bloedafname, dus er kunnen geen orders meer blijven openstaan, of materiaal binnengekomen voor inmiddels geannuleerde orders. -‐ Molis krijgt alleen testcodes voor eigen onderzoeken binnen. -‐ Hierdoor ook geen annuleringsbericht van Labosys naar Molis nodig. Nadelen: -‐ Interlabkoppeling van Labosys naar Molis nodig, vooral werk voor leverancier Labosys (Philips) en MMC. -‐ Proceswijziging in logistieke afhandeling nodig: alle SBK-‐materiaal moet naar Klinisch Lab verstuurd worden, kan niet rechtstreeks bij PAMM afgeleverd worden. -‐ Verschillende werkwijzen voor SBK-‐aanvragen enerzijds, en BV-‐ en PA-‐aanvragen anderzijds. -‐ Voor aanvragende afdeling blijven verschillende etiketten (lab-‐ en PAMM-‐etiket) in gebruik. -‐ Overplakken etiketten bij Klinisch Lab blijft nodig. 5.5.4
Koppeling SBK -‐ algemeen
Bij alle ontwerpen ligt een risico in het proces, zowel bij de etikettering als in de logistieke afhandeling. Het digitale aanvraagformulier dwingt een correcte handelswijze niet af. Nu bloedkweek en serologie samen onder één tab bij de laborders zijn geplaatst is het lastig om de instructie "geen serologie en bloedkweek op één order" te handhaven, temeer daar het juist wél de bedoeling is om laborders en PAMM-‐orders te combineren. Voor alle ontwerpen geldt dat een procedure voor het wijzigen van formulieren noodzakelijk is, omdat er drie partijen in het spel zijn. In elk systeem moet de PAMM-‐testcodetabel identiek blijven. Deze procedure is 36 opgesteld en door alle partijen goedgekeurd .
36
Procedure aanvraag wijziging PAMM-formulier v1.0
31
5.6
Keuze ontwerp
Ontwerpen 1 en 2 losten beide het probleem van samenvoegen van gelijktijdige orders niet op. Dit was in het projectplan als randvoorwaardelijk gesteld bij de keuze voor een nieuwe architectuur. In juni heeft Philips echter release 4 van Labosys uitgebracht, waarin het mogelijk werd om de juiste etiketten te genereren uit samengevoegde orders. Daarmee werd dit argument van minder belang. Ontwerp 1 is onwenselijk omdat de orderstatus hiermee niet waterdicht op te volgen is. In geval van problemen zou het ook moeilijker zijn te achterhalen waar het probleem nu ligt, in de berichtuitwisseling tussen Ezis en Labosys of die met Molis. Ontwerp 2 valt af omdat er niet 1, maar 2 nieuwe koppelingen gebouwd zouden moeten worden. Ook is een 24-‐uursdienst bij de PAMM niet haalbaar. Ontwerp 3 heeft de beste balans tussen voor-‐ en nadelen. Deze oplossing biedt een eenduidige uitwisseling van de orderstatus, en orders worden pas naar Molis verstuurd na daadwerkelijke bloedafname. Dit verkleint de kans op fouten. De verschillende ontwerpen zijn voorgelegd aan de stuurgroep, met advies voor ontwerp 3. Dit is door de 37 stuurgroep overgenomen .
37
notulen stuurgroepoverleg DA PAMM 20140402
32
6 Architectuurontwerp De ontwerpen voor zowel de PA-‐ en BV-‐aanvragen als voor de SBK-‐aanvragen zijn in het architectuur-‐ 38 projectteam verder uitgewerkt . Hierin is uitgebreid aandacht besteed aan de workflow tussen de betrokken systemen en aan de statusvoering. Voor beide typen volgen hieronder de schema’s van het detailontwerp.
6.1
Detailontwerp PA en BV
EZIS Order
PAMM Order (1) retourbericht (verzonden)
Aanvraag
PAMM (molis-MM)
Annuleren Etiketten + Formulier (papier) met barcode (2)
Materiaal (met barcode) (3)
Afname (Kliniek/OK of patient)
In bewerking (4)
Orderstatus
Voltooid (7) Geannuleerd
Uitslag Onderzstatus
Materiaal Ontvangen (5)
Uitslag (6) (voorlopig / definitief)
Uitslag
Technische ACK/NACK afhandeling geschiedt op gebruikelijke wijze tussen verzendend en ontvangend systeem. De technische ACK van/naar de systemen is verder vanwege de leesbaarheid achterwege gelaten maar zijn in de praktijk wel degelijk aanwezig.
Workflow
Ezis
(4) Ezis
PAMM Verzonden
Materiaal ontvangen
In bewerking
Figuur 17 Architectuurontwerp BV en PA
PAMM
Molis-MM
Molis-MM
(6)
(7)
Status
Molis-MM
(5)
ORM
Uitslag
Molis-MM
ORU
MM onderz
Kliniek / Patient
Status
Kliniek / Patient
(3)
ORM
Status
(2)
Afname & distributie
Specialist in Ezis (order) (1)
ORU
Planning
Aanvraag
ORM
Ezis
Ezis
voorlopig / definitief
voltooid
38
2014 0281 PAMM order Ontwerp Architectuur en inrichting_v2.3
33
39 Dit is het schema voor BV-‐onderzoeken (hier nog MM genoemd), maar hetzelfde ontwerp geldt voor de PA-‐ onderzoeken. Van belang is de workflow die een order doorloopt, met de daarbij behorende statusupdates. De gebruikte HL7-‐berichten worden in het interactiediagram gespecificeerd:
Aanvraag MM onderzoek EZIS/ Comez
MolisMM ORM NW aanvraag MM, status: niet verzonden ACK (ontvangen), status: verzonden ORR status: in bewerking ORU status: ‘i’ (materiaal ontvangen)
ORU status: ‘P’ ORU status: ‘F’ ORR status: voltooid
ORU status: ‘C’ (optioneel)
Annuleren vanuit EZIS EZIS/ Comez
MolisMM ORM CA annuleren MM aanvraag ORR Status: geannuleerd
Annuleren vanuit Molis-MM EZIS/ Comez
MolisMM ORM CA annuleren MM onderzoek ORM CA annuleren MM aanvraag ORR Status: geannuleerd
Figuur 18 Actiediagram BV en PA
Het MMC gaat hierbij uit van HL7 v2.6 OML-‐berichten. De betrokken leveranciers blijken echter alleen HL7 v2.5 aan te bieden. Deze versie voorziet ook al in OML-‐berichten, dus dat is door het MMC geaccepteerd. 39
In dit schema wordt nog de afkorting MM (medische microbiologie) gebruikt, waar BV bedoeld wordt. Dit was eerder in het project de gangbare afkorting. Het staat echter ook voor de MM-afdeling van de PAMM, waar ook SBK-aanvragen afgehandeld worden. Vandaar dat ik in dit document gekozen heb voor BV.
34
6.2
Detailontwerp SBK
Het architectuurontwerp voor SBK-‐aanvragen is uitgewerkt in het schema hieronder: Serologie / Bloedkweek EZIS Order
Klin.Lab
Aanvraag
Order (1) Verzonden Annuleren Annuleren
PAMM
Order (3) Ontvangen (7)
LAB (Labosys)
PAMM (molis-MM)
Annuleren
2) g(
Orderstatus
n r ki d r we be ulee 8 ) In n an id ( Ge oltoo V
Etiketten + Formulier (papier) met barcode (4)
ZelfAfname
Prikpost (afname)
Materiaal (buizen met barcode) (6)
Uitslag Labuitslag
Afgenomen (5) (in bepaling)
Materiaal Ontvangen (7)
MMuitslag
Uitslag (9) (voorlopig/ definitief)
Technische ACK/NACK afhandeling geschiedt op gebruikelijke wijze tussen verzendend en ontvangend systeem. De technische ACK van/naar de systemen is verder vanwege de leesbaarheid achterwege gelaten maar zijn in de praktijk wel degelijk aanwezig.
Labosys
(2)
(5)
Ezis Labosys Verzonden
In bewerking
ORM Labosys
Figuur 19 Architectuurontwerp SBK
Ezis
Afgenomen (3)
Molis-MM
Lab of Prikpost (prikken)
(6)
ORR
MM uitslag
Labosys
Afname & distributie
Lab uitslag
(4)
ORU
MM onderzoek
Lab (binnen halen)
Status
(1)
ORU
Status
Specialist in Ezis (order)
ORR
Planning
Aanvraag
ORM
Registratie bij pamm
Workflow
Molis-MM
Lab
PAMM
Molis-MM
(7) Ezis + Labosys Materiaal ontvangen
(8)
ORU
(9)
Ezis
Ezis
voltooid
voorlopig / definitief
Versie 2.2 24-03-2014 Peter Kerkhofs MIT – MMC ©
35
Om de interlabkoppeling te realiseren zal de PAMM vanuit Labosys beschouwd worden als een soort super-‐ analyser die werk uitvoert voor het Klinisch Lab. Bij aanmelden van het monster wordt de order doorgezet naar de PAMM. In de koppeling naar de PAMM worden order-‐ en etiketgegevens meegestuurd. De overige inhoud moet in de ontwikkelfase verder overeengekomen worden. Om deze order in Labosys af te kunnen sluiten wordt gebruik gemaakt van het ORU-‐bericht "materiaal ontvangen" dat Molis uitstuurt. Hiermee is het mogelijk om een testcode van een resultaat te voorzien. Het Labosys ordernummer kan hiermee afgesloten worden; hiervoor is een uitgaande poort op de Cloverleaf naar Labosys nodig. De koppeling zal gerealiseerd worden op basis van HL7 v2.5 OML-‐berichten. Het bijbehorende interactiediagram ziet er als volgt uit: Aanvraag Serologie/bloedkweek EZIS/ Comez
MolisMM
Labosys ORM order, status: niet verzonden
Oppakken order in Labosys (verzamelen)
ACK, status: verzonden ORR Status: in bewerking
ORM order ACK
ACK
Registreren van materiaal in Molis
ORR Status: ontvangen ORU status: ‘i’
Verslaglegging microbioloog
ORU status: ‘P’ ORU status: ‘F’ ORU status: ‘C’ Dagafsluiting / bij facturatie ORR status: voltooid
Annuleren Serologie/bloedkweek vanuit EZIS EZIS/ Labosys Comez ORM CA, annuleren order
Indien vóór ORM aan pamm, dan is doorsturen niet nodig. Indien ná doorsturen aan pamm dan wordt onderzoek toch uitgevoerd en gefactureerd.
MolisMM
ORR Status: Geannuleerd
Annuleren Serologie/bloedkweek vanuit Labosys EZIS/ Verwijderen hele order. Labosys Annulering gaat asynchroon Comez naar beide kanten.
ORM CA, annuleren ORM CA, annuleren
MolisMM
ORM CA, annuleren ORR Status: Geannuleerd
ORR Status: Geannuleerd
Annuleren Serologie/bloedkweek vanuit Molis-MM is niet van toepassing Versie 2.2 24-03-2014 Peter Kerkhofs MIT – MMC ©
Figuur 20 Actiediagram SBK
36
6.3
Risicoanalyse detailontwerp
De ontwerpen zijn zowel in de architectuur-‐projectgroep als in de stuurgroep besproken. Hierin is een aantal risico's onderkend. Deze worden hieronder omschreven, met daarbij de maatregelen die getroffen worden om het risico te verminderen. Risico's Risicoverlagende maatregelen De oplossing om SBK-‐aanvragen via een Voor dit soort tests zal een afgeschermd deel van de interlabkoppeling te laten verlopen is niet standaard. productieomgeving van Molis gebruikt worden. Dit maakt het noodzakelijk de koppeling goed door te Er zijn goede afspraken tussen Klinisch Lab en PAMM testen in geval van releaseveranderingen bij PAMM nodig voor het afstemmen en uitvoeren van of Klinisch Lab. Labosys heeft hiervoor een dergelijke tests. Deze zullen in de projectfase worden testomgeving. Bij de PAMM heeft Molis wel een vastgelegd. separate testomgeving, maar die wordt alleen voor grote wijzigingen gebruikt. Deze architectuur kan niet voorkomen dat serologie In de instructies moeten hier speciale aandacht aan en bloedkweek op één aanvraag ingediend worden, worden besteed. Tijdens de instructies moet een terwijl Molis dit niet kan verwerken. Het kan zo'n vertegenwoordiger van de PAMM aanwezig zijn om order niet splitsen in deelorders. Het blijft dus het belang van een correct proces uit te leggen. De afhankelijk van het gedrag van de aanvrager of dit PAMM moet ook de verantwoordelijkheid nemen correct wordt ingevoerd. aanvragers hierop aan te spreken. De etiketteringsproblemen zijn met deze ontwerpen Ook dit vergt heldere en overzichtelijke instructies, niet verholpen. Afhankelijk van de situatie moet een waar voldoende tijd voor uitgetrokken moet worden. lab-‐ of een PAMM-‐etiket worden geprint, of hoeft er De PAMM moet ook de verantwoordelijkheid nemen geen etiket te worden geprint maar alleen een aanvragers hierop aan te spreken. orderbon, of hoeft er zelfs niets geprint te worden. Deze veelheid aan workflows maakt het proces foutgevoelig, omdat de individuele aanvragers (vaak secretaresses en baliemedewerkers) niet altijd het overzicht hebben wanneer wat geprint moet worden. Alle materiaal voor SBK moet via het Klinisch Lab Dit moet in de instructies helder overgebracht aangeleverd worden. Dit vergt een gedeeltelijke worden. procesverandering: op dit moment wordt dit ook wel Er is afgesproken dat, als materiaal rechtstreeks bij de rechtstreeks naar de PAMM gebracht. PAMM wordt afgeleverd, iemand van de PAMM bij het Klinisch Lab zal langslopen om het monster alsnog aan te melden. Er zal gemonitord worden of dit werkbaar is. Mogelijk is het nodig om een functionaliteit bij de PAMM te bouwen waardoor zij zelf een monster bij Labosys kunnen aanmelden. Het kan lang onduidelijk blijven hoe en waar Na invoering bij een nieuw specialisme moeten alle bepaalde fouten ontstaan, omdat de communicatie betrokken partijen systematisch opvolgen wat er tussen aanvragers, PAMM, Zorginformatie en Klinisch verkeerd gaat en dit direct terugkoppelen aan de Lab niet gestructureerd verloopt. betreffende aanvrager. Samen moet naar oplossingen gezocht worden. Hiervoor fungeert de projectleider als centraal aanspreekpunt.
37
6.4
Business Case
6.4.1
Projectresultaat
Dit project zorgt voor completering van het digitaal aanvragen binnen het MMC. Digitaal aanvragen richting radiologie en klinisch lab is in de afgelopen jaren reeds ingevoerd, orderen naar de PAMM vormt het sluitstuk. Dit is conform het beleid van MMC, om zoveel mogelijk processen middels het EPD te digitaliseren. Digitale formulieren zijn makkelijker en goedkoper uitbreidbaar en onderhoudbaar dan papieren formulieren. Voor aanvragers wordt het aanvraagproces eenduidiger: alles verloopt digitaal. Door verhoogde leesbaarheid en completere invulling van de formulieren zal de kwaliteit van de aanvragen hoger worden. Dit resulteert naar verwachting in efficiënter en kosteneffectiever aanvragen omdat de uit te voeren onderzoeken beter afgestemd kunnen worden op de vraagstelling van de arts. Ook wordt het nu mogelijk om complete ordersets te definiëren waarin alle aanvullend onderzoek rond een aandoening of klacht in één keer kan worden aangevraagd. Met digitaal aanvragen wordt het mogelijk zeker te stellen dat de naam van de aanvragend arts altijd wordt ingevuld. Daardoor is het altijd duidelijk naar wie de uitslag opgestuurd dient te worden (zie ook par. 2.2.1). 6.4.2
Kosten en inzet
De in te zetten uren moeten uit de reguliere bezetting gehaald worden. Deze worden niet apart bijgehouden of gefactureerd. Dit is in hoofdlijnen gedekt bij aanvang van het project. Onderstaand is een schatting gemaakt van de ingezette uren tot en met september: klinisch informaticus als projectleider 12 u/w, 39 weken 1 persoon 468 u architect 16 u/w, 16 weken 1 persoon 256 u informatieanalist 12 u/w, 39 weken 1 persoon 468 u stuurgroepleden 7 x 1u pp 4 personen 28 u projectleider PAMM 1 u/w, 39 weken 1 persoon 39 u projectteamleden 1 u/w, 39 weken 7 personen 273 u opdrachtgever 1 u/w, 39 weken 1 persoon 39 u 1571 u In geval van kosten voor externe leveranciers, wordt dit tot een limiet van ca. € 50.000 gedekt uit de bestaande investeringsgelden. De te maken kosten voor Molis en een interlabkoppeling bij de PAMM worden gedragen en gedekt door de PAMM.
38
7 Implementatie 7.1
Technische implementatie
Implementatie van het technisch ontwerp voor de drie koppelingen kan pas van start gaan als Philips (voor de interlabkoppeling Labosys – Molis) en Chipsoft (voor de best practices voor BV en PA) een planning afgeven voor het ontwikkelen van deze koppelingen. Eind augustus is van Chipsoft een planning binnengekomen, die vanaf 10 september tot en met eind januari 2015 loopt. Inmiddels heeft ook Philips gemeld dat ze gaan beginnen met het bouwen van de koppeling. De verdere technische implementatie zal begeleid worden door een nieuwe (interim-‐)projectleider.
7.2
Functionele implementatie
Naast de technische implementatie moet het digitaal aanvragen ook daadwerkelijk bij alle afdelingen in het ziekenhuis uitgerold worden. Dit zal plaatsvinden na oplevering en acceptatie van de te bouwen orderkoppelingen. De bevindingen en aanbevelingen uit hoofdstuk 3 kunnen gebruikt worden om deze uitrol te optimaliseren.
39
8 Verificatie/validatie: vergelijk met programma van eisen De ontwerpen voor BV, PA en SBK zoals die er nu liggen voldoen voor het merendeel aan de opgestelde functionele en technische eisen. Enkele items, zoals nr. 46, zijn al opgeleverd. Enkele andere zijn tijdens de ontwerpfase gewijzigd of aangepast. Diverse items kunnen pas definitief gevalideerd worden na oplevering van de koppelingen. Hieronder worden de items voorzien van een beoordeling voor zover dit op dit moment mogelijk is. Het ontwerp blijkt voor een belangrijk deel reeds aan de eisen te voldoen. De "status" verwijst naar het resultaat als de implementatie conform het ontwerp wordt uitgevoerd. M = Must have S = Should have
8.1 1 2 3 4 5 6 7 8
9
10
11
12 13 14
Functionele eisen omschrijving digitaal aanvragen moet voor aanvrager minstens dezelfde mogelijkheden bieden als op papier order moet binnen zijn op moment dat materiaal bij PAMM binnenkomt mogelijkheid om ordersets / -‐pakketten aan te maken mogelijkheid om elk onderzoek ook apart aan te vragen klinische gegevens moeten altijd ingevuld zijn (afdwingen) aanvragend arts moet altijd ingevuld zijn (afdwingen) afnamedatum en tijd moet altijd ingevuld zijn (automatisch vullen en handmatig aan te passen, afdwingen) aanvragen voor bloedkweek en serologie moeten tegelijk met aanvragen voor bloedonderzoek van het KCL verstuurd kunnen worden proces moet dezelfde route als order volgen, d.w.z. materiaal voor bloedonderzoek moet altijd via KCL afgeleverd worden een aanvraag moet, zolang die niet in bewerking is (tot het materiaal door PAMM in ontvangst is genomen), gewijzigd of geannuleerd kunnen worden systeem moet voor iedereen op elke werkplek beschikbaar zijn (i.t.t. papieren orders)
belang M
M M S M M
status ja, formulieren zijn 1:1 overgenomen ja, zowel voor SBK als voor BV en PA geregeld ja ja nee, niet voor SBK ja ja
M
ja
S
ja
S
ja, voor BV; voor SBK betekent dit tot materiaalafname ja, vereist wel beschikbaarheid printers, PC's en aansluitmogelijkheden 40 nee 41 nee ja
ADT-‐koppeling vanuit Ezis naar PAMM MFN-‐artsenkoppeling systeem moet voor aanvrager mogelijkheid bieden tot volgen status van de aanvraag
S S M
M
M
40 41
zie paragraaf 3.4.3 zie paragraaf 3.4.3
40
8.2
Niet-‐functionele eisen
15
omschrijving geen extra kosten, anders dan eventuele aanschafkosten CS-‐module
belang M
16
zoveel mogelijk gebruik van bestaande koppelingen
S
17
zo min mogelijk nieuwe koppelingen (laten) bouwen
S
18
de te ontwikkelen architectuur + werkwijze mag niet tot M nieuwe problematiek qua proces leiden (zoals wel gebleken is bij fase 1) formulier moet makkelijk vindbaar zijn binnen werkcontext M van aanvrager de gebruikers moeten instructie krijgen over het gebruik M
19 20
21
M
ja, verschillende ingangen mogelijk ja, is bij pilot gedaan en zal ook bij verdere uitrol plaatsvinden ja, vereist wel autorisatie in Ezis nee, is nog aandachtspunt ja, voor B&V; voor SBK moet dit wel nog met Philips doorgesproken worden ja, iedereen over eens ? moet nog gepland worden ? nu nog niet beperkt tot interne specialisten, wordt nog veranderd ja, is zo afgesproken
M
ja, is zo afgesproken
M
ja, is opgelost met nieuwe Labosys release 4, en in SBK-‐ architectuur
M
22
alle gebruikers moeten in de gelegenheid zijn om digitaal te orderen materiaal moet correct geëtiketteerd zijn
23
geen verschillende materialen op één order
M
24
handhaving afspraak rond bloedafname door KCL
M
25
systeem moet gevalideerd worden door betrokken S gebruikers aanvragend arts moet in actieve artsenbestand bekend zijn M
26
27 28
29
BSN moet ondersteund worden in de berichtuitwisseling tussen MMC en PAMM (en vice versa). What's new moet ondersteund blijven, d.w.z. de artscode (aanvrager) die in de OML staat moet via de ORU teruggezonden worden aan EZIS het samenvoegen van orders in Labosys voor dezelfde prikronde bij het KCL mag niet (meer) leiden tot identificatieproblemen bij PAMM
status nee, ook aanschafkosten interlabkoppeling Labosys – Molis ja, koppeling Ezis – Labosys wordt voor de SBK-‐aanvragen gebruikt ja, voor 3 typen aanvragen 3 koppelingen gepland ? pas te beoordelen na implementatie
M
41
8.3 30
Technische eisen belang M
status ja
M
ja
M M M M M M
ja, in overleg met Philips af te stemmen ja ja ja ja ja
M
ja
M M S
ja ja ja
42
omschrijving orders moeten volledig digitaal van Ezis naar Molis gestuurd kunnen worden orders moeten volledig digitaal vanuit Ezis naar Sympathy gestuurd kunnen worden Labosys moet een volledige order digitaal door kunnen sturen naar Molis berichtenverkeer moet beveiligd plaatsvinden via VPN-‐tunnel koppelingen moeten verlopen via Cloverleaf (CIS) koppelingen moeten verlopen via Communicator (Ensemble) Comez koppelingen moeten voldoen aan MMC-‐standaard koppelingen moeten volgens standaarden (min. HL7 v2.4) gebouwd worden Ezis-‐ordernummer moet als MMC identificeerbaar zijn voor PAMM (voorafgegaan worden door '40') ordernummer moet uit maximaal 10 cijfers bestaan in orderbericht moet BSN patiënt staan In uitslagbericht moet Ezis-‐ordernummer staan en BSN van patiënt als deze door MMC is aangeleverd in orderbericht (OML) aan PAMM systeem moet functioneel en technisch getest worden
M
43 44
systeem moet gevalideerd worden door betrokken partijen Ezis-‐ordernummer moet onveranderd, leidend zijn
S M
45
de order-‐ en uitslagberichten moeten identificeerbaar zijn met een uniek message-‐number en moeten sending facility en sending application bevatten
S
ja, voor BV en PA al gepland; voor SBK nog te plannen ? nog te plannen ja, zij het dat in communicatie met PAMM voorloop-‐40 wordt gehanteerd ? pas te beoordelen na implementatie
31 32 33 34 35 36 37 38 39 40 41
8.4
Beheereisen
46 47
48
omschrijving er moet een sluitende procedure voor updaten codetabellen zijn er moet na inproductiename een gelijkwaardige testomgeving zijn, met separate koppelingen naar deze testomgeving overdracht aan beheerders moet plaatsvinden voordat de koppelingen in productie gezet worden.
belang M
status 42 ja
S
? te beoordelen na implementatie
S
? nog te plannen
42
Procedure aanvraag wijziging PAMM-formulier v1.0
42
9 Conclusies en aanbevelingen Met betrekking tot de analyse van de inrichting van het aanvraagproces zijn de conclusies en aanbevelingen reeds beschreven in hoofdstuk 3. Hieronder volgen de conclusies met betrekking tot het ontwerp van de technische orderkoppelingen.
9.1
Haalbaarheid
9.1.1
Technisch
Er is overleg geweest met zowel de leverancier van de BV-‐ en PA-‐koppelingen (Chipsoft), als die van de interlabkoppeling (Philips) met betrekking tot het architectuurontwerp van het MMC. De conclusie was dat de gekozen oplossingen hiermee in overeenstemming zijn. De best practices van Chipsoft zijn aangekocht en worden vanaf september geïmplementeerd. Er lijken op dit 43 moment geen obstakels te zijn voor een succesvolle implementaties. Tijdens het ColonIS-‐project kwam een probleem aan het licht met betrekking tot de firewalls tussen beide organisaties. Voor de orderkoppeling moet de verbinding tussen de firewalls namelijk altijd open blijven staan, en dit was niet het geval. Er bleek een instellingsfout in de ontvangende applicatie te staan die de koppeling instabiel maakte, maar dit is recentelijk opgelost. Philips is in september begonnen met werk aan de interlabkoppeling. Dit deelproject zal dus parallel verlopen aan dat van Chipsoft. Dit betekent dat zowel het MMC als de PAMM hier voldoende capaciteit voor beschikbaar moet stellen. Op dit moment gaan beide zijden ervan uit dat dit haalbaar is. 9.1.2
Functioneel
In de implementatiefase zullen eindgebruikers aan de projectteams deelnemen om de functionele bruikbaarheid te bewaken. Dit moet helpen om een ziekenhuisbrede uitrol haalbaar te maken. Echter, de reeds geconstateerde problemen in de inrichting van het aanvraagproces zullen aangepakt moeten worden. Een minimumeis hierbij is het verbeteren van de instructies. Aanbevelingen hiervoor zijn: -‐ Geef instructies op moment dat iedereen er voldoende aandacht aan kan geven. Bijvoorbeeld werkoverleg, overdrachtsmoment, of een half uurtje na 5 uur. -‐ Zorg dat iedereen die met het digitaal aanvragen te maken heeft, ook instructie ontvangt. Beter nog zou zijn om dit als eis te stellen voordat men hiervoor geautoriseerd wordt. -‐ Sluit aan bij de klinische les van het Klinisch Lab over digitaal orderen, zodat ook nieuwe medewerkers instructie kunnen krijgen. -‐ Benoem in de kliniek de verschillende opties met betrekking tot serologie en bloedkweek: prikronde, cito, zelfafname hebben een verschillende werkwijze. -‐ Houd bij de instructies rekening met het niveau van computervaardigheid en Ezis-‐vaardigheid bij de eindgebruikers. Die ligt vaak beduidend lager dan bij de medewerkers van Functioneel Beheer. -‐ Illustreer tijdens de instructies wat de risico's zijn van verkeerde etikettering (vooral bij pathologie-‐ aanvragen) -‐ Maak de instructies qua lay-‐out en uitleg beter leesbaar.
9.2
Behalen van projectdoelen
9.2.1
Kwaliteit van de aanvragen en verhogen efficiëntie
De drie koppelingen moeten de digitalisering van het aanvraagproces completeren. Naast het digitaal indienen van de aanvraag, kan de order hiermee ook digitaal naar de informatiesystemen van de PAMM worden gestuurd. Hiermee worden twee hoofddoelen gerealiseerd: de nadelen van de aanvragen op papier zijn ondervangen, en het aanvraagproces in zijn geheel (inclusief het ontvangstproces aan de zijde van de PAMM) wordt een stuk efficiënter. 43
Aanleggen van een orderkoppeling voor pathologie-aanvragen afkomstig van endoscopieën, in het kader van het Landelijk Bevolkingsonderzoek Darmkanker
43
9.2.2
Optimalisatie van het proces
Aan optimalisatie van het proces dragen deze koppelingen niet bij. Met de gemaakte keuzes blijven er drie routes voor de verschillende aanvraagtypen bestaan, met de bijbehorende handelingen en logistiek. Het proces is hiermee dus niet eenduidiger geworden. Gegeven de diversiteit van alle mogelijke labonderzoeken (bij KL en PAMM) lijkt de beste oplossing om in de interface een schil te bouwen rond de verschillende aanvraagtypen waarin een standaard aanvraagtraject wordt gedefinieerd. Bij het doorlopen van dit traject worden dan de 44 keuzeopties van elk onderdeel aangepast aan de voorafgaande keuze . 9.2.3
Gebruiksvriendelijkheid
Aan een aantal verwachting op het gebied van gebruiksvriendelijkheid is voldaan: bredere beschikbaarheid van de aanvraagfaciliteit, een arts kan de orderstatus opvolgen en overzicht houden over alle ingediende orders. De papieren formulieren zijn 1 op 1 overgezet naar digitale formulieren, dus de gebruiker heeft de beschikking over dezelfde functionaliteit. Het gebruiksgemak is, zoals eerder besproken, door de grote variabiliteit niet heel hoog. Ook de mogelijkheid 45 tot het aanbieden van ordersets lijkt beperkt 9.2.4
Werken volgens standaarden en onderhoud codetabellen
Aan het werken volgens standaarden is voldaan, en ook het onderhoud van de codetabellen is inmiddels geregeld.
9.3
Oplossing knelpunten
De te bouwen koppelingen moesten enkele knelpunten uit de pilot oplossen. Dit is gelukt voor het probleem van samenvoegen van meerdere orders voor dezelfde prikronde. Door de orders eerst naar het KL te sturen, en pas na materiaalafname door de sturen naar de PAMM vormt het samenvoegen in Labosys geen probleem meer: zowel het materiaal krijgt het nummer waaronder is samengevoegd, als de order die naar de PAMM wordt gestuurd. Ook het indienen van aanvragen voor meerdere materialen op één order bij BV-‐onderzoeken zal bij de nieuwe koppeling van Chipsoft niet meer kunnen voorkomen. Voor het gelijktijdig aanvragen van bloedkweken en een serologieonderzoek moet nog een oplossing gevonden worden in definiëring van het orderbericht dat vanuit Labosys naar Molis wordt gestuurd. De problemen met etiketteren zijn deels opgelost, bespreking hiervan met de verschillende afdelingen heeft bij navraag bij de PAMM tot verbetering geleid. De architectuur voorziet echter niet in verdere verbeteringen hiervoor in de techniek. Voor aanbevelingen op dat gebied zie paragraaf 3.4.4 en 9.1. De interlabkoppeling zal ook een probleem oplossen dat pas bij de analyse uit hoofdstuk 3 aan het licht is gekomen, namelijk dat het invullen van klinische gegevens bij SBK-‐aanvragen overgeslagen kan worden. Om deze vragenlijst via de interlabkoppeling te kunnen doorsturen moesten er wijzigingen in de inrichting van de ordermodule van Ezis gemaakt worden. Deze wijzigingen zorgen ervoor dat invullen van de aanvullende gegevens nu ook voor SBK wordt afgedwongen.
9.4
MFN-‐ en ADT-‐koppelingen
Zoals in paragraaf 3.4.3 al is gesteld, moeten MFN-‐ en ADT-‐koppelingen alsnog ingevoerd worden. Hier moet de PAMM nog mee instemmen. In de tussentijd betekent dit dat de komende implementaties hier wel al in moeten voorzien, zodat dit te zijner tijd ingevuld kan worden.
44 45
Zie paragraaf 3.4.4 Zie paragraaf 3.5
44
10 Discussie 10.1
Gehanteerde aanpak
Bij de start van het huidige project was het MMC al enige jaren bezig om tot een digitale orderkoppeling met de PAMM te komen. Dit heeft druk gelegd op het komen tot een ontwerp, om vervolgens vaart te kunnen maken met de technische en functionele implementatie. Ook de late start van mijn jaarproject binnen de twee jaar van de opleiding leidde tot tijdsdruk. In het ontwerp heb ik me mede daarom, maar ook door mijn onervarenheid als projectleider, nogal laten leiden door de situatie “as is”. De uitgebreide analyse van de inrichting heeft tot het inzicht geleid dat er meer aandacht gegeven had moeten worden aan de problemen rond het aanvraagproces. Mogelijk had dit kunnen leiden tot een ander ontwerp van de architectuur. De optie om alle aanvraagtypen via de PAMM te laten 46 verlopen is weliswaar besproken, maar op praktische gronden verworpen . Het is ook de vraag of dit had geholpen. Ook in dat geval zouden zorgverleners met verschillende labaanvragen te maken houden: bloedonderzoek bij het KL zou dan een andere route volgen dan bloedonderzoek bij de PAMM. Voor eindgebruikers lijkt dit weinig te bieden qua eenduidigheid. Het uitvoeren van de analyse in een eerder stadium had, als toch voor deze architectuur was gekozen, in ieder geval kunnen leiden tot diepgaander onderzoek naar de vormgeving van de gebruikersinterface. Mogelijk biedt HIX, versie 6 van Ezis, mogelijkheden tot het verbeteren daarvan. Het verdient dan ook aanbeveling om in de opstartfase van een project meer tijd uit te trekken voor een grondige probleem-‐ en procesanalyse, om de resultaten daarvan te kunnen verwerken in het uiteindelijke ontwerp, voor alle relevante architectuurlagen.
10.2
Projectorganisatie
In de stuurgroep waren eindgebruikers niet vertegenwoordigd. Dit heeft waarschijnlijk bijgedragen aan de verminderde aandacht voor de inrichting van het aanvraagproces. Het is een algemeen advies bij het vormen van een projectorganisatie om de inbreng van eindgebruikers te borgen. Dit is hier niet gebeurd, omdat ik het KL en de PAMM als gebruikers zag, namelijk als gebruikers van de orderkoppeling.
10.3
Communicatie met de PAMM
Dat de analyse pas later in het traject plaatsvond, heeft ook te maken met het feit dat de PAMM een aparte organisatie is. Ondanks de nabije locatie is de communicatie beperkter dan binnen de eigen organisatie. Net als bij de bezoeken aan de aanvragende afdelingen kwamen issues bij de PAMM ook pas voldoende aan het licht door vaker en uitgebreider bezoeken af te leggen bij de medische administratie. De communicatie verliep tot dan toe primair via de contactpersonen bij de PAMM, maar als projectleider verdient het aanbeveling om ook zelf op de hoogte te raken van de werkprocessen daar.
46
Zie paragraaf 5.6
45
11 Relevantie ontwerp voor anderen Zoals in paragraaf 4.5 al is genoemd, is de situatie van het MMC met betrekking tot de PAMM niet iets wat veel voorkomt. Het AVL / NKI maakt weliswaar ook gebruik van een extern MMB-‐lab, maar hun uitgangspunt is anders: de opdracht tot bloedafname is bij hen een aparte order, los van de aanvraag voor het aanvullend onderzoek. Zij beraden zich op een oplossing voor de vraag hoe ze beide orders aan elkaar kunnen relateren. Met deze zienswijze laten zij goed zien dat materiaalafname niet gelijk is aan het uitvoeren van het onderzoek, wat overeenkomt met wat ik in paragraaf 4.4.1 heb geschreven over de bedrijfsactiviteit "Uitvoeren aanvullend onderzoek" zoals die in het RDZ omschreven wordt. De oplossing zoals zij die nu voor ogen hebben lijkt een omgekeerde versie van de onze: zij sturen een MMB-‐ order uit, met daarin een trigger om ook een prikorder te genereren. Wij sturen een laborder uit die ervoor zorgt dat bloedafname plaatsvindt, wat (na afname en aanmelding) als trigger fungeert voor het genereren van een PAMM-‐order. Beide oplossingen pleiten voor het splitsen van de RDZ-‐bedrijfsactiviteit "Uitvoeren aanvullend onderzoek" in twee verschillende BA's. Onze keuze komt overigens deels voort uit het feit dat de laborders al eerder gedigitaliseerd waren. De SBK-‐ orders zijn daarbij ondergebracht. Dat dit zijn nadelen heeft is beschreven in het verslag van de analyse van het aanvraagproces. Het is dan ook de vraag of dit als voorbeeld zou moeten dienen voor andere ziekenhuizen, voor zover deze een zelfde constructie kennen als de MMC met PAMM.
46
12 Reflectie 12.1
Persoonlijke reflectie
Ik heb veel kunnen leren tijdens dit project. Dat gaat gepaard met voortschrijdend inzicht, waardoor ik dingen bij een volgend project zeker anders zal aanpakken. Het is me nu bijvoorbeeld pas laat duidelijk geworden dat ik niet de enige ben die het proces niet doorgrondde. Ik heb te makkelijk aangenomen dat dit bij iedereen al duidelijk was, terwijl het bij nader onderzoek zeker niet duidelijk, zelfs nogal gecompliceerd bleek te zijn. Meer vertrouwen en durf om door te blijven vragen is op zijn plaats. Vooral ben ik me erg bewust geworden van mijn neiging om me aan te passen aan de gegevenheden van een situatie. Zo heb ik de keuzes met betrekking tot werkwijze en proces zoals die in de pilot waren gemaakt, pas later tegen het licht gehouden. Dit is een belangrijk leerpunt waar ik bij volgende projecten vanaf het begin alert op moet zijn. Een volgende keer wil ik meer op mijn eigen kennis en inzicht koersen. Het was voor mij (en voor het project) erg nuttig om bij alle aanvragende afdelingen langs te gaan om het aanvraagproces te kunnen doorgronden. Ik heb het ook erg plezierig gevonden en denk dat ik hierin ook meerwaarde te bieden heb. Ik wil dit graag in toekomstige projecten verder ontwikkelen. Verder heb ik opnieuw gemerkt dat ik graag “deskundig” ben op een bepaald onderwerp. Het is voor mij een basis om adviezen te kunnen geven en beslissingen te nemen. In de loop van dit project ben ik steeds beter op de hoogte geraakt van de ins en outs van digitaal aanvragen, wat voor mij waardevolle kennis is.
12.2
Projectmanagement
Dit project heeft me een stuk verder gebracht op het gebied van project management. Ik heb nu veel kunnen werken met projectteams voor het ontwerp en de te maken keuzes. Mijn ervaring met het externe project in het CWZ in Nijmegen is hierbij van groot belang geweest. Het maken van een projectplan en een planning, het bijhouden van de benodigde documentatie en het werken met een stuurgroep zijn allemaal onderdelen die ik in het CWZ een eerste keer heb uitgevoerd. Alles wat ik daarin geleerd heb is me goed van pas gekomen bij dit jaarproject. Ook de cursus van Mark van Onna heeft veel waarde gehad. Het heeft de principes van projectmanagement goed duidelijk kunnen maken, en ook het belang van een grondige initiatiefase. Ik had wel graag meer geleerd over tools om een planning te kunnen maken, maar vooral ook bij te kunnen houden. Ik heb daarom later nog een cursus MS Project gedaan, al zou dat beter werken als ik dit direct had kunnen toepassen. Bij de samenstelling van een stuurgroep zou ik nu zeker ook een eindgebruiker kiezen. Nu is de aandacht vooral naar het technisch ontwerp gegaan, een eindgebruiker zou de procesoptimalisatie meer centraal hebben kunnen stellen. Het benoemen van verschillende projectteams was in dit geval weinig zinnig. Het gaf mijzelf in eerste instantie wel overzicht, maar al snel bleek dat per onderwerp dat besproken moest worden, vanzelf wel duidelijk was wie aan moest zitten. In de planning van het project hebben we (ikzelf en stuurgroep) geen rekening gehouden met vertraging door de leveranciers. Zowel Chipsoft als Philips waren zeer traag met reageren, en ook toen duidelijk was dat het MMC hier in ieder geval mee door wilde gaan, lukte het niet om op tijd een planning voor de implementatie te verkrijgen. Extra lastig was dat beide firma's niet konden (of wilden) aangeven op welke termijn zij wel aan de slag zouden kunnen gaan. Hun beleid is dat ze pas een planning afgeven na het tekenen van een offerte, maar ook daarna heeft het nog lang geduurd. Dit heeft tot gevolg gehad dat ik qua projectmanagement minder af heb kunnen handelen dan we vooraf hadden ingeschat. Het is dus van groot belang om al veel eerder met een concreet jaarproject te kunnen starten, zodat er uitlooptijd is om dit soort vertragingen op te kunnen vangen. Omdat telkens niet duidelijk werd hoeveel langer het nog zou gaan duren, was het ook niet mogelijk om naar een serieuze alternatieve opdracht om te zien. Ik vind het in ieder geval een gemis dat ik de daadwerkelijke technische implementatie niet bij kan wonen.
47
12.3
Gebruikte kennis uit het curriculum
Het RDZ is een goed bruikbaar hulpmiddel gebleken. Het verschafte een conceptuele basis om de verschillende ontwerpen langs te leggen. Hierbij heb ik ook opgemerkt dat er nog wel wat te verbeteren is aan de RDZ, hiervoor heb ik een RFC ingediend bij Fred Smeele van iZiekenhuis. Het gebruik van het RDZ levert ook bruikbare en overzichtelijke schema's op. Hier kan ik bij presentaties richting stakeholders goed gebruik van maken. Ik heb kennis gemaakt met Archimate voor het uitwerken van de opdrachten B1 en B2. Tijdens de colleges vond ik deze cursusonderdelen nog totaal onbegrijpelijk. Een van beide docenten was ook didactisch zeer ontoereikend. Ik heb daarom erg tegen deze opdrachten opgezien, maar het gebruik van het RDZ en Archimate heeft geholpen om de concepten helder te krijgen. Ook omdat ik tijd kon besteden aan de uitwerking, heb ik er alsnog veel van geleerd. Ik zal zeker ook in de toekomst gebruik blijven maken van de hiermee verworven kennis.
12.4
Zorginformatie
Deze afdeling staat middenin het werkgebied van een klinisch informaticus. Zij vormen een directe schakel tussen de business / zorg en de ICT. Ik heb veel kunnen opsteken van de applicatie-‐ en functioneel beheerders, en van de andere projectleiders. Ik heb hierdoor meer inzicht gekregen in wat er allemaal speelt op het gebied van zorg-‐ICT, en wat daar de mogelijkheden en obstakels in zijn. Het bijwonen van het teamoverleg en het projectleidersoverleg heeft voor mij veel relevante kennis en informatie opgeleverd. Zo ook het sparren met de opdrachtgever en alle inhoudelijke kennis die ik daarbij heb opgedaan. Dit heeft me (opnieuw) enthousiast gemaakt voor de rol die ik in dit werk graag wil invullen: intermediair tussen zorg en ICT. Bij het werken op deze afdeling heb ik de volgende dingen geleerd die ik in voorkomende gevallen zeker voor ogen zal houden: -‐ Neem voldoende tijd voor de intake. Zorg zoveel mogelijk te weten te komen van wensen, doelen, context en (on)mogelijkheden van de aangevraagde functionaliteit. -‐ Trek voldoende tijd en aandacht uit voor een diepgravende procesanalyse. Niet toegeven aan de drang om stappen te maken: tijd die nu geïnvesteerd wordt betaalt zich later terug. -‐ Zet procesanalyse op papier, zo mogelijk met schema's (Visio, Archi). Laat dit door gesprekspartners beoordelen, verbeteren, en uiteindelijk accorderen. -‐ Zet voorgesteld proces ook op die manier op papier en laat dit accorderen door alle betrokkenen. -‐ Maak gebruik van plaatjes in de communicatie! -‐ Maak heldere, leesbare en bruikbare instructies. Laat deze eerst door een panel beoordelen. -‐ Zorg dat iedereen daadwerkelijk instructie krijgt. Dus: namenlijst afstrepen. Niet 1 of 2 mensen instrueren die het vervolgens (half-‐half) door moeten geven aan collega's. -‐ Zorg dat instructie op een moment plaatsvindt dat iedereen ook echt aanwezig kan zijn voor alleen dat doel, bv. overdrachtsmoment, onderwijsmoment, werkoverleg etc. -‐ Geef instructies in samenwerking met opdrachtgever of stakeholder, in dit geval PAMM. -‐ Volg na invoering op: meteen (eerste week), na 1-‐2 maanden, na een half jaar. -‐ Hanteer een uniforme werkwijze bij projecten. Tijdens de opdracht heb ik wel soms geconstateerd dat de werkwijze rond projecten binnen het MMC niet optimaal is. Er is naar mijn idee nog onvoldoende transparantie rond de beslisstructuur rond zorg-‐ICT en ook nog weinig structuur in de aanpak van projecten. Uitvoeren lijkt het soms te winnen van probleemanalyse en onderzoek naar verschillende oplossingsrichtingen. Ook zou er gestreefd kunnen worden naar meer uniformiteit in bijvoorbeeld het EPD. Nu heeft ieder specialisme, iedere afdeling zijn eigen werkwijze en lay-‐out, wat de begrijpelijkheid en beheersbaarheid niet ten goede komt.
48
13 Referenties en gebruikte externe kennis BR/CU-‐2121 Prestaties en tarieven medisch specialistische zorg. NZa, 05-‐05-‐2014. Documentatie HL7 v2.4 – v2.6 Health Level 7 2.x Introduction. Presentatie van J. Forbes en S. Phantasomchit, 2005. HL7 v2.4 implementation guide. HL7 v2.6 implementation guide. Een checklist voor informatie-‐uitwisseling in de zorg. Nictiz, Den Haag, 13 november 2012 ICT-‐standaarden in de zorg. Een praktisch overzicht. Nictiz, Den Haag, september 2012. NEN7510-‐2011 Medische informatica – Informatiebeveiliging in de zorg. Nederlands Normalisatie-‐instituut, oktober 2011. Referentiedomeinenmodel ziekenhuizen versie 2.2. Nictiz, Den Haag, 31 maart 2014. (http://www.nictiz.nl/rdz) Informatie andere ziekenhuizen: Bespreking Ronald Swinkels UMCU 20140410 Bespreking Maarten Nagelkerke juni 2014 Bespreking Patrick Lubbers AVL NKI mei 2014 User Centered Design: http://en.wikipedia.org/wiki/User-‐centered_design
Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY. Norman, Donald A. (1988). The design of everyday things, The Perseus Book Group.
49
1
