Test strategie

Bij het testen voor VIPP Babyconnect, wordt alleen interoperabiliteit getest. Het testen van de verschillende bronsystemen zelf, valt buiten de scope.

De test strategie is grof in te delen in 4 delen: voorbereiden, technisch testen, functioneel testen, toetsen.

Het eerste deel is de voorbereiding, welke data moet getest worden.

Vervolgens technisch testen, waarmee en door wie. Alle testgegevens door de verschillende modules halen om te meten of het werkt. Door technici, in de kartrekker regio’s.

Dan functioneel testen door eindgebruikers. Nu het technisch werkt beoordelen de eindgebruikers of de gegevens correct geraadpleegd kunnen worden.

En dan toetsen door het LPB en het misterie. Nu de eindgebruikers akkoord zijn moet nog beoordeeld worden of voldaan wordt aan de acceptatiecriteria en de beleidsregels.

We maken onderscheid in verschillende soorten beoordelingen: Testen en toetsen. Testen is essentieel en moet altijd gedaan worden. Toetsen is alleen benodigd voor de afronding van het VIPP programma.

Technische testen: dit is hoofdzakelijk ‘onder de motorkap’. Hierbij zijn de technici en analisten de belangrijkste testers. Belangrijkste vraag is hier: Werkt het? Deze testen hoeven niet door elke zorgaanbieder in elk systeem gedaan te worden. Als een aangewezen groep heeft beoordeeld dat een functie technisch werkt, kunnen alle andere eindgebruikers daarvan uitgaan.

Functionele testen: dit is hoofdzakelijk ‘boven de motorkap’, Dit zijn de belangrijkste testen. Deze testen zullen worden uitgevoerd als technische testen voldoende gereed zijn, hierbij zijn de eindgebruikers de belangrijkste testers. Belangrijkste vraag is hier: Levert het wat nodig is? Essentie van deze testen is dat er integraal getest wordt. In een viewer zijn dan alle relevante gegevens te raadplegen, ongeacht waar die zijn vastgelegd, of in welk systeem die zijn vastgelegd.

Acceptatietesten: los van technische en functionele testen zijn er acceptatiecriteria vastgesteld waar elk regionaal partnerschap aan moet voldoen. (documentatie, helpdesk, etc). Belangrijkste vraag is hier: Mag het in de praktijk gebruikt worden? Essentie van deze testen is of alles organisatorisch en juridisch correct geregeld is.

Toetsen: voor het subsidieprogramma VIPP Babyconnect zijn toetsen vastgesteld door het ministerie. Op basis van de toetsen wordt de werkelijke waarde van de subsidie vastgesteld. Toetsen is een eenmalige activiteit.

Testen worden op lokale, regionale en landelijke schaal uitgevoerd.

Met lokaal wordt bedoeld: bijvoorbeeld het direct testen van een verbinding tussen twee modules, en het PEN-testen van een gegevensuitwisseling, (Een pentest (penetratietest) is een test waarbij ethical hackers systemen onderzoeken op kwetsbaarheden.)
Met regionaal wordt bedoeld: het beoordelen van de resultaten van gegevens van testzwangeren die zijn vastgelegd door zorgverleners in de regionale partnerschap,
Met landelijk wordt bedoeld: het door landelijke eindgebruikersgroepen, beoordelen van de resultaten van gegevens van testzwangeren, die zijn vastgelegd door zorgverleners uit meerdere regio’s.

Wat is een module?

Een module is een toepassing die een taak uitvoert. Een module kan een zorg informatiesysteem zijn, of een vertaler, of een opslag, of een viewer, etc.
Interoperabiliteit kan soms bereikt worden door twee modules, en soms zijn er meerdere modules nodig. In Interoperabilteit geboortezorg zijn meerdere modules nodig.

Wat is een eindgebruikersgroep?

Een eindgebruikersgroep is een groep mensen die gebruik maakt van gegevens die van een cliënt/patiënt zijn vastgelegd.

Bij Interoperabiliteit Geboortezorg herkennen we 4 eindgebruikersgroepen

De cliënt/patiënt (de zwangere, kraamvrouw)
De zorgverlener
De zorgorganisatie (zorgaanbieder)
De onderzoeker

De eerste twee eindgebruikersgroepen zijn betrokken bij de primaire zorg en maken gebruiken van de persoonlijke gegevens van de cliënt.

De andere eindgebruikersgroepen gebruiken de gegevens alleen secundair. Deze gegevens zijn anoniem. (Bijv: aantal vrouwen per provincie, die zwanger zijn en suikerziekte hebben)

Voor het testen zijn verschillende use-cases ontworpen. Voor het technisch testen zijn er 10 use cases waarin alle relevante velden van het PWD minimaal eenmaal gebruikt zijn.

Voor het functioneel testen heeft iedere regionale partnerschap en eigen testzwangere waarbij alleen die regionale partnerschap gegevens invoert over die testzwangere en gegevens verspreid staan over alle betrokken bronsystemen in die regionale partnerschap.

Er zijn ook landelijke testzwangeren met gegevens verspreid over élke regionale partnerschap in de productieomgeving, elke regionale partnerschap kan testgegevens toevoegen over die testzwangeren.

Het modulair ontwerp, maakt modulair testen mogelijk. Nadat elke module voldoet, kan het geheel getest worden ter acceptatie.

Elk zorgverlener systeem heeft technisch twee taken uit te voeren.

Het kunnen activeren van een viewer via een SSO routine
Het beschikbaar kunnen stellen van bron gegevens

Deze technische testen worden uitgevoerd door een zogenoemde “kartrekker regio“. In deze regio wordt een zorgverlener systeem technisch getest. Het resultaat is dan voor alle andere regio’s beschikbaar.

Wat is SSO?

SSO staat voor Single Sign On. Hiermee wordt bedoeld dat een eindgebruiker niet opnieuw hoeft in te loggen in een andere applicatie. Vanuit het eigen zorg informatiesysteem moet de zorgverlener direct naar een externe viewer kunnen. Het moet voor de zorgverlener geen extra handeling zijn. De zorgverlener is al ingelogd in het eigen systeem en staat al in het scherm van de cliënt/patiënt. Dan zijn alle benodigdheden al bekend om veilig een andere applicatie op te starten.

Een viewer moet gegevens kunnen presenteren uit elke bron (FHIR). Het is hier essentieel dat er gewerkt wordt met de “eenheid van taal”. Als eenheid van taal is voor de Geboortezorg vastgesteld dat dit FHIR resources zijn, vastgesteld volgens ZIBs, gecodeerd in Snomed-CT en gebaseerd op het PWD. (Perinataal Woordenboek en Dataset)

Als een bronsysteem niet zelf FHIR als output levert, wordt de wel beschikbare output getest tegen een vastgestelde definitie. (Bijvoorbeeld in XML, of in ORU) Een convertor moet die vastgestelde definitie ombouwen naar HL7-FHIR.

Een PGO moet een vastgestelde HL7-FHIR set kunnen verzamelen. Die test wordt uitgevoerd door MedMij en resulteert in een kwalificatie.
Een MedMij kwalificatie is vereist voor het mogen leveren van gegevens aan een cliënt/patiënt.