Over OTAP
Voordat de medische informatietechnologie in gebruik kan worden genomen moet de gehele medische informatietechnologie getest en gevalideerd worden. Hiervoor wordt vaak een OTAP-omgeving ingericht. Dit acroniem staat voor:
- Ontwikkelomgeving (meestal alleen bij de fabrikant)
- Testomgeving (onderdeel van de initiële installatie)
- Acceptatieomgeving (een recente kopie van de Productieomgeving inclusief de koppelingen)
- Productieomgeving (de uiteindelijke productieomgeving)
Het accent van de testen ligt vooral op het controleren van een goede werking van de software, het goed functioneren van alle koppelingen en interfaces en het correct bewerken en verwerken van de aangeboden data in de bijbehorende workflow van de zorginstelling. Wanneer het gehele systeem correct functioneert en aan de overige randvoorwaarden is voldaan, kan de medische informatietechnologie klinisch in gebruik worden genomen.
Wat heb ik voor een OTAP nodig?
Voor validatie/verificatie van medische informatietechnologie (inclusief de keten) is het noodzakelijk om naast de productie- (klinisch gebruik) ook een acceptatieomgeving beschikbaar te hebben. Hierbij is het belangrijk dat de acceptatieomgeving een representatieve omgeving is. Denk hierbij aan de gehele keten tijdens het klinisch gebruik, en bij databases bijvoorbeeld aan de load voor realistische performance-testen (regressietesten).
Hierbij moet dus ook gedacht worden aan de gekoppelde randapparatuur en/of in- en externe datakoppelingen. Om een OTAP in te richten is ook een beschrijving van het technisch en functioneel ontwerp noodzakelijk, zoals de aanwezige technische koppelingen en interfaces. IT-architecten vertalen het technisch en functioneel ontwerp in een zogenaamde architectuurplaat. Hierop zijn alle onderlinge afhankelijkheden zichtbaar gemaakt.
Wat zijn aandachtspunten bij een OTAP-inrichting?
De verschillende O-,T-, A- en P-omgevingen zijn virtueel dan wel fysiek van elkaar gescheiden.
De praktische invulling van een OTAP-omgeving kan van diverse factoren afhankelijk zijn, zoals de complexiteit van de te beoordelen softwareapplicaties en de complexiteit en inrichting van de eigen organisatie. Er moeten minimaal een A- en P-omgeving zijn. Relevante informatie en tools die helpen om een OTAP-omgeving op te zetten zijn bijvoorbeeld:
- ITIL-processen;
- ANTILOPE - Adoption and take up of standards and profiles for eHealth Interoperability;
- IHE Connectathon/DICOM.
Voor deze koppelingen moeten mogelijk op basis van de praktische uitvoerbaarheid en de inrichting van de infrastructuur specifieke keuzes worden gemaakt. Kun je bijvoorbeeld de functionele of gebruikerstesten in een acceptatieomgeving overal in de organisatie uitvoeren of alleen op specifieke werkstations (zijn deze representatief voor productie)? Of zijn er afhankelijkheden met het netwerk door IP-filteringen waardoor er een verschil met de uiteindelijke productieomgeving is? Voor het netwerk wordt voor medische toepassing veelal een VLAN gecreëerd – een virtueel gescheiden netwerk.
Praktische uitdagingen bij een OTAP
Het is in de praktijk niet altijd eenvoudig om een OTAP in te richten. Hieronder geven we een aantal voorbeelden van praktische uitdagingen.
• Bij koppelingen in zijn algemeenheid bijvoorbeeld met ADT is het belangrijk te borgen dat er geen naar echte patiënten herleidbare productiedata in de OTA-omgevingen beschikbaar of zichtbaar zijn.
• Een Patiënt Data Management Systeem (PDMS) waarbij via een specifieke gateway de HL7-verstuurde vitale parameters in het PDMS-systeem komen. Als verantwoordelijke organisatie zou men afhankelijk van de geïnventariseerde risico’s voor de acceptatie op basis van de productieomgeving een ‘mini’ patiëntmonitoringsysteem (bedzijdige patiëntbewakingsmonitor en centraal post) en een HL7-gateway kunnen inrichten. Dit geeft mogelijk naast financiële uitdagingen, gezien het fysiek scheiden van de omgevingen, ook netwerkarchitectuurtechnische uitdagingen. Een oplossing kan hierbij het werken met virtuele netwerken en domeinen zijn.
• Een update van een Medisch Oproep Systeem (MOS-) en/of Medisch Alarm (MA-) keten. Hierbij kan het – afhankelijk van de aanwezige infrastructuur en de gebruikte devices, zoals oproep-pagers – lastig zijn een representatieve test- en acceptatieomgeving te maken. Bijvoorbeeld vanwege kosten of hoge infrastructuureisen. Voor de oproeppagers is naast een IT-oplossing via wifi ook veelal een specifieke infrastructuur met HF-zenders aanwezig. Omdat het om primaire alarmeringsvoorzieningen gaat is het testen en accepteren een heel belangrijk onderdeel van het validatieproces. Om toch te kunnen valideren kan een oplossing zijn om het systeem in de productieomgeving te testen of om het systeem gefaseerd (afdeling voor afdeling) over te zetten naar een nieuwe softwareversie. Ook kan het een optie zijn om in overleg met de zorgafdeling het MOS/MA gedurende een afgesproken tijd uit de lucht te halen om alle benodigde werkzaamheden uit te voeren. De afdeling kan zich dan voorbereiden door maatregelen te treffen, zoals het permanent bezetten van de centrale post met de centrale bewakingsmonitoren.
• Aanpassing in het TBI-dosisberekeningsprogramma. Hierbij is alleen de ontwikkelomgeving afwijkend ten opzichte van de situatie met niet-zelfontwikkelde software. In deze omgeving kunnen programmeurs de eerste verkennende stappen zetten om de software te wijzigen, zonder meteen een geheel nieuwe versie te bouwen. Als er bijvoorbeeld berekeningen in Excel worden gedaan, kan experimenteel worden bekeken of de software ook werkt met een nieuwe versie van Excel. Indien nodig kan men dan enkele wijzigingen in de eigen software programmeren. Zie ook Praktijkvraag 8 bij de fase gebruik.
• Validatie van een virusscan. De OTAP-omgeving wordt gebruikt om te testen in hoeverre een kritische update om virussen te voorkomen invloed heeft op de softwareapplicatie. Veelal worden deze virusscans als kritische update beschikbaar gesteld, het is belangrijk om samen met de fabrikant afspraken te maken over het doorvoeren van deze updates. Een aantal van deze aandachtspunten is in de Standaard Service Overeenkomst (SSO) opgenomen, het advies is om deze te hanteren.
Hoe kan ik mijn OTAP up-to-date houden?
Bij de inrichting van een OTAP is het representatief houden van de verschillende OTAP-omgevingen noodzakelijk. Dit kan bijvoorbeeld door het up-to-date houden van de configuratiemanagementdatabase (CMDB). Idealiter wordt in een CMDB alle beschikbare informatie opgeslagen: pc’s, werkstations, servers, applicaties, licenties en gebruikers.
Met zo’n database kunnen allerlei relaties worden gelegd en is te zien welke applicaties gebruikmaken van welke servers en databases, wie de gebruikers zijn en wie de beheerders zijn. Zowel bij het oplossen van storingen als het doorvoeren van wijzigingen is dergelijke informatie van groot belang.
Bij wijzigingen in de CMDB kan er een check plaatsvinden of er een impact met de OTAP-omgevingen is. Dit kunnen naast hardware ook softwareversies zijn. Het is dan ook cruciaal dat alle betrokken partijen toegang hebben tot de informatie in de CMDB en zich verantwoordelijk voelen om alle informatie in deze database gedurende de gehele levenscyclus van de medische informatietechnologie up-to-date te houden.