KRAVDOKUMENT: API - RESPONSLØSNING OG EPJ

Transkript

1 KRAVDOKUMENT: API - RESPONSLØSNING OG EPJ Prosjektmodellens mal for Prosjektforslag, v

2 1. Bakgrunn og begrunnelse for prosjektet Prosjektets formål Omfang og avgrensninger Funksjonelle behov Brukerhistorier Overordnet funksjonell løsning Detaljerte funksjonelle krav Informasjonsmodeller Hente informasjon til støtte for brukerrettede tjenester Mottak av hendelser Ikke funksjonelle krav Programvare og lisenser Krav til støtte av lover og regler Personvern, informasjonssikkerhet og logging Standarder Infrastruktur, drift, vedlikehold og dokumentasjon Test Opplæring Krav til prosjektgjennomføring Leveranse og betalingsplan Vedlegg Prosjektmodellens mal for Prosjektforslag, v

3 1. BAKGRUNN OG BEGRUNNELSE FOR PROSJEKTET Helse- og omsorgsdepartementet har utarbeidet tildelingsbrev med de økonomiske rammer som gjelder for Direktoratet for e-helse i Tildelingsbrevet inneholder en nærmere beskrivelse av forhold av betydning for etaten, hovedmål og prioriteringer. Under hovedmål 3, spesielle oppdrag står det: «Påbegynne arbeidet med å realisere felles nasjonal plattform og infrastruktur på velferdsteknologiområdet. Plattformen skal legge til rette for raskere innføring og innovasjon ved å knytte løsninger fra ulike leverandører sammen og gjøre informasjonen tilgjengelig for aktørene i behandlingskjeden». Det er startet et felles arbeid sammen med prosjektet «Digitale innbyggertjenester til brukere av hjemmetjenesten» på helsenorge.no, med formålet å etablere felles grensesnitt mot de kommunale fagsystemene/epj. Dette prosjektet eies av Direktoratet for e-helse, og Oslo kommune er med som en av flere kommuner. Dette arbeidet er en viktig forutsetning for en plattform for velferdsteknologi der fungerende integrasjoner mot fagsystemene er helt avgjørende Prosjektets formål Målet med dette dokumentet er å beskrive funksjoner og foreslå retningslinjer for et API med toveis informasjonsutveksling mellom responsløsninger og de tre kommunale fagsystemene, CosDoc, Gerica og Profil levert fra henholdsvis ACOS, Tieto og Visma. Funksjonaliteten beskrevet i dette dokumentet bygger på krav og ønsker fra workshoper med kommunene og fagsystemleverandører. Følgende definisjoner ligger til grunn: Responsløsningen er en teknisk løsning som skal gi støtte for responstjenestens behov for å motta, vurdere, dokumentere og respondere på varslinger fra velferdsteknologiske løsninger. I dette inngår utveksling av informasjon med fagsystemer i helse- og omsorgssektoren. Fagsystem er et elektronisk informasjons-, dokumentasjons- og beslutningsstøttesystem for helse- og omsorgstjenestene som støtter sentrale arbeidsprosesser, som f.eks. saksbehandling, faglig dokumentasjon (journalsystem), arbeidsplanlegging, rapportering mv Omfang og avgrensninger Dette dokumentet beskriver de funksjonelle behovene for integrasjon. Datatekniske spesifikasjoner og integrasjonsspesifikke detaljer omfattes ikke av dette dokumentet. Prosjektmodellens mal for Prosjektforslag, v

4 Vedlagt ligger 1) Informasjonsmodell/variabelliste 2) Tilgjengeliggjøring av opplysninger fra behandlingsrettede helseregistre 3) Informasjonssikkerhetskrav 4) AMQP spesifikasjon helsenorge.no 2. FUNKSJONELLE BEHOV 2.1. Brukerhistorier Kravdokumentet har blitt utformet i brukerhistorier. Riktig og relevant tilgang til informasjon er nødvendig for at hvert ledd i tjenestekjeden skal kunne utføre sine oppgaver best mulig. De påfølgende brukerhistoriene beskriver overordnet funksjonalitet som er en del av utviklingsprosjektet Brukerhistorie 1 Automatisk journalføring ved manuell dokumentasjon av respons på hendelse. Som responstjenestemedarbeider ønsker jeg at min dokumentasjon av hvordan alarm / avvik er løst kan formidles automatisk fra responsløsningen og journalføres i EPJ, slik at jeg slipper dobbeltarbeidet det medfører å dokumentere i to systemer Brukerhistorie 2 Formidle informasjon til hjemmetjenesten. Som responstjenestemedarbeider ønsker jeg å kunne gi beskjed til hjemmetjenesten om behov for oppfølging eller andre forhold de bør være oppmerksomme på ved neste besøk, slik at de er oppdatert på hva som er skjedd og kan følge opp dette samt at hjemmetjenesten i en del tilfeller kan følge opp og løse mindre akutte situasjoner så responstjenesten slipper å rykke ut Brukerhistorie 3 Opprette oppdrag i fagsystem (EPJ). Som responstjenestemedarbeider ønsker jeg å kunne opprette utrykningsoppdrag som skal utføres av hjemmetjenesten, ved å overføre «bestilling» av oppdrag fra responsløsningen til deres fagsystem/epj, slik at hjemmetjenesten kan benytte sitt eget fagsystem for planlegging, støtte til utførelse og dokumentasjon av utrykningsoppdrag samt at jeg slipper å måtte gå inn i dette systemet for å opprette oppdrag Brukerhistorie 4 Hente ut tjenesteinformasjon fra fagsystem (EPJ) som støtte til vurdering av handlingsalternativer. Som responstjenestemedarbeider ønsker jeg at informasjon fra fagsystem/epj om brukers helsetjenester, besøksplan, aktuelle kontaktpersoner etc. kan vises i/fra min responsløsning, slik at jeg ikke må sjekke ulike systemer for å skaffe meg oversikt over tjenester og aktører som grunnlag for å vurdere handlingsalternativer for den aktuelle situasjonen jeg skal respondere på. Prosjektmodellens mal for Prosjektforslag, v

5 Brukerhistorie 5 Hente ut brukerinformasjon fra EPJ som støtte til vurdering av situasjon. Som responstjenestemedarbeider ønsker jeg at informasjon fra EPJ om brukers helsesituasjon kan vises i/fra min responsløsning, slik at jeg får et bedre helhetsbilde av brukeren som grunnlag for å vurdere den aktuelle situasjonen jeg skal respondere på, samt at jeg slipper å måtte sjekke i annet system for å skaffe meg denne type tilleggsinformasjon Overordnet funksjonell løsning I samarbeid med representanter fra helse- og omsorgstjenesten i flere kommuner er det kartlagt et minimum sett av informasjon som må utveksles mellom responssenterløsningen og kommunalt fagsystem/epj. Prosjektmodellens mal for Prosjektforslag, v

6 2.3. Detaljerte funksjonelle krav Kravbeskrivelse Brukerhistorie Hendelser som lagres i EPJ skal begrenses til kun de alarmene det aksjoneres på Dokumentering av hendelser skal inneholde; HendelseID Tid Lokasjon Beskrivelse hendelse/avvik Data fra utstyr hos tjenestemottaker Besluttet videre aksjon O Brukerhistorie Beskjeder fra responssentertjenesten O Informasjon om mulig behov for endring Andre beskjeder knyttet til tjenestemottaker Utførende tjeneste må få varsel om inntrufne hendelser som er viktig O å kjenne til før neste planlagte besøk Krav for brukerhistorie 1 er også gjeldende O Brukerhistorie Hendelsesinformasjon skal kunne videreformidles til utførende O tjeneste ved behov for aksjon Utførende tjeneste må få opp et tydelig varsel om hendelsen i de O tilfeller utførende tjeneste må ta aksjon Krav for brukerhistorie 1 er også gjeldende O Brukerhistorie Oppdatert informasjon om tjenestemottaker skal inneholde; O Personalia o Fødselsnummer o Navn o Adresse o Kontaktinformasjon o Pårørende m/kontaktinformasjon Brukerinformasjon (ikke medisinske) o Funksjonsnivå IPLOS/ADL o Besluttede vedtak og tiltak Daglig besøksplan Brukerhistorie Helseopplysninger (medisinske) o Diagnoser o Kritisk info o Cave o Obs o Medisinliste O Type O Merknad [A1]: Dette er det tjenesten selv som vurderer. Grensesnittet må ha mulighet til å merke info som skal lagres i EPJ Prosjektmodellens mal for Prosjektforslag, v

7 3. INFORMASJONSMODELLER 3.1. Hente informasjon til støtte for brukerrettede tjenester Resultat av forespørsel begrenset innsyn (uten medisinske opplysninger): Resultat av forespørsel fullt innsyn (med medisinske opplysninger): Resultat av forespørsel fullt innsyn, med flere relasjoner: Prosjektmodellens mal for Prosjektforslag, v

8 3.2. Mottak av hendelser Input til fagsystem/epj: Hendelse fra velferdsteknologisk tjeneste: Mottak og behandling av hendelse fra velferdsteknologisk tjeneste i fagsystem/epj: Prosjektmodellens mal for Prosjektforslag, v

9 4. IKKE FUNKSJONELLE KRAV 4.1. Programvare og lisenser Nr. Kravbeskrivelse Type Programvare som benyttes i leveransen listes opp med navn og O programvarelisenser som er nødvendig i produksjonsmiljø. Spesifiser også bruk av tredjeparts verktøy og/eller tredjeparts leverandører hvis tilbudt løsning forutsetter bruk av dette Spesifiser eventuelle lisenser som er nødvendig ved etablering av andre ikke produksjonsrettede miljøer eksempelvis test, utvikling og opplæring Eventuell fri programvare som benyttes i leveransen listes opp med O navn og programvarelisens Beskriv eventuelt andre deler av leveransen som vil bli omfattet av O vilkårene i en fri programvarelisens Leverandøren skal beskrive sine vurderinger av den frie programvaren som eventuelt benyttes i forhold til leverandørens ansvar for rettsmangler ved fri programvare. O 4.2. Krav til støtte av lover og regler Merknad [A2]: Hvilken leveranse snakker vi om her? Merknad [A3]: Hva er sammenhengen mellom dette og API spesifikasjonene? Nr. Kravbeskrivelse Type Krav til støtte av lover og regler Etterlevelse av Norm for informasjonssikkerhet v5.2 og Veileder tilgang mellom virksomheter v Løsningen skal tilfredsstille kravene i Personopplysningsloven om håndtering av personsensitive opplysninger «Krav til etablert «Normen avtale for RS» for å kunne integrere mot EPJ» Etterlevelse av Veileder i informasjonssikkerhet ved bruk av velferdsteknologi v2.0 Prosjektmodellens mal for Prosjektforslag, v

10 formasjonssikkerhet%20- %20velferdsteknologi/Veileder%20ved%20bruk%20av%20velferdstek nologi%20ver%202.0.pdf Etterlevelse av Veileder i Tilgangsstyring v lgangsstyring/veileder%20tilgangsstyring%20v1.0.pdf 4.3. Personvern, informasjonssikkerhet og logging Dette kapittelet skal dekke krav til løsningen rundt personvern, informasjonssikkerhet og logging. Det er ikke tatt stilling til hvilken type teknologi som grensesnittene i løsningen skal realiseres med. Følgende behov må ivaretas ved valg av teknologi: 1. Der hvor brukeren forventer å motta informasjon i sanntid, heretter kalt API-basert kommunikasjon. Eksempler på teknologi som kan anvendes: a. RESTFul API b. SOAP-basert API c. AMQP og bruk av NHN sin AMQP infrastruktur 2. Der hvor brukeren, eller gjennom brukerens handlinger, skal utlevere informasjon til annen eksternt system, heretter kalt meldingsbasert kommunikasjon. Eksempler på teknologi som kan anvendes: a. ebxml/ebms over SMTP og bruk av NHN sitt SMTP infrastruktur b. AMQP og bruk av NHN sin AMQP infrastruktur c. Eventuelt også API-basert kommunikasjon kan benyttes, men utleveringen bør ikke hindre brukeren fra å fortsette med arbeidet sitt. Kravene i dette kapittelet er basert på at virksomhetene som utveksler helse- og personopplysninger er utveksling mellom en databehandler som behandler helse- og personopplysninger på vegne av den databehandlingsansvarlige (Responsløsning) og den databehandlingsansvarlige (kommunal EPJ). På bakgrunn av at databehandleren av Responsløsningen må forholde seg til mange kommuner (databehandleransvarlige) er det et viktig prinsipp at Responsløsningen må være ansvarlig for autentisering og autorisering av sine brukere når de utfører handlinger som medfører utveksling av informasjon med kommunale EPJ-er. Det må da etableres et tillitsforhold mellom databehandler og databehandleransvarlige. Eventuelt kan autentisering og autoriseringen delegeres til en ekstern tjeneste hvor da både databehandler og databehandleransvarlig må etablere tillit til den sentral tjenesten og dermed implisitt seg i mellom. Merknad [A4]: Har dette noen klar kobling til tittelen i kapittelet? Dette bør komme i et eget kapittel med en viss grad av mapping mellom informasjonsmodellene og foretrukket teknologi (sanntid vs melding) Merknad [A5]: I noen tilfeller, kanskje bedre å bruke bør kunne forholde seg til. Prosjektmodellens mal for Prosjektforslag, v

11 Nr. Kravbeskrivelse Type Autentisering og autorisering (Responsløsning) Løsningen skal kunne integreres med en ekstern autentiserings- og autorisasjonsmekanisme med støtte for sikkerhetsnivå 4 autentisering for å styre tilganger for brukere. Eksempel på ekstern autentisering er FIA STS og ID-porten Leverandøren bes å beskrive hvordan dette kan løses Alle forespørsler til EPJ-løsningen skal signeres med virksomhetssertifikat slik at EPJ-løsningen kan oppfylle kravnr Eksempel ved bruk av RESTFul API: RFC7523 og Alle forespørsler til EPJ-løsningen skal også ha støtte for å overbringe identiteten av helsepersonell som får tilgang til opplysningene, for lokal logging i det utleverende systemet (Ref Veileder tilgang mellom virksomheter v1.1 : Hendelsesregister) og håndheving av eventuelle sperringer/reservasjoner som pasient har Responsløsningen skal kunne støtte at detaljert autorisasjon håndteres iht. Normen Veileder tilgang mellom virksomheter v Autorisering skal skje selvstendig for hver enkelt bruker/rolle. Autentisering må sikre identifisering i korrekt rolle i hvert enkelt tilfelle. Autoriseringsbeslutningen gjøres generelt i responsløsningen, ikke i utleverende EPJ, med unntak av tilfeller der pasienten har reservert seg mot utlevering eller har hemmelig adresse Medisinske og personlige opplysninger skal kun være tilgjengelig for helsepersonell med tjenstlig behov. Leverandøren bes å beskrive hvordan dette kan løses Bruker skal bare kunne benytte de funksjoner og den informasjon som vedkommende er autorisert for Responsløsningen skal loggføre hvem som har lest og oppdatert helseinformasjon (se detaljerte krav under «loggføring») Ref forskrift om tilgang til helseopplysninger mellom virksomheter 10 skal dette automatisk dokumenteres i et hendelsesregister Det skal være mulig å registrere følgende metadata for bruker: brukerens nåværende, fulle navn initialer (bruker-id) HPR-nummer, «unik-id» for personer som ikke har HPR-Id (ansattnummer, fødselsnummer, ) HER-ID som angir virksomheten som brukeren er ansatt i dato for når bruker ble opprettet dato for når bruker utgår alle tidligere navn alle tidligere initialer Merknad [A6]: Formulering hører kanskje mer hjemme i en anskaffelsesspesifikasjon? Merknad [A7]: Igjen anskaffelsesformulering Merknad [A8]: Registrere hvor? Prosjektmodellens mal for Prosjektforslag, v

12 Det skal finnes en oversikt over hvilket eller hvilke tidsrom hver bruker har vært aktiv. Autentisering og autorisering (EPJ) EPJ-løsningen skal kunne akseptere eksterne brukere som er autentisert på sikkerhetsnivå 4 av eksterne identitetstilbydere som kommunen har etablert tillit til, ref kravnr Eksempel på ekstern autentisering er FIA STS og ID-porten Leverandøren bes å beskrive hvordan dette kan løses Tilgang til grensesnittet og opplysninger som gis over grensesnittet skal kunne begrenses til de virksomhetene som kommunen har avtale med å utveksle informasjon med. Virksomheter skal kunne autentiseres ved hjelp av virksomhetssertifikater og signerte forespørsler EPJ-løsningen skal kunne støtte at detaljert autorisasjon håndteres i kallende system (responsløsning) iht. Normen Veileder tilgang mellom virksomheter v1.1. EPJ-løsningen skal støtte både lese og skrive tilgang I EPJ opprettes én generell rolle «helsepersonell-responssenter». EPJ skal motta detaljert informasjon fra kallende system som loggføres i EPJ ved utlevering av informasjon (se detaljerte krav under «loggføring» For internkontrollformål skal EPJ-løsningen loggføre bruk av API. Kravbeskrivelse Informasjonssikkerhet Meldingsbasert kommunikasjon Ved bruk av ebxml over SMTP skal standarden HIS 1037:2011 følges. ( Ved bruk av AMQP og NHN sitt AMQP infrastruktur skal prinsippene beskrevet i følges. Se vedlegg Ved bruk av NHN sin infrastruktur for meldingsbasert kommunikasjon må løsningen være tilgjengelig på Norsk Helsenett. Loggføring og innsyn (gjelder både Responsløsning og EPJ-løsning hvis ikke annet er opplyst) Bruk av API-kommunikasjon mellom Responsløsning og EPJ-løsning skal hendelser registreres automatisk i begge løsningene. (Ref Normen Veileder tilgang mellom virksomheter v1.1. kap 2.8) Det skal være prosesser og mekanismer i Responsløsningen for å overvåke tilgang til helsepersonell for å sikre at enkelte brukere ikke misbruker tilgangen, som beskrevet i forskrift om tilgang til helseopplysninger mellom virksomheter og Normen Veileder tilgang mellom virksomheter v1.1. Prosjektmodellens mal for Prosjektforslag, v Type Type Type Merknad [A9]:

13 Leverandøren bes å beskrive hvordan dette kan gjennomføres. Merknad [A10]: Gjennom konfigurasjon skal man kunne styre detaljeringsgrad for logging Tilgang til å lese og ta ut logger skal kunne styres gjennom definering av roller Forskrift om tilgang til helseopplysninger mellom virksomheter sier at pasienter har rett til innsyn i og få utskrift av hendelsesregistrert informasjon. Det skal være enkelt å ta ut logger ift. angitte parametre som fra/til dato, felter i loggført informasjon, etc Følgende informasjon skal loggføres i Responsløsning Hvilken virksomhet/system som blir oppkalt (HERID, «System- ID for EPJ») Hvem som henter ut eller oppdaterer informasjon (HPRnummer, bruker-id). (Alternativt hvilket system/velferdsteknologiske løsning som oppdaterer informasjon) Hvilken informasjon som hentes ut/oppdateres (pasient-id, type informasjon) Evt. ytterligere informasjon (token-id, session-id, lokasjon, nettverk, autentiseringsmetode, årsak til informasjonsbehov, ikke suksessfulle kall, Access denied, ) Følgende informasjon skal loggføres i EPJ Kallende virksomhet/system (HERID, «System-ID for Responssenter løsning») Hvem som henter ut eller oppdaterer informasjon (HPRnummer, bruker-id). (Alternativt hvilket system/velferdsteknologiske løsning som oppdaterer informasjon) Hvilken informasjon som hentes ut/oppdateres (pasient, type informasjon) Evt. ytterligere informasjon (token-id, session-id, lokasjon, nettverk, autentiseringsmetode, årsak til informasjonsbehov, ikke suksessfulle kall, Access denied, ) Det er ønskelig at loggene enkelt skal kunne analyseres med henblikk på bl.a å oppdage urettmessige tilegnelse av taushetsbelagt informasjon. Leverandør bes å beskrive hvordan dette kan løses Sikring av datatrafikk Kommunikasjonen mellom virksomhetenes nettverksoner hvor helseopplysninger behandles skal være kryptert iht Kravspesifikasjon for PKI i offentlig sektor» Løsningen skal støtte innholdskryptering samt signering med Prosjektmodellens mal for Prosjektforslag, v Type Merknad [A11]: Fra hvor? Merknad [A12]:

14 virksomhetssertifikat for meldingsbasert kommunikasjon (ebxml over SMTP og AMQP). Cryptographic Message Synxtax (CMS) skal benyttes ved kryptering og signering All HTTP-basert kommunikasjon skal transportkrypteres med minimum TLS 1.2. Det bør benyttes toveis TLS, dvs både TLS klient- og tjenersertifikat. Løsningen skal også verifisere at ikke mellomtjenere uten databehandlingsavtale dekrypterer trafikken, for eksempel ved sjekk av TLS klient- og tjenersertifikat Det skal finnes en dokumentert og utprøvd løsning for midlertidig sperring av tilgang til APIer i tilfelle katastrofe 4.4. Standarder Nr. Kravbeskrivelse Type Protokoller og format Løsningen skal kunne benytte TCP/IP som informasjonsbærer Løsningen skal kunne ta imot og behandle data fra ulike type formater-json, XML etc. Merknad [A13]: Hva er løsningen her? 4.5. Infrastruktur, drift, vedlikehold og dokumentasjon Nr. Kravbeskrivelse Type Driftsdokumentasjon Leverandør skal beskrive tilbudt løsning for service, brukerstøtte og vedlikehold Det skal foreligge nødvendig dokumentasjon for å drifte systemet. Det skal leveres en teknisk driftsdokumentasjon (engelsk eller norsk) som beskriver vanlige feilkilder/feilmeldinger og standard driftsrutiner for applikasjonene samt daglige preventive vedlikeholdsrutiner Det skal foreligge nødvendig installasjonsdokumentasjon (norsk eller engelsk). Det skal leveres en installasjonsveiledning med figurer, og dokumentasjon av versjoner og avhengigheter til underliggende operativsystemer/api-er Installasjonsdokumentasjon skal som et minimum inneholde: Systemets/komponentenes formål, bruksområde og ansvarlige ressursbehov driftsrettet beskrivelse av systemets oppbygging driftsrutiner, herunder sikkerhetskopiering oversikt over rapporter og distribusjon av disse rutiner for å sikre systemets tilgjengelighet og ytelse Prosjektmodellens mal for Prosjektforslag, v Merknad [A14]: Hører dette hjemme her?

15 rutiner for oppfølging av driftsvedlikehold av IT-systemer rutiner for forvaltning av systemet definisjon av begreper retningslinjer vedrørende sikkerhet instrukser vedrørende feil og avvikssituasjoner Leverandøren skal oppdatere driftsdokumentasjon ved hver ny hovedversjon All driftsdokumentasjon skal tilgjengeliggjøres elektronisk i Wordog/eller PowerPoint-format for Kunde med mulighet til å redigere/editere på dokumentasjonen. Infrastruktur Leverandøren skal beskrive preferert driftsplattform for løsningen Løsningen må kunne kjøres på en virtuell server infrastruktur («som skytjeneste»). I de tilfeller der sertifisering og/eller lisensiering av produkter som inngår i løsningen hindrer en kostnadseffektiv utnyttelse av en virtuell infrastruktur skal dette gjøres rede for Leverandøren skal beskrive hvordan høytilgjengelighet kan understøttes. Beskriv og skisser anbefalt design inkludert prefererte komponenter Leverandøren skal kunne bidra med kompetanse for design og etablering av relevant test- og produksjonsmiljø Leverandøren skal kunne dokumentere rutiner i forbindelse med konfigurasjonsstyring og versjonskontroll. De samme kravene stilles til endring/avvikshåndtering Det skal finnes en dokumentert og utprøvd løsning for midlertidig sperring av tilgang til APIer i tilfelle katastrofe (vurder om dette kravet bør settes til driftsleverandør) Ytelse Løsningen sin responstid og ytelse skal av brukeren oppleves som god. Operasjoner som utføres ofte skal gå fort og være uten forsinkelser. Det skal ved normale operasjoner ikke oppleves ventetid på over x sekunder. Beskriv eventuelle utfordringer. Dokumenter eventuelle operasjoner hvor kravet ikke vil kunne oppfylles Det må gjøres rede for i hvilken grad det kan oppstå begrensninger i bruk av løsningen når det gjelder maksimalt antall innloggede eller samtidige brukere, i programvaren, mot databaseløsningen eller på annen måte. Flere områder Leverandøren skal eksplisitt informere Kunden når bistand ikke inngår i brukerstøtte som del av fast årlig vedlikeholdsavgift og Kunden vil bli fakturert etter medgått tid Test Prosjektmodellens mal for Prosjektforslag, v

16 Nr. Kravbeskrivelse Type Test Leverandøren skal beskrive sitt planlagte testopplegg Leverandørens systemtest skal omfatte volum-, kapasitets-, og svartidstester Leverandør skal ha en ansvarlig som mot Kunden skal: Påse at leverandørens leveranser er i henhold til krav. Overordnet ansvar for at alle tester som skal utføres fra leverandørens side blir utført og dokumentert i henhold til krav. Vurdere innrapporterte feil i samarbeid med utvikler, tester og testansvarlig. Påse at rapporterte feil blir rettet og levert så snart som mulig. Ha løpende dialog med Kunden sin testleder i forbindelse med oppfølging av avviksrapportering Opplæring Nr. Kravbeskrivelse Type Opplæring Leverandøren skal tilby opplæringsmateriell og opplæring tilpasset følgende målgrupper: Drifts- og systemansvarlig Administrator Brukerstøtte (hvis relevant) Personell i responssenter / pleiepersonale (hvis relevant) Dette gjelder for: Nye brukere Nye versjoner/funksjoner Behov for oppfriskningskurs Leverandøren skal gi en oversikt over hvordan opplæring anbefales gjennomført for de ulike målgruppene og for nye brukere/versjoner/funksjoner, samt der det er behov for oppfriskningskurs Leverandøren skal oppdatere opplæringsmateriale ved hver ny hovedversjon All opplæringsdokumentasjon skal tilgjengeliggjøres elektronisk i Word-og/eller PowerPoint-format for Kunde med mulighet til å redigere/editere på dokumentasjonen Kunden forbeholder seg retten til selv å gjennomføre opplæring av sine brukere og å innhente annen ekstern undervisningskompetanse. Kopiering og gjenbruk av kursdokumentasjon skal være vederlagsfritt Prosjektmodellens mal for Prosjektforslag, v

17 5. KRAV TIL PROSJEKTGJENNOMFØRING Leverandør skal utarbeide en prosjektplan, presentere en prosjektorganisasjon og gi en kort beskrivelse av aktiviteter før signering av kontrakt. Prosjektplan med aktiviteter skal som minimum fylle følgende krav: Milepæl Milepælbeskrivelse Leveransenummer Dokumentasjon M1 Oppstart M2/M3 Estimater/planer/design godkjent 6 7 Leverandør skal lage en prosjektplan med oppstart senest M-1 Leverandør lager forslag til milepælsplan for milepæler M-1 til og med M-8. I forbindelse med oppstart skal det gjennomføres en kontrakt-gjennomgang og kravsporing Leverandøren skal utpeke sitt pilotlegekontor i samarbeid med Kunden. Leverandøren skal beskrive kundens involvering og ressursbehov til de forskjellige aktivitetene i prosjektplanen. Før godkjent design skal det legges inn aktiviteter for prototyping Designdokumentet som godkjennes skal inkludere akseptansekriterier. Det er EPJ leverandørens brukerrepresentanter, utpekt av EPJ-løftet, som godkjenner. 8 Leverandøren skaffer til veie testdata M4 Utvikling ferdigstilt 9 Mellom milepælene M-3 og M-4 skal leverandøren gi ukentlige statusrapporter på fremdrift og gjenstående aktivitet. 10 I forbindelse med milepæl M-4 skal leverandør presentere løsning og testrapporter som gir pilotkunde trygghet for igangsettelse av pilot. M5 Opplæring gitt, pilotinstal. ferdigstilt 11 Leverandøren skal i samarbeid med Kundens representanter utarbeide en plan med aktiviteter som sikrer: 1) Full utbredelse av løsningen 2) og at den enkelte virksomhet oppnår forventet effekt av løsningen M6 Prøvedrift-pilot gjennomført 12 Statusrapport pilot M7 Akseptansetest godkjent 13 Signert dokument med godkjente akseptansekriterier M8 Release, implementert hos brukerne 14 Leverandør skal informere brukerne om løsningen i releasenotater 15 Leverandør skal dokumentere løsningen i sin produktdokumentasjon 16 Leverandøren skal inkludere løsningen i sine forvaltning drift og vedlikeholdsrutiner Prosjektmodellens mal for Prosjektforslag, v

18 6. LEVERANSE OG BETALINGSPLAN Milepæler Dato Leverandørens forslag Betalingsplan M0 Kontrakt signert M1 Oppstart 30 % M2/M3 Estimater/planer/design godkjent M4 Utvikling ferdigstilt 40 % M5 Opplæring gitt, pilotinstal. ferdigstilt M6 Prøvedrift-pilot gjennomført M7 Akseptansetest godkjent M8 Release, implementert hos brukerne 30 % dg= kalenderdager 7. VEDLEGG Vedlegg 1: Informasjonsmodell/variabelliste Vedlegg 2: Tilgjengeliggjøring av opplysninger fra behandlingsrettede helseregistre Vedlegg 3: Informasjonssikkerhetskrav Vedlegg 4: AMQP spesifikasjon helsenorge.no Prosjektmodellens mal for Prosjektforslag, v