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, waarmee en door wie. Vervolgens technisch testen door technici, alle testgegevens door de verschillende modules halen om te meten of het werkt. Dan functioneel testen door eindgebruikers, nu het technisch werkt beoordelen 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?
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?
Acceptatietesten: los van technische en functionele testen zijn er acceptatiecriteria vastgesteld waar elke regio aan moet voldoen. (documentatie, helpdesk, etc). Belangrijkste vraag is hier: Mag het in de praktijk gebruikt worden?
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 regio,
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 zijn zwanger en hebben suikerziekte)
Hiervoor zijn verschillende use-cases, bijvoorbeeld:
Iedere regio heeft een eigen testzwangere waarbij alleen die regio gegevens invoert over die testzwangere en gegevens verspreid staan over alle betrokken bronsystemen in die regio,
Er zijn ook landelijke testzwangeren met gegevens verspreid over élke regio in de productieomgeving, elke regio kan testgegevens toevoegen over die testzwangeren.
Het modulair ontwerp, en de daarmee samenhangende standaardisatie van gegevensuitwisseling, maken modulair testen mogelijk.
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
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. 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)
Wat is de “eenheid van taal”?
Eenheid van taal is een afspraak (of een standaard). Het is een essentieel en centraal deel van de interoperabiliteit geboortezorg. Als elk systeem gegevens volgens een eenheid van taal, beschikbaar kan stellen, kan elk ander systeem daar gebruik van maken.
(Ooit was dat in mensentaal geprobeerd in Esperanto. Nu lijkt het steeds meer dat ieder het Engels gebruikt.)
Voor de digitale wereld is zowel de taal (sematisch) als het formaat (syntactisch) belangrijk.
Voor de geboortezorg is gekozen voor de informatiestandaard PWD 3.2.
Deze informatiestandaard is gebaseerd op ZIBs, in HL7-FHIR gecodeerd in SNOMED-CT.
Als een bronsysteem niet zelf FHIR als output levert, wordt de wel beschikbare output getest tegen een vastgestelde definitie. Een convertor moet die vastgestelde definitie kunnen 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.
0 Comments