Introduktion

I det følgende gives en oversigt over de vigtigste opgaver og aktiviteter i forbindelse med et tilslutningsforløb. Formålet med oversigten er at sikre, at de nødvendige aspekter huskes og overvejes.


Afdækning af test- og uddannelsesbehov

SDS udstiller et antal fælles testmiljøer, der har hver deres formålserklæring:

MiljøAnvendelse
TEST1

Et ”dynamisk testmiljø” i den forstand, at det primært anvendes af applikations udviklere, der kan have behov for hurtig response og ny version. Selv om TEST1 kan være mere ustabilt end TEST2, anbefaler vi udviklere at

anvende TEST1, for at få fundet fejl i det miljø, så der er muligt at holde TEST2 mere stabilt. Ny funktionalitet er også altid først tilgængeligt i TEST1.

TEST2Et mere stabilt miljø, hvor primært brugere tester nye klient-applikationer, der gør brug af ny ikke releaset funktionalitet. Miljøet giver således mulighed for at teste og afprøve  klient funktionalitet mod nye snitflader. Miljøet anvendes typiske også af klient udviklere op mod aflevering af nye releasen til brugerne.
UDDEt miljø, hvor stabilitet og forudsigelighed er prioriteret højt. Stamdata opdateres relativt sjældent, så opgaven med at holde undervisningsmateriale opdateret balanceres op mod ønsket om ”friske” stamdata fra produktionsmiljøet.

PRODTEST

Et produktionslignende miljø, hvor de udstillede nationale services og NSP’ens infrastrukturkomponenter har samme versioner som i produktionsmiljøet.

Det skal afdækkes, om de lokale behov for test- og uddannelse kan opfyldes ved brug af disse miljøer, og det skal beskrives, hvilke miljøer der ønskes anvendt fra de enkelte lokale it-systemer.

For yderligere information omkring hvad der deployes på hvilke testmiljøer se også NSP deploymentregler.

Vilkår for anvendelse af de fælles testmiljøer - indgåelse af aftale

NSP-operatøren er ansvarlig for de fælles testmiljøer, og der skal indgås en aftale med NSP-operatøren om anvendelse af de fælles miljøer, før test kan etableres.

Der er udarbejdet et Bestillingsark for adgang til eksternt testmiljø for en sådan aftale, der skal udfyldes og indsendes til NSP-operatøren via SDS´s Nationale Servicedesk.  Det er NSP-operatøren, der sikrer SDS prioritering og tilbagemelding om, hvornår testmiljøet kan etableres.

Overholdelse af fælles ”spilleregler”

I de fælles testmiljøer vil der være mange anvendere i de enkelte miljøer samtidig. Alle anvendere har adgang til at se alle data, også testdata ”ejet” af andre parter, men ikke mulighed for ændre i andres test-Stamdata.

Man kan godt rette i andres kliniske data. Der er ingen begrænsninger i nogen af de kliniske services, der laver adgangskontrol ud fra ejerskab af test-patienter.


Det er nødvendigt at parterne i fællesskab underlægger sig et sæt fælles ”spilleregler” for anvendelsen af hvert miljø. Dette kan opleves som en begrænsning og en risiko, og der er behov for intern styring af hvilke data, testbrugere i en given organisation bruger til hvilke formål.

Overordnet betyder dette:

  • Alle har adgang til og kan se alle testdata
  • Der må kun rettes i test-stamdata, oprettet og ”ejet” af den enkelte testbruger
  • Man kan godt rette i andres kliniske data. Der er ingen begrænsninger i nogen af de kliniske services, der laver adgangskontrol ud fra ejerskab af test-patienter.

  • For abonnementer oprettet på testmiljøerne i komponenten NAS anbefales at anvender sørger for at nedlægge abonnementer, der ikke er brugt inden for de sidste 30 dage
  • Der må ikke laves performancetest på de fælles testmiljøer
  • En kritisk test, der anvender de fælles testmiljøer, skal varsles med 10 arbejdsdage til National Servicedesk

Tilsvarende er miljøerne konfigureret til de formål, der er vedtaget af anvenderne i fællesskab. I praksis betyder det, at miljøerne ikke kan skræddersys til en enkelt anvenders behov.

Forud for indgåelse af en aftale med NSP-operatøren forpligter den enkelte anvenderorganisation sig på at overholde de fælles ”spilleregler”.

NB - der er ikke implementeret en teknisk sikring af at retningslinjerne overholdes, ej heller automatiseret overvågning af anvendernes adfærd. 



Testpatienter og testCPR nr.

Testpatienter og tilhørende testCPR nr. oprettes i DTG af testbruger. Testbruger 'ejer' jf. fælles 'spilleregler' disse testpatienter. I forbindelse med oprettelse af testpatienterne checkes det ønskede tilhørende testCPR nr. op mod CPR datasamlingen i produktion, for at undgå en cifferkombination der kan forveksles med et gyldigt CPR nr. i produktion.

Bemærk: Dette gøres alene i forbindelse med oprettelsen af testpatienten. Det anbefales derfor, at testbruger efterfølgende løbende checker om et testCPR nr./den givne cifferkombination ligner et gyldigt CPR nr. i produktion. Hvis dette er tilfældet, anbefales det at testbruger 'sletter' denne cifferkombination som testCPR (lader testCPR dø og fraskriver sig ejerskab) og erstatter det med oprettelsen af en ny cifferkombination i DTG.


Regioner og LPS’er

Fælles "spilleregler" aftalt mellem regioner og LPS’er kan findes her.

Specielle betingelser for TEST1

Formålet med TEST1 er  defineret som tidlig afprøvning af services der forventes i produktion med fokus på en række tværgående aspekter ved en service, uanset om det er en ny funktionalitet eller eks. fejlrettelse (såkaldte ”hotfixes”) til eksisterende (produktions)versioner.

Udviklingsprojekter hos leverandører kan anvende TEST1 efter forudgående aftale med Operatør om anvendelse og forbrug af ressourcer i NSP set-up'et.

Ønsker om anvendelse af TEST1 over en længere periode (op til 3 måneder) kan ligeledes aftales med Operatøren. Betingelserne for denne anvendelse af TEST1 er:

-          At der ikke samtidig køres eller forventes release af andre versioner af den pågældende service og de services der skal integreres til i TEST 1 miljøet

-          At der til integrationstest af nationale services, kan anvendes generelle services – m.a.o. at der ikke er afhængigheder til anvendelse af specifikke versioner af andre services, eks. STS.

-          At der til integrationstest anvendes generelle testdata fra testmiljøet – m.a.o. at der ikke er afhængigheder til specialdesignede testdata på tværs af platformen.

Såfremt foranstående betingelser ikke kan opfyldes af projektet, vil Operatør stille krav om, at dedikeret testmiljø oprettes af projektet.

Tilslutningsguide

Se dette dokument for flere informationer: Tilslutningsguide-Anvendere.

Testcertifikater

Se dette dokument for at få en vejledning til oprettelse og vedligehold af testcertifikater: Vejledning testcertifikater

OBS: det er væsentligt af eks. kommunens eget cvr nr. indgår i testcertifikat - et tilfældigt test cvr nr kan ikke anvendes på NSP. Se evt vejledning om oprettelse af testcertifikat i eget cvr nr. her: testorganisationer-i-pre-produktionsmiljø.pdf

Formular til test adgang: Findes her

Endpoints for testmiljøer til regioner, Læge Praksis Systemleverandører og kommuner

Se dokument om endpoints til testmiljøerne her.