Godkjenning og forankring

Endringslogg Versj. Dato Kapittel Endring Produsent Godkjent av 1.0 19.07.11 Alle Alle Ervin Reyes Marit Endresen Godkjenning og forankring Godkjenning Godkjent av (Sign.) Godkjent dato: Godkjent Marit Endresen 19.07.11 Saken har vært forelagt følgende aktører (sett kryss) Apotek Bandasjist Legemiddelverket Oppgjør og kontroll (Helsedir) Andre: Norsk Helsenett Utbredelsesprosjektet Rekvirentprosjektet (Helsedir) Referanse til sak: Side 1 av 20

INNHOLDSFORTEGNELSE Godkjenning og forankring...1 1 Innledning...3 1.1 Målgruppe...4 1.2 Målsetting med dokumentet...4 1.3 Formål og avgrensning...5 2 Definisjoner...5 3 Overordnet om testing av e-reseptmeldinger...6 3.1 Samhandlingsskjeden e-resept...6 3.2 E-reseptmeldinger...7 3.3 Hvilke type test tilbys...9 3.4 Implementeringsmatrisen...9 4 Testmiljø...14 5 Testdata...14 5.1 Innhold testdata...14 6 Planlegging og gjennomføring...16 6.1 Bestille testgjennomføring...16 6.2 Forutsetning...17 6.3 Planlegging...18 6.4 Gjennomføring...18 6.5 Avslutning...19 6.5.1 Testrapport...19 6.5.2 Godkjenningskriterier...19 6.5.3 Avvik...19 7 Vedlegg...20 A.1 Sjekkliste etter test...20 A.2 Mal for testrapport...20 A.3 Mal for releasenotes...20 Side 2 av 20

1 Innledning E-resept er en samhandlingskjede mellom ulike private og offentlige aktører som knyttes sammen i en helhetlige elektronisk forløp for å håndtere rekvirering av alle reseptpliktige legemidler samt medisinsk forbruksmateriell og næringsmidler som omfattes av blåreseptforskriften. Følgende aktører omfattes av denne rutinen: Systemeiere og virksomheter med bestillingsansvar overfor systemleverandører i e-resept: Helsedirektoratet Legemiddelverket Apotekkjedene Rekvirentprosjektet (bestiller ansvar ovenfor rekvirent) Brukere: Systembrukere som det enkelte apotek, bandasjister, legekontor Leverandører: NAF-data EDB Ergogroup Ardis Infodoc Profdoc Hove Theriak NHN Medilink DIPS Buypass NAV SLV Side 3 av 20

Foreninger med fag-/- og brukerkompetanse Legeforeningen Apotekforeningen BNU Andre aktører Det er en rekke tiltak som er iverksatt på nasjonalt nivå for å skape sikkerhet rundt elektroniske meldingsutveksling. En viktig forutsetning for høy kvalitet er at meldingen blir testet ut før de tas i bruk. Testing av meldinger er krevende i forhold til antall meldinger og mengde systemer. Det er utfordrende å tilrettelegge for riktige testmiljøer og velge den riktige testmetodikk for de ulike testene som er nødvendig. Dette dokumentet vil ta for seg hvordan meldinger i e-resept skal testes før en produksjonssetting. 1.1 Målgruppe Målgruppen av dette dokumentet er forvaltning av e-resept databehandlingsansvarlige testeledere testere prosjektledere systemeiere systembrukere. 1.2 Målsetting med dokumentet Målsetting med dokumentet er å sikre målgruppen har en prosessbeskrivelse og instruksjon om hva som må gjøres når e-reseptmeldinger skal kvalitetssikres i samhandlingskjeden før de settes i produksjon. Side 4 av 20

1.3 Formål og avgrensning Formålet med testarbeid i e-resept er å ivareta sikkerhet og effektivitet i e-reseptkjeden. Jfr. Reseptformidlerforskriften 1-2. Dokumentet er utarbeidet i tråd med erfaringer fra ulike testprosesser i e-reseptprogrammet. Dokumentet omhandler test av e-resept funksjonalitet og meldingsflyt, ikke generell test av det enkelte system. Prosessen involverer ikke sykehus og andre helseforetak. 2 Definisjoner Systemtest Systemtest gjennomføres for å sikre arbeidsflyt som støtter eget e-resept grensesnitt og korrekt samspill mellom systemene som inngår i e-resept. Denne testen har som mål å avdekke feil og mangler knyttet til funksjonaliteten i løsningen før det gjennomføres akseptansetest koordinert av Helsedirektoratet. Testen inneholder test av enkeltkrav i detaljerte e-reseptkrav. Akseptansetest Akseptansetest er den avsluttende formelle testen av den samlede e-reseptløsningen. Den gjennomføres under ledelse av e-reseptforvaltning. Testen har som mål å verifisere at alle meldinger som inngår i e-resept er i henhold til spesifikasjoner. Godkjent akseptansetest er nødvendig for å kunne løfte løsningen over i produksjon. Akseptansetest skjer på et tidspunkt der det er små muligheter for omfattende feilkorrigering og retesting. Testen fokuserer på positive tester. Side 5 av 20

Regresjonstest Ved regresjonstest gjentas det en eller flere testfaser for å verifisere at feilrettinger eller endringer ikke har ført til nye feil, og at løsningen fremdeles tilfredsstiller spesifiserte krav. Målet med regresjonstest er å teste alle eller enkelte av meldingene som flyter gjennom e-resept, ut fra en utvalgt del av de aktuelle testfasene. Retest Testen gjennomføres for å verifisere at feilrettinger eller endringer fungerer som spesifisert. 3 Overordnet om testing av e-reseptmeldinger 3.1 Samhandlingsskjeden e-resept Legen skriver ut en resept med bruk av FEST og sender deretter resepten elektronisk til Reseptformidleren. Herfra kan apoteket eller bandasjisten laste ned resepten og ekspedere når pasienten kommer for å få utlevert det legen har forskrevet. Deretter sendes et elektronisk oppgjør til HELFO for legemidler som omfattes av blåreseptforskriften. Det er opprettet et testrom på Helsedirektoratet hvor man kan simulere verdikjeden i e-resept. Her finnes infrastruktur som Norsk Helsenett, oppslag mot Buypass og kommunikasjon mot reseptformidleren. På testrommet er det installert ulike EPJ systemer, apotek og bandasjist. De ulike systemer kan settes opp mot reseptformidlerens ulike testmiljøer. Side 6 av 20

3.2 E-reseptmeldinger Meldingsnummer Meldingsbeskrivelse Implementert v2.4 FEST M30 Overføring av informasjon fra Legemiddelverkets FEST-system X Resepten M1 Resepten X Referansenummer Låst resept M4.1 M4.2 Tilbakekall Forespørsel om referansenummer Retur av referansenummer X M5 Tilbakekalling av resept X M7 Slette resepter i RF X Utleveringsmeldinger M6 Utleveringsrapport rekvirent (Rekvirent) X M8 Utleveringsrapport Kopi til fast lege X Forespørsel gyldig resept hos Apotek og Bandasjist M9.1 M9.2 M9.3 M9.4 Utleverers forespørsler om tilgjengelige resepter for en pasient Reseptliste til utleverer Forespørsel om nedlasting av resept Nedlasting av resept X Forespørsel gyldig resept lege M9.5 M9.6 Utlevering Rekvirentens forespørsler om tilgjengelige resepter for en pasient Reseptliste til rekvirent X M10 Utleveringsrapport X Individuell søknad om refusjon til HELFO M2 Individuell søknad om refusjon til HELFO X Side 7 av 20

Meldingsnummer M12 Meldingsbeskrivelse Implementert v2.4 Svarmelding fra HELFO Godkjenningsfritaksløsning M3 Grunnlag for søknad / Søknad godkjenningsfritak (Til Legemiddelverket) X M14 Søknad til Legemiddelverket X M15 Melding om godkjenningsfritak Søknadssvar fra Legemiddelverket X M20 Notifiseringsmelding X Forsendelses og ekspederingsanmodning M21 Ekspederingsanmodning X Elektronisk oppgjør til HELFO M18 Oppgjørskrav X M22 Oppgjørsresultat X M23 Utbetaling X Samtykke oppslag og registrering M24.1 M24.2 M26.1 M26.2 Multidose M25.1 M25.2 M25.3 Samtykkeregistrering Svar på samtykke Oppslag i fastlegeregister Svar fra fastlegeregister Varer i bruk (fra fastlege til apotek) Varer i bruk (fra apotek til fastlege, formidle forslag til justering) Varer i bruk (fra apotek til fastlege, informasjon om hva som er pakket og utlevert) X x Ikke implementert i v2.4 Side 8 av 20

3.3 Hvilke type test tilbys Akseptansetest av ny eller endret e-reseptfunksjonalitet Regresjonstest av ny eller endret e-reseptfunksjonalitet Retest av ny eller endret e-reseptfunksjonalitet 3.4 Implementeringsmatrisen Implementeringsmatrisen er et verktøy som benyttes for å vurdere feil og endring opp mot e- resept nærhet. Matrisen benyttes som en veileder i forhold til angrepsmåte for testgjennomføringen når en feil eller endring skal implementeres. Leverandøren vurderer omfanget av endringer foretatt i sitt system før oppgradering i produksjon skal gjøres. Eventuelle e-reseptfeilrettinger inngår som en del av dette grunnlaget. Ved rene feilrettinger må det vurderes spesielt omfanget av kodeendring 01 eller 02 og gruppering av kodeendringen, da spesielt E2 og E3, med tanke på å fastlegge nødvendig testing. Rutinen omhandler innføring av feilrettinger og endringer i produksjon i applikasjonene, samt alle endringer knyttet til e-reseptdokumentasjon og konfigurasjon. Med e-reseptdokumentasjon menes de sentrale dokumentene som danner grunnlag for e-resept. Overordnet funksjonell spesifikasjon Detaljert funksjonell spesifikasjon med vedlegg Meldingsdefinisjoner (gjeldene og støttende meldingsnummer) E-reseptarkitektur Kodeverksdokumentet Med konfigurasjon menes hardware og basis software til de sentrale systemene som inngår i e- resept. De sentrale systemen består av Reseptformidleren, Helfo oppgjørsløsning, Legemidellverkets FEST og NHN. Formålet med rutinen er å minimere risiko for feil og mangler i ordinærdrift ved innføring av nye endringer og feilrettinger. Med rutinen skal man sørge for at nødvendig systemtesting av Side 9 av 20

leverandøren og akseptansetest mellom aktørene blir foretatt før løsningen implementeres i produksjon. Rutinen bygger på følgende forutsetninger: Det vil være behov for feilrettinger og endringer som medfører oppgradering/justering av de systemene som benyttes i ordinær drift. Slike leveranser må være kvalitetssikret før de produksjonssettes Innføring av feilrettinger og endringer i produksjon er en samhandling mellom brukere og leverandører, andre systemer som utveksler e-reseptopplysninger og Helsedirektoratet som forvalter av reseptformidleren og e-reseptverdikjeden. I e-resept er det mange aktører som samhandler og det er derfor behov for å tilrettelegge for en mest mulig omforent forståelse for ved innføring av feilrettinger og endringer. Dette illustreres ved bruk av Implementeringsmatrisen. Side 10 av 20

Figur 1 Implementeringsmatrisen Forklaring til de tre sonene i Implementeringsmatrisen. Turkis sone Leverandøren er ansvarlig for kvalitetssikring og test og det er ikke krav til test mellom aktørene i eresept. Leverandøren må dokumentere feilrettingen og endringen i releasenotes som sendes pilotdeltageren og Helsedirektoratet. I releasenotes angir leverandør matrise kode, eks. E1, O1. Kodekombinasjoner i turkis sone: E1, O1 E1, O2 E2, O1 Side 11 av 20

Blå sone Leverandøren er ansvarlig for kvalitetssikring og test og å vurdere om test mellom aktørene i eresept skal gjøres. Dersom leverandøren er i tvil om test mellom aktørene er nødvendig, skal han søke råd hos Helsedirektoratet. Dersom leverandøren konkluderer med at koordinert test mellom aktørene er nødvendig, skal han melde behov for slik testing til Helsedirektoratet så tidlig som mulig. Helsedirektoratet avtaler testing med alle involverte aktører. Leverandøren må dokumentere feilrettingen og endringen i releasenotes som sendes pilotdeltageren og Helsedirektoratet. I releasenotes angir leverandør matrise kode, eks. E2, O2. Kodekombinasjoner i blå sone E1, O3 E2, O2 E3, O1 E3, O2 Side 12 av 20

Lilla sone Leverandøren er ansvarlig for kvalitetssikring og test og det er krav til test mellom aktørene i eresept på testrommet hos Helsedirektoratet. Leverandøren skal melde behov for slik test mellom aktørene til Helsedirektoratet så tidlig som mulig. Helsedirektoratet avtaler testing med alle involverte aktører Leverandøren må dokumentere feilrettingen og endringen i releasenotes som sendes pilotdeltageren og Helsedirektoratet. I releasenotes angir leverandør matrise kode, eks. E3, O3 Kodekombinasjoner i lilla sone og mail til Helsedirektoratet sendes E2, O3 E3, O3 E4, O1 E4, O2 E4, O3 Side 13 av 20

4 Testmiljø For å gjennomføre strukturerte akseptansetester og eventuelle regresjonstester i samhandlingskjeden i e-resept er det behov for å utføre dette på ulike testmiljø. Dette for å sikre best mulig kontroll på innhold i leveranser og i testdata. Det legges opp til flere testmiljøer mot Reseptformidleren. RF Utviklingsmiljø: kan benyttes i en tidlig utviklingsfase av nye meldingsversjoner, men er kun tilgjengelig over Internett (kun synkrone meldinger) og etter nærmere avtale RF Test 1 og Test 2: benyttes i forbindelse med leverandørenes systemtester, nyutviklet eller endret e-reseptfunksjonalitet og regresjonstest. Disse miljøene kan, etter forespørsel, gjøres tilgjengelig over Internett RF QA: benyttes i forbindelse med endelig akseptansetest i forkant av produksjonssetting - etter vurdering, ikke tilgjengelig over Internett Bruk av alle miljøer koordineres av e-resept forvaltning. All oppkobling og bruk av miljøene skal avtales på forhånd. Grensesnittdokumentet beskriver oppkobling mot de ulike miljøer i detalj. 5 Testdata Riktige testdata er viktig for å få til en strukturert test av e-reseptmeldinger 5.1 Innhold testdata For leger Legekontor: Hvilke legekontor benyttes? Leger (PKI): Hvilke leger benyttes? Pasienter: Hvilke pasienter benyttes? Side 14 av 20

For Apotek Apotek: Hvilke apotek benyttes? Pasienter: Hvilke pasienter benyttes? For Bandasjist Bandasjist: Hvilke bandasjister benyttes? Pasienter: Hvilke pasienter benyttes? For HELFO: Utleverer: Hvilke apotek og bandasjister benyttes? Side 15 av 20

6 Planlegging og gjennomføring Når en test skal gjennomføres er det viktig at bestilling om test og testens innhold sendes til Helsedirektoratet minst 4 uker i forkant av ønsket teststart. Bestillingen sendes til e-reseptforvaltning via e-resept samhandlingsverktøy, ERSA. For enkelte retester kan det aksepteres en kortere bestillingstid dersom særskilte forhold tilsier dette. 6.1 Bestille testgjennomføring Bestillingen legges inn som en sak i ERSA. Kategori Forespørsel benyttes under registreringen. Saken skal blant annet inneholde følgende informasjon: Informasjon om bestiller Hvilket system og versjon av systemet skal testes. Hvilke e-reseptmeldinger skal testes Formålet med testen Releasenotes innhold i leveransen. Releasenotes er et dokument som leverandører fyller ut når feilrettinger og endringer er utført og systemet som skal produksjonssettes er klar. Et releasenotes beskriver alle feilrettinger og endringer som er foretatt i den versjonen som skal produksjonsettes (uavhengig om feilretting/endring er relatert til e- resept) og benyttes i forbindelse med utarbeidelse av testscenarioer. Releasenotes må være mottatt av Helsedirektoratet før installasjon kan skje. Releasenotes skal inneholde følgende: Leverandør: Angir navn på leverandør. Versjon av e-reseptmeldinger: Angir hvilken versjon av meldingsdefinisjon som er gjeldende Navn og versjon av software: Angir software og versjonsnummeret som skal installeres Ident: Referanse til hvilke feil og endring som er rettet. ERSA ID benyttes for alle e-resept feil. Beskrivelse av feilretting/endring: Kort beskrivelse av hva som er rettet for en ikke teknisk bruker Side 16 av 20

Kode implementeringsmatrise: Angir kode i matrisen hvor leverandøren mener feilrettingen/endringen er. Eks. E1, O1. Dato for retting: Dato når feilrettingen/endringen er implementert i koden Versjon: Konfigurasjon: Beskrivelse av eventuell endring i systemteknisk konfigurasjon som installasjon av feilrettingen/endringen krever. Database: Beskrivelse av eventuelle databaseendringer som installasjon av feilrettingen/endringen krever. Testing foretatt: Beskrivelse av leverandørens egen systemtest. Verifisert Ok: Leverandøren erklærer at de har kvalitetssikret feilretting/endring før akseptansetesten gjennomføres. Releasenotes skal vedlegges i saken. 6.2 Forutsetning For å kunne samhandle i e-resept må virksomheten opprette kommunikasjonsavtaler med Reseptformidleren og andre tilhørende parter som virksomheten skal utveksle meldinger med. Se dokument grensesnittdokument for testrom 204. En leverandør vil ved bestilling av testgjennomføring avklare om han er ny eller eksisterende bruker av e-resept. Virksomhetseier er ansvarlig for at det gjennomføres systemtest i forkant av koordinert test fra 204. Ved oppgradering til nye e-resept meldingsversjoner eller endring av eksisterende meldingsversjon forutsettes det at virksomhetseier sørger for at det gjennomføres validering av e-resept meldinger gjennom KITH sin test og godkjenningsordning. Alle meldinger skal valideres av KITH for å sikre semantisk og syntaktisk riktighet for sending/mottak av meldinger. Godkjenningen gjennomføres etter etablert praksis med KITH som godkjenningsinstans. KITH vil også gi leverandørene støtte gjennom sin testserver som kan brukes i utviklingsfasen. Videre forutsettes det at virksomhetseier sørger for at det installeres og gjennomføres installasjonstest på gjeldende systemversjon på testrommet i Helsedirektoratet før den aktuelle testfasen påbegynnes. Side 17 av 20

6.3 Planlegging Tabellen under beskriver roller og ansvar knyttet til planlegging og gjennomføring av felles testaktiviteter. Roller Testansvarlig e- reseptforvaltning Testpersonell virksomhetseier Testleder virksomhetseier Utviklere virksomhetseier Oppgaver og ansvar Koordinerer testaktiviteter i e-resept. Har ansvar for planlegging og gjennomføring av testaktivitetene som inngår i de forskjellige tester som tilbys i regi av e-reseptforvaltning Er med på å utarbeide sjekklister, testcase og kjøreplaner i samarbeid med testansvarlig. Er ansvarlig for å gjennomføre testene i praksis og rapportere resultater. Ansvarlig for testarbeidet i den enkelte virksomhet. Ansvarlig for gjennomføring av systemtest og tilrettelegging for installasjonstest og akseptansetest Utfører prioritert retting av feil som avdekkes under testgjennomføringen. Er ansvarlig for å få lagt rettelsene i riktig miljø. Testarbeid knyttet til e-resept følges opp i e-reseptforvaltningens ordinære driftsmøter. Ved behov vil testansvarlig kalle inn til ytterligere møter for å sikre god gjennomføring av testen og for å sikre et best mulig resultat for helheten. 6.4 Gjennomføring Testperioden vil variere avhengig av omfang på leveransen og type test som planlegges gjennomført. For gjennomføring av akseptansetest av større leveranser vil det normalt planlegges med to testiterasjoner på en uke hver og en feilrettingsuke mellom hver iterasjon. Testgjennomføringen vil foregå koordinert fra testrommet i Helsedirektoratet. Side 18 av 20

6.5 Avslutning 6.5.1 Testrapport Etter testgjennomføring skrives vanligvis en testrapport der det viktigste innhold er: Hvilke system er testet mot hverandre? Når? Av hvem? Hvilke testtilfeller er kjørt og hvilken status er oppnådd (kjørt ok, feilet, ikke kjørt)? Hvilke feil er oppdaget og hva er status (alvorlighetsgrad, rettet / ikke rettet)? Anbefaling om produksjonssetting Testrapporten danner grunnlag for godkjenning og produksjonssetting. 6.5.2 Godkjenningskriterier Generelt gjelder følgende kriterier: Alle testcaser skal være testet i henhold til plan Resultatet av testen er dokumentert Ingen gjenstående feil med alvorlighetsgrad Kritisk Ingen gjenstående feil med alvorlighetsgrad Alvorlig Andre utestående feil skal være dokumentert Løsningen som ønskes produksjonssatt skal være av den kvalitet som ikke medfører risiko for de systemer som allerede inngår i e-resept 6.5.3 Avvik Avvik registreres i ERSA og behandles der. Følgende regelverk gjelder: Alle avvik som avdekkes under testgjennomføringen skal dokumenteres i ERSA med henvisning til skjermdumper, rapport, osv. Alle avvik skal forsøkes gjenskapt to ganger før registrering Avviket skal beskrives på en slik måte at det kan gjenskapes av utviklere/leverandør. Type avvik skal registreres. Alle avvik skal kategoriseres med alvorlighetsgrad. Kategoriseringen blir utført av den enkelte tester og blir gjennomgått i statusmøte. Dersom avviket medfører behov for endring skal det sendes endringsanmodning til endringsansvarlig. Endringsansvarlig ivaretar videre behandling av endringsanmodninger. Side 19 av 20

Behandlingsstatus skal registreres. 7 Vedlegg A.1 Sjekkliste etter test Ansvarlig testansvarlig Spørsmål Svar Frist Ansvarlig Er testrapport skrevet? Hvor mange testtilfeller er laget totalt? Hvor mange testtilfeller er kjørt med vellykket resultat? Hvor mange testtilfeller er kjørt med feilet resultat? Hvor mange testtilfeller er ikke kjørt? Hvor mange feil er oppdaget totalt? Hvor mange feil er rettet? Hvor mange kritiske feil gjenstår? Hvor mange alvorlige feil gjenstår? Hvor mange lite alvorlige feil gjenstår? Er det oppdaget feil som fører til endringer? A.2 Mal for testrapport A.3 Mal for releasenotes Side 20 av 20