INNLEDNING 3

Fagsystem for Tolketjenesten Trondheim kommune

SSA-L Bilag 1 Kundens behovsspesifikasjon

Funksjonelle og tekniske krav

INNLEDNING 3

Formålet med dokumentet 3

Avtale 3

Besvarelse 3

KUNDENS FORMÅL MED AVTALEN 4

Definisjoner 4

FUNKSJONELLE KRAV 6

Overordnede / Generelle krav 6

Krav i forbindelse med konfigurering av løsning 10

Språk 10

Fagområder 10

Klassifikasjon av utdanning 10

Utlysningsmetoder 10

Satsregister 11

Kunder 11

Tolk/Oversetter 11

Oppdragstyper 12

Saksbehandlingsstatuser 14

Funksjonelle krav i forbindelse med hovedprosess - Formidling 15

Krav i forbindelse med bestilling av oppdrag 15

Krav i forbindelse med aksept av oppdrag 18

Krav i forbindelse med gjennomføring av oppdraget 18

Krav forbindelse med rapportering i ettertid av oppdraget 18

Krav i forbindelse med endring av oppdrag 19

Krav i forbindelse med avbestilling av oppdrag 19

Funksjonelle krav i forbindelse med støtteprosesser 20

Fakturere kunder 20

Lønne tolker 20

Oppdatere tilgjengelighet for tolk 21

Uttak av lønn/fakturagrunnlag for tolk/oversetter 21

Andre funksjonelle krav knyttet til brukertyper 22

Bestillere 22

Tolk/Oversetter 22

Interne brukere (Tolkeformidlere, Lønnsmedarbeidere, Admin) 22

Integrasjoner, samhandling mot andre systemer og api-er 23

IKKE-FUNKSJONELLE KRAV OG TEKNISKE KRAV 25

Brukerstøtte, opplæring og dokumentasjon 25

Informasjonssikkerhet og personvern 25

Prosjekt- , fremdriftsplan og administrative bestemmelser 30

Testing og godkjenning 30

Drift, vedlikehold og ytelse 31

Brukskvalitet 32

1 INNLEDNING

1.1 Formålet med dokumentet

Dette dokumentet er Kundens behovsspesifikasjon og fremstiller de krav og forventninger Trondheim kommune har til nytt fagsystem for tolketjenesten.

1.2 Avtale

Dette dokumentet vil sammen Statens standardavtale for skytjenester (SSA-SKY) og avtalens øvrige bilag danne avtalen mellom Kunde og Leverandør.

1.3 Besvarelse

Besvarelse gjennomføres etter beskrivelse og krav i filen Vedlegg 1 til Bilag 1 - Krav til Leverandørens besvarelse av Kundens behovsspesifikasjon

2 KUNDENS FORMÅL MED AVTALEN

Kundens formål med avtalen er å erstatte dagens utdaterte system for formidling av tolke- og oversettelsesoppdrag med et nytt og moderne IT-system.

3 Definisjoner

Begrep	Definisjon
Single-Sign-On (SSO)	SSO allows a single authentication credential to access different systems within a single organization.
Federated Identity	Federated identity management system provides single access to multiple systems across different enterprises.
Utlysningsmetode	Beskriver hvordan systemet og Tolketjenesten skal gå fram for kontakte tolk eller oversetter i forbindelse med et nytt oppdrag.
Klienter	Personer som det skal tolkes for. F.eks. en pasient på legevakt, eller foreldre på et foreldremøte.
Tolking	Direkte oversettelse av tale fra et språk til et annet
Oversettelse	Skriftlig oversettelse fra et språk til et annet
Formidling	Finne og tildele riktig tolk eller oversetter til bestilt oppdrag
LIFT	Trondheim Kommunes økonomi-løsning basert på Agresso
Agresso	En av to store aktører innenfor regnskapssystemer i Kommune-Norge. Har litt under halvparten av alle kommunene i Norge. Er brukt av de største kommunene sånn at de har over halvparten av brukerne.
Bluegarden	Trondheim Kommunes HR-løsning levert av Visma
Visma	Norsk konglomerat av ulike forvaltningsløsninger til kommunal, statlig og privat sektor i Norge og flere andre ulike land i Europa.
Intrawin	Dagens løsning for tolkeformidling.
IMDI	Integrerings- og mangfoldsdirektoratet
TQM	Trondheim Kommunes kvalitetssystem

IT-Brukertjenesten	Førstelinjesupport for alt av IT-tjenester i Trondheim Kommune. Det legges opp til at henvendelser til Leverandør kommer via denne enheten i Trondheim Kommune
ServiceNOW	Trondheim Kommunes oppfølgingsverktøy for support henvendelser. ServiceNow er et amerikansk programvareselskap som utvikler en cloud computing-plattform for å hjelpe selskaper med å håndtere digitale arbeidsflyter for drift.
Kunde	Enhet eller eksternt selskap som har minimum en bestiller, men kan også har flere bestillere. Dette kan f.eks. være en skole eller et privat legesenter som har behov for tolk/oversetter.
Bestiller	Brukertype i systemet. En bestiller kan bestille oppdrag på vegne av en kunde og klienter.

4 FUNKSJONELLE KRAV

4.1 Overordnede / Generelle krav

Krav Nr.	Beskrivelse av krav	Krav- kode	Svarkode Leverandør skal svare J/N/T om kravet oppfylles	Har Leverandør forbehold til kravet (Beskrives i Vedlegg Forbehold)	Leverandør skal beskrive sin oppfyllelse av kravet i	Type priselement
		(M, A, B)	(J/N/T)	(J/N)	Xxxxx	S/B
1	Overordnet krav
1.1	Systemet skal bidra til effektiv formidling av tolk- og oversettelsesoppdrag	A			Bilag 2
1.2	Systemet skal bidra til stor grad av automatisering av formidling av oppdrag	A			Bilag 2
2	Krav om brukervennlighet
2.1	All informasjon som er mulig å fylle ut automatisk skal fylles ut automatisk.	M
2.2	Autoutfylling kan overskrives av brukere	M
2.3	Systemet skal ha et responsivt design som fungerer på telefon, nettbrett og pc/mac (plattformuavhengig)	M
2.4	Systemet må støtte mange brukere samtidig og ha funksjoner på plass for å unngå feilsituasjoner som overlagring etc.	M			Bilag 2
2.5	Alle sider skal være uten store kodefeil.	M
2.6	Det vektes positivt at fagsystemet er utformet slik at brukerens arbeidsoppgaver kan utføres på en brukervennlig måte, inkludert på mobile løsninger.	A			Bilag 2
3	Krav i forhold til automatisering
3.1	Systemet skal støtte følgende utlysningsmetoder: 1. Automatisk booking av øverste tolk(er) basert på om de er satt som ledig og ut fra en prioriteringsliste. 2. Sekvensiell forespørsel mot tolker basert på en prioriteringsliste 3. “Førstemann-til-mølla”-prinsipp 4. Visning av alle aktuelle tolker, slik at ønsket tolk kan velges. (Dette gjelder kun for interne brukere)	M
3.2	Det bør være mulig å sette opp en algoritme for prioritering av tolk for å kunne automatisk tildele oppdrag. F.eks. for et tolkeoppdrag. 1. Språk (tolken må kunne språket) 2. Tolk må oppfylle kvalifikasjonskrav definert i oppdraget 3. Kjønn (om spesifisert i oppdraget)	A			Bilag 2

	4. Kundens reservasjon mot enkelt tolker 5. Reisetid (når relevant) 6. Tolk reservasjon mot tolkeform i oppdraget 7. Pre-prioritert liste for hvert enkelt språk
3.3	Systemet bør kunne ta høyde for brukt tid mellom hvert oppdrag for å unngå at en tolk blir booket så tett at de ikke klarer å gjøre seg klar / forflytte seg til neste oppdrag. Det må f.eks. kunne være 15 min mellom hvert skjermtolkningsoppdrag, mens minimum 30 minutte mellom hvert oppmøteoppdrag. Disse parameterne bør kunne parameterstyres	A			Bilag 2
3.4	Systemet bør kunne beregne tidsbruk mellom oppmøteoppdrag basert på oppmøteadresser og avstand	A			Bilag 2
3.5	Det bør være mulig å sette opp hvilke tolkeformer som er mulig å automatisk booke. F.eks. bør det være mulig å si at frammøteoppdrag skal kunne gå via manuell behandling.	A			Bilag 2
3.6	Det bør være mulig å overstyre hvilke tolkeformer som er mulig å booket automatisk pr kunde.	A			Bilag 2
4	Krav om brukertyper og roller
4.1	Løsningen skal støtte minst fire ulike brukertyper med tilhørende spesialtilpassede grensesnitt som standard. De fire ulike brukertypene er: - Tolk/Oversetter - Kunder - Interne brukere - Fagsystemasnvarlig/administratorer	M
4.2	Informasjon og grensesnittene som er tilgjengelig for de fire brukertypene bør kunne tilpasses av administrator.	A			Bilag 2
4.3	Det bør være mulig å opprette flere ulike roller innenfor de ulike brukertypene. F.eks. Formidler, Økonomiansvarlig, intern tolk, ekstern tolk etc. med mulighet for å konfigurerer hvilket innhold disse har tilgang til.	A			Bilag 2
5	Krav om generering av underlag for andre systemer og integrasjon
5.1	Systemet skal kunne generere riktig fakturagrunnlag for kunder og overføre dette til andre systemer for effektuering.	M
5.2	Systemet skal kunne generere riktig lønnsgrunnlag for eksterne tolker og sørge for at det kan bli overført til andre systemer for effektuering.	M
5.3	Systemet bør kunne integrere med Bluegarden for utveksling av lønnsgrunnlag og reiseregninger med vedlegg automatisk etter fullførte oppdrag.	A			Bilag 2
6	Krav om registrering av nye tolker og kunder
6.1	Systemet skal gi eksterne tolker og bestillere mulighet for å registrere seg med nødvendig informasjon. Informasjon skal komme rett inn i systemet. Systemet skal gi brukere med riktig tilgang en enkel oversikt for å redigere og/eller, godkjenne eller avvise forespørselen før de kan bruke systemet	M

6.2	Systemet skal støtte flere bestillere for hver kunde.	M
6.3	Det ønskes å få brukere opprettet automatisk basert på på innloggingsløsning. Ansatte i Trondheim Kommune, som ikke er ansatt hos Tolketjenesten, skal automatisk registreres som bestiller under sin enhet. Finnes ikke enheten som kunde skal den opprettes automatisk med informasjon fra Innloggingsløsning. For eksterne er det ønskelig at mest mulig informasjon fra innloggingsløsning kan brukes i registreringen.	A			Bilag 2
6.4	Mulighet for interne brukere å registrere nye tolker/kunder/bestiller	M
7	Krav om søk
7.1	Systemet skal ha et globalt søk som søker i all relevant informasjon en bruker har tilgang til	M
8	Krav om rapportering
8.1	Systemet skal ha forhåndsdefinerte rapporter.	M
8.2	Systemet skal ha rapporter som inkluderer alle felt.	M
8.3	System bør ha mulighet til å bygge opp rapporter dynamisk i forhold til den informasjon en bruker har tilgang til.	A			Bilag 2
8.4	Systemet bør ha mulighet for å sammenligne en valgfri periode med en annen valgfri periode for alle rapporter der dette er naturlig.	A			Bilag 2
8.5	Systemet bør ha ferdig rapport(er) som innfrir til enhver tid gjeldende krav om rapportering til IMDI.	A			Bilag 2
8.6	Alle rapporter skal kunne eksporteres som Excel/Google sheet rapporter.	M
8.7	Alle rapporter bør kunne eksporteres som CSV og PDF rapporter.	A			Bilag 2
8.8	Alle brukere bør ha mulighet til å ta ut rapporter på den informasjon de har tilgang til.	A			Bilag 2
9	Krav om håndtering av e-post og sms
9.1	Systemet må håndtere både utgående og innkommende e-post som en integrert del av systemet	M
9.2	Systemet må håndtere både utgående og innkommende SMS som en integrert del av systemet.	M
10	Krav om varsling av brukere
10.1	Systemet skal kunne varsle brukere ved alle vesentlige hendelser som er relevant for brukertype, rolle eller tilgang. F.eks. skal en tolk varsles ved forespørsel om et oppdrag og en bestiller/kontaktperson skal kunne bli varslet ved avlysning av oppdrag.	M
10.2	System skal kunne varsle gjennom e-post , sms, internmeldinger i system eller evt. mobilapplikasjon.	M
10.3	Systemet skal kommet med et standardoppsett for varsling av de ulike brukertypene.	M

10.4	Systemet bør komme med et sett av standardmeldinger. Disse skal være enkle å få en oversikt over, og administrator skal kunne legge til flere standardmeldinger og endre de eksisterende.	A			Bilag 2
10.5	Bruker bør selv kunne velge hvilken kanal de foretrekker å bli varslet på i forhold til de ulike varslene	A			Bilag 2
10.6	Brukere bør selv kunne velge hvilke hendelser de ønsker å bli varslet om	A			Bilag 2
10.7	Tolkeformidler bør kunne overstyre innstillinger for varsel på andre brukere for hvert enkelt oppdrag.	A			Bilag 2
10.8	Systemet bør gi brukerne enkle mulighet for å varsling i forbindelse med forsinkelser eller andre uforutsette hendelser i forbindelse med gjennomføring av oppdrag	A			Bilag 2
10.9	Systemet bør kunne varsle interne brukere ved endringer i nasjonalt tolkeregister på blant annet kvalifikasjoner eller annet for tolk som er knyttet opp mot nasjonalt tolkeregister.	A			Bilag 2
11	Krav rundt sporbarhet
11.1	Systemet skal inneholde en kronologisk logg som som viser når et oppdrag er mottatt, hvem som har gjort hva med et oppdrag mm. Dette inkluderer varsler og annet som også er sendt ut av systemet eller brukere. Det skal f.eks. være mulig å gå inn på et oppdrag for å se hvilke tolker som har fått forespørsel om oppdraget.	M
12	Krav om skjermtolking
12.1	Systemet bør ha innebygd sikker løsning for videotolking	A			Bilag 2
12.2	Systemet skal støtte bruk av annen videoløsning ved å gi mulighet for sikker og effektiv distribuering av møtedetaljer med nødvendige påloggingsdetaljer.	M			Bilag 2
13	Krav om dokumenthåndtering for oversettelse
13.1	Systemet må støtte enkel dokumenthåndtering for ikke sensitive dokumenter.	M
13.2	Det er ønskelig at systemet støtter sikker dokumenthåndtering for sensitive dokumenter som skal oversettes. Her skal løsningen sikre innhold fra uvedkommende, hindre nedlastning og spredning av dokumentene samt slette dokumentene automatisk etter at det er levert tilbake til kunde.	A			Bilag 2
14	Satser for honorering og fakturering
14.1	Parametrene og satsene for honorering av oppdrag til xxxxxx og oversettere bør kunne endres, tilpasses av administrator.	M
14.2	Parametrene og satsene for fakturering av oppdrag til kundene bør kunne endres, tilpasses av administrator.	M
15	Melding og nyheter

15.1	Systemet skal støtte sending av meldinger internt i fagsytemet til bestillere, tolker og brukere	M
15.2	Systemet skal støtte å sende meldinger til flere brukere	M
15.3	Systemet skal gjøre det mulig å publisere nyheter og oppslag i løsningen for å kommunisere med alle brukertyper i løsningen	M

4.2 Krav i forbindelse med konfigurering av løsning

Krav Nr.	Beskrivelse av krav	Krav- kode	Svarkode Leverandør skal svare J/N/T om kravet oppfylles	Har Leverandør forbehold til kravet Beskrives i Vedlegg Forbehold	Leverandør skal beskrive sin oppfyllelse av kravet i	Type prisele ment
		(M, A, B)	(J/N/T)	(J/N)	Xxxxx	S/B
1	Språk
1.1	Det må være mulig å legge inn alle språk Tolketjenesten tilbyr tolk eller oversettelse for.	M
1.2	Det må være mulig å legge inn prioriteringslister på tolker for hvert enkelt språk basert på de tolkene som er registrert i systemet for angitt språk.	M
2	Fagområder
2.1	Det må være mulig å registrere og vedlikeholde et register over fagområder som f.eks. juridisk, barnevern, helse eller annet som brukes for å matche tolk/oversetter med oppdrag.	M
3	Klassifikasjon av utdanning
3.1	Det bør være mulig å opprette egne klassifiseringer av utdanning.	A			Bilag 2
3.2	Det bør være mulig å velge mellom ulike klassifikasjonsmetoder for utdanning.	A			Bilag 2
3.3	Det må være mulig å benytte IMDIs klassifikasjon.	M
3.4	Det må være mulig å utvide IMDIs klassifikasjon med egne elementer	M
3.5	Systemet skal alltid ha en oppdatert klassifikasjonsmetode basert på IMDIs gjeldende praksis	M
4	Utlysningsmetoder
4.1	Det skal være mulig å konfigurerer hvor lang tid en tolk har å svare på en forespørsel via en sekvensiell metode.	M

4.2	Det skal være mulig å sette en makstid for hver utlysningsmetode før bestillingen går til manuell behandling.	M
5	Satsregister
5.1	Mulighet til å registrere og endre satser for: Tolkeform (fremmøte, skjerm, telefon), Varighet på oppdrag Dag/kveldsoppdrag, helg- og helligdager Sats for oversettelser - per time hastetillegg Moms/ikke moms	M
6	Kunder
6.1	Mulighet for å importere kunder med bestillere/brukere basert på CSV filer eller andre tilsvarende filformater i en oppstartsfase.	M
6.2	Mulighet å skille mellom interne og eksterne kunder	M
6.3	Informasjon om kunde må minimum inneholde: - Kundeinfo: kundenr. firmanavn, organisasjonsnummer. telefon, e-post, kundetype, kundegruppe - Fakturaadressa - Kontaktinformasjon: postadresse, besøksadresse - Kontaktperson: Fornavn, Etternavn, Mobil tlf./Telefon, E-post	M
6.4	Det bør være mulig å sette opp standardbetingelser for nye kunder som f.eks.unntak fra gebyr for tolkeform, hasteoppdrag, avbruddsgebyr, kvelds- og helgetillegg og annet nødvendig for å kunne generere korrekt fakturagrunnlag fra systemet.	A			Bilag 2
6.5	Hver enkelt av parameterne/satsene over bør kunne settes/overstyres individuelt for hver enkelt kunde.	A			Bilag 2
6.6	Det bør være mulig å sette opp standardverdi for nye kunder om de kan bestille oppdrag direkte eller om de må via manuell behandling av Tolketjenesten	A			Bilag 2
6.7	Det bør være mulig å sette individuelt på hver kunde om deres bestillinger kan gå automatisk eller om de må via manuell behandling av Tolketjenesten.	A			Bilag 2
6.8	Det bør være mulig å konfigurere hvilke tolkeformer en kunde kan bestille med automatisert booking.	A			Bilag 2
6.9	Det bør være mulig å styre hvilke brukere hos kunden som skal varsles om hvilke hendelser på hvilke kanaler. Dvs. varsel om bestilling, avbestilling og endringer skal sendes til valgte brukere på epost og/eller SMS.	A			Bilag 2
7	Tolk/Oversetter

7.1	Det må være mulig å opprette tolker basert på CSV filer eller tilsvarende filformater i en oppstartsfase.	M
7.2	Det må være mulig å benytte IMDI’s klassifikasjon eller tilsvarende for å definere tolkens utdannelse.	M
7.3	Det må være mulig å legge inn flere språk pr. tolk med ulik klassifikasjon i henhold til tolkens utdanning.	M
7.4	Det må være mulig å legge inn betingelser for hver enkelt tolk som brukes i lønnsberegning etc.	M
7.5	Det må være mulig å skille mellom ulike typer betingelser pr tolk. F.eks. fastlønn for ansatt, oppdragstakere som mottar honorar, timesats i henhold til betingelser for frilansere, enkeltpersonsforetak som fakturere og tolker som er knyttet opp mot eksterne tolkeformidlere.	M
7.6	Det er ønskelig å overstyre satser pr fagområder pr tolk.	A			Bilag 2
7.7	Det må være mulig å konfigurere om en person gjør tolkeoppdrag og/eller oversettelsesoppdrag pr språk registrert på den personen. Ved oversettelse skal også oversettelsesretning kunne legges inn om det er relevant.	M
7.8	Det må være mulig å definere fagområder tolken tolker innenfor. Dette må taes hensyn til ved søk/utvelgelse.	M
7.9	Det skal være mulig å lagre følgende annen informasjon om en tolk: - Ordinære personopplysning - Tolkens unike tolkenummer (internnummer) - Unik ID som indentifiserer tolk i IMDI - Ansattnummer fra HR-system - Kontrakts-/ansettelsesforhold (Fast ansettelse, Timetolker, Honorarmottakere, Selvstendig næringsdrivende, Tolkeformidlingsbyrå, Andre offentlige tolkeformidlingstjenester) - Aktiv/inaktiv	M
7.10	Det må være mulig å reservere en tolk mot ulike type tolkeoppdrag	M
7.11	Det må være mulig å reservere en tolk mot ulike fagområder	M
7.12	Det må være mulig å konfigurere standard varslingsrutiner for Tolk	M
7.13	Det må være mulig å konfigurere om tolkens kalender skal vises eller ikke i kundens/bestillers bestillingsskjema.	M
8	Oppdragstyper
8.1	Det bør være mulig å Legge til, slette og vedlikeholde flere oppdragstyper. Pt. har er det 4 ulike tolkeoppdrag og 4 ulike oversettelsesoppdrag	A			Bilag 2

	- Et enkelt tolkeoppdrag for en tolk - Serie med tolkeoppdrag for en tolk - Flere tolker til et tolkeoppdrag - Flere tolker til en serie med tolkeoppdrag - Oversettelse av et dokument - Oversettelse av flere dokumenter til et språk - Oversettelse av et dokument til flere språk - Oversettelse av flere dokumenter til flere språk
8.2	Det er ønskelig å kunne spesifisere et antall tolker med gitt kvalifikasjonskrav for en type tolkeoppdrag. F.eks. en oppdragstype med et enkelt tolkeoppdrag med to tolker, på samme språk, på Kategori C eller høyere. Et annet eksempel kan være en serie på 3 oppmøter, med 1 tolk pr språk, som alle har Kategori C eller høyere.	A			Bilag 2
8.3	Det bør være mulig å velge hvilke felter som skal være med eller utelates for en oppdragstype. I tillegg bør det være mulig å angi hvilke felter som er obligatoriske pr oppdragstype.	A			Bilag 2
8.4	Det bør være mulig å navngi ulike oppdragstyper som opprettes. F.eks. - “Oversettelse av vitnemål”: Oversettelse av et dokument til et språk for en tolk. - ”Legekonsultasjon”: Et enkelt tolkeoppdrag for en tolk innenfor fagområde helse - “Fylkesnemndsak”: Et enkelt tolkeoppdrag med to tolker for samme språk innenfor fagområde - “Helsekontroll løp barn”: (2. 4. 6 uker, 1 år pr)	A			Bilag 2
8.5	Det bør være mulig å sette opp en standard tolkeform på hver oppdragstype Det er tre ulike tolkeformer for tolkeoppdrag. (1) Telefontolking, (2) Skjermtolking og (3) Fremmøtetolking.	A			Bilag 2
8.6	Det bør være mulig å styre om en oppdragstype er fastpris til kunde eller bestemt av tidsbruk, reisevei og andre parametere satt på kunde eller tolk. Dette er ofte naturlig i forbindelse med oversettelsesoppdrag.	A			Bilag 2
8.7	Det bør være mulig å sette opp standardgebyrer for hastebestilling, avlysning etter frist, og andre relevante gebyrer for hver oppdragstype	A			Bilag 2
8.8	Det bør være mulig å konfigurere om oppdragstype skal behandles automatisk eller gå via formidling. Oppdragstypen vil kun behandles automatisk om kunden som bestiller dette også har tilgang til automatisk håndtering på valgt tolkeform.	A			Bilag 2
8.9	Det bør være mulig å konfigurere utlysningsmetode for hver oppdragstype. Dvs. skal forespørsel gå ut til alle kvalifiserte tolker samtidig der “førstemann-til-mølla” gjelder eller skal den best kvalifiserte tolken forespørres først i henhold til algoritme.	A			Bilag 2
8.10	Det bør kunne parameterstyres om en oppdragstype kan bestilles som et hasteoppdrag, dvs. bestilles med kortere tid til oppstartsdato enn det som er satt som standard i krav.	A			Bilag 2
8.11	Det børl kunne parameterstyres for hver oppdragstype hvor lang tid i forveien en bestilling skal kunne gjøres.	A			Bilag 2

8.12	Det bør kunne parameterstyres for hver oppdragstype hvor lang tid i forveien det er mulig å avbestille/kansellere et oppdrag for bestiller/kunde.	A			Bilag 2
8.13	Det bør kunne parameterstyres hvor lang tid i forveien det er mulig å kansellere et oppdrag for tolk.	A			Bilag 2
8.14	Frist for rapportering etter gjennomført oppdrag bør være konfigurerbart. Dette er tiden en tolk og bestiller har til rådighet for å rapportere/godkjenne oppdraget uten at bestiller blir fakturert, eller tolk ikke får dette inn i sitt lønnsgrunnlag	A			Bilag 2
9	Saksbehandlingsstatuser
9.1	Løsningen må inneholde statuser på oppdrag som representerer saksbehandlingen. Disse bør minimum inneholde følgende: - Under arbeid - Avventer bekreftelse fra kunde - Avventer bekreftelse fra tolk - Utført - ferdig formidlet - Avlyst innen frist - Avlyst etter frist. Det skal være mulig for administrator av løsningen å sette opp egne statuser som skal kunne brukes i saksbehandlingen. Disse statusene må det også være mulig å filtrere oppdragene på senere.	M

4.3 Funksjonelle krav i forbindelse med hovedprosess - Formidling

Krav Nr.	Beskrivelse av krav	Krav- kode	Svarkode Leverandør skal svare J/N/T om kravet oppfylles	Har Leverandør forbehold til kravet Beskrives i Vedlegg Forbehold	Leverandør skal beskrive sin oppfyllelse av kravet i	Type priselement
		(M, A, B)	(J/N/T)	(J/N)	Xxxxx	S/B
1	Krav i forbindelse med bestilling av oppdrag
1.1	Generelle krav
1.1.1	Systemet må ha grensesnitt for innlegging av bestilling for brukertype “kunder/bestillere”	M
1.1.2	Systemet må ha grensesnitt for innlegging av bestilling av oppdrag for brukertype “interne brukere”	M
1.1.3	Bestiller skal få kvittering om oppdragene de har bestilt med referansenummer, dato og tidspunkt for oppdragene.	M
1.1.4	Systemet bør varsle bestiller dersom det legges inn en identisk bestilling som er lagt inn fra tidligere (F.eks. hvis bestiller, tidspunkt og klient info er det samme).	A			Bilag 2
1.2	Bestilling av tolkeoppdrag
1.2.1	Løsningen må ha grensesnitt for bestilling av tolkeoppdrag. Grensesnitt må ha bl.a. disse felt: - Bestiller*: Fornavn, Etternavn, Mobil tlf./Telefon, E-post, Enhet/Firma (automatisk utfylt basert på innlogget bruker, men mulig å endre) - Kontaktperson: Fornavn, Etternavn, Mobil tlf./Telefon, E-post, Enhet/Firma. (automatisk utfylling hvis kontaktperson og bestiller er samme person) - Minoritetsspråklige brukere*: Språk/dialekt, Fornavn, Etternavn, Fødselsdato (mulighet til å legge flere personer) - Fagområde*: Liste med mulige fagområder (mulighet til å velge flere av alternativene) - Type tolking*: Skjermtolking, Telefontolking, Fremmøtetolking (mulighet til å velge flere av alternativene. Mulig å velge skjerm og telefon eller bare fremmøte) - Ved oppmøte: Oppmøteadresse* - Ønsket kjønn på tolk - Vedlegg - Tema for samtalen* - Kommentarer	M

	Felt merket med * er obligatoriske i utgangspunktet, men dette skal være konfigurerbart, enten via oppdragstype eller en generell innstilling.
1.2.2	Aktuelle tidspunkt for valgt oppdrag skal vises i en kalendervisning i minst 12 måneder frem i tid. Denne kalenderen skal vises som en aggregert kalender basert kalendere fra tolker som er aktuelle for det valgte oppdraget. Kalenderen bør sørge for at: - Tid der en eller flere tolker har registrert seg som ledig skal vises på en egnet måte, også for fargeblinde. - Tid der det finnes tolker som oppfyller kriterier for oppdraget, som ikke har et annet tolkeoppdrag samtidig, men som ikke har registrert seg som ledig i sin kalender skal vises som på egnet måte. - Tid der det ikke finnes tolk som oppfyller kriteriene skal markeds på en egnet måte.	M
1.2.3	Velges et ledig tidspunkt, skal tolk bookes automatisk og bestiller skal få en bekreftelse umiddelbart. Tolk skal da varsles om oppdraget.	M
1.2.4	Velges et tidspunkt som ikke er ledig, men det finnes mulige tolker skal disse kontaktes for godkjenning av oppdraget basert på valgt utlysningsmetode for aktuelt oppdrag ved bestilling.	M
1.2.5	Velges et tidspunkt der det ikke finnes tolk, skal bestillingen gå rett til intern formidling.	M
1.2.6	Velges et tidspunkt der det ikke finnes tolk, skal bestiller varsles om at det kanskje ikke er mulig å skaffe tolk i dette tidsrommet på en hensiktsmessig måte.	M
1.2.7	Det ønskes en mulighet til å legge flere datoer og tidspunkt i for hver enkelt oppdragstype.	A			Bilag 2
1.3	Skjermtolking	M
1.3.1	Det bør være mulig å velge om det skal brukes eget system eller det som er innebygd i fagsystemet.	A			Bilag 2
1.3.2	Ved bruk av innebygd videoløsning bør det være mulig å legge til flere deltakere i møtet.	A			Bilag 2
1.3.3	Ved bruk av egen videoløsning bør det være mulig å legge inn møtedetaljer som formidles til tolk(er) og bestiller.	A			Bilag 2
1.4	Bestilling av oversetting
1.4.1	Løsningen må ha grensesnitt for bestilling av oversettelsesoppdrag Grensesnitt skal ha bl.a. disse felt: - Bestiller*: Fornavn, Etternavn, Mobil tlf./Telefon, E-post, Enhet/Firma hentes fra AD men må kunne redigeres. (automatisk utfylt basert på innlogget bruker, men mulig å endre)	M

	- Kontaktperson: Fornavn, Etternavn, Mobil tlf./Telefon, E-post, Enhet/Firma. (automatisk utfylling hvis kontaktperson og bestiller er samme person) - Minoritetsspråklige brukers*: Fornavn, Etternavn, Fødselsdato (mulighet til å legge flere minoritetsspråklige brukere) - Fra og Til språk* - Dokument sensitivitet*: Sensitiv eller ikke sensitive - Dokumenttype: Original, Bekreftet kopi, Ubekreftet kopi. - Fagområde*: vitnemål, vedtak, informasjon - Haster (mulighet til å huke av) - Antall sider/ord/tegn - Antall timer - Ønsket frist over oversettelse - Mulighet for opplasting av dokument - Mulighet for innleggelse av informasjon om hvordan en får tilgang til dokumenter til oversettelse Felt merket med * er obligatoriske i utgangspunktet, men dette skal være konfigurerbart, enten via oppdragstype eller en generell innstilling.
1.4.2	Det bør være mulig for bestiller å laste opp et dokument som skal oversettes på sikker måte i henhold til sensitiv informasjon og gdpr	A			Bilag 2
1.4.3	Det bør være mulig å legge ved informasjon ved bestilling på hvordan oversetter(e) kan få sikker tilgang til dokument som skal oversettes som et alternativ til å laste opp dokumentene i løsningen.	A			Bilag 2
1.5	Tillegg for interne bestillere (“Formidlere”)
1.5.1	En intern bruker med tilgang til å bestille/formidle oppdrag skal i størst mulig grad være i stand til å formidle oppdrag mest mulig effektivt. Det betyr at denne brukeren må kunne overstyre det meste av standardoppsettet som er satt for å formidle oppdrag automatisk. Dette inkluderer blant annet: - Velge om oppdrag skal faktureres eller ikke og om fakturering gjelder for en bestilling, endring eller avbestilling/kansellering, hastebestilling, ubekvem tidspunkt, osv - Velge tildelingsmetode for ethvert oppdrag, uavhengig av standard tildelingsmetode på oppdraget. - Velge tolker ut fra prioriterte lister. - Bestille et oppdrag uavhengig av gjennomføringstidspunkt. - Etterregistrere et oppdrag - Avbestille/kansellere oppdrag uavhengig av frister. - Editere på eksisterende bestillinger, også dem som er gjort av kunde.	M

1.5.2	En bestilling for et oppdrag skal kunne lagres uten å ha registrert tolk(er). Den skal vises som en egen status. f.eks. “Ingen tolk”.	M
1.5.3	En intern bestiller skal kunne lagre et nytt oppdrag som kladd fram til det er ferdig.	M
2	Krav i forbindelse med aksept av oppdrag
2.1	Tolker og oversettere som har satt seg ledig i sin kalender skal varsles om oppdrag de har blitt booket til gjennom foretrukne kanaler.	M
2.2	Tolk/Oversetter skal kontaktes i forhold til valgt tildelingsmetode for oppdraget	M
2.3	Tolk/Oversetter skal kontaktes gjennom foretrukne kanaler med forespørsel om oppdraget	M
2.4	Tolk/Oversetter må informeres om tid for å akseptere eller avslå oppdraget. F.eks. må oppdraget aksepteres innen (parameterstyrt) før det går videre til nestemann på listen.	M
2.5	Tolk må kunne akseptere eller avslå oppdraget direkte i grensesnittet så lenge det er innenfor akseptansefristen	M
3	Krav i forbindelse med gjennomføring av oppdraget
3.1	Ved alle tolkeoppdrag skal systemet tilby en kalenderoppføring, i de mest brukte kalenderformatene, for nedlasting for både tolk og bestiller.	M
3.2	Tolk og bestiller skal ha på en hensiktsmessig måte få oversikt over all nødvendig informasjon vedrørende oppdrag. Ved bruk skjermtolking skal f.eks. all nødvendig for å koble seg på videomøtet være tilgjengelig i løsningen på en oversiktlig måte.	M
3.3	Opplastet/tilknyttet dokument vises sammen med oppdrag info til tolker	A			Bilag 2
3.4	Tolkene varsles/påminnes i god tid tid før oppdrag. Denne tiden bør det være mulig for å konfigurere	A			Bilag 2
3.5	Ved oversettelsesoppdrag bør systemet tilby en sikker måte å oversette sensitive dokumenter.	A			Bilag 2
3.6	Systemet bør støtte å bruke forskjellige språk/skrifttyper i dokument som oversettes.	A			Bilag 2
4	Krav forbindelse med rapportering i ettertid av oppdraget
4.1	Tolkeoppdrag skal kunne rapporteres med status valg (utført, tolk ikke møtt, avlyst) samt felt for å skrive kommentar for både tolk og bestiller. Kunde blir avkrevd å rapportere lengden på møte.	M
4.2	Tolk må svare innenfor fristen for at oppdraget skal inngå i lønnsgrunnlaget generert fra systemet. Gjelder ikke fast ansatte tolker.	M

4.3	Bestiller må svare innenfor fristen, f.eks. 24 timer, for at oppdraget ikke skal faktureres etter gjeldende sats på oppdraget og kunde. Denne fristen skal være konfigurerbar for administrator.	M
4.4	Bestiller og tolk skal varsles i forkant av svarfrist i henhold til deres egne varslingsrutiner	M
4.5	Mulighet for tolkene til å rette opp rapportert oppdrag innenfor fristen som er satt.	M
4.6	Tolk skal ha mulighet til å legge til kvitteringer for utlegg med beløp og kommentar samtidig ved rapportering, innenfor fristen.	M
5	Krav i forbindelse med endring av oppdrag
5.1	Det skal være mulig for kunde å legge inn endring på en eksisterende bestilling.	M
5.2	Ved endring bør regler for endring knyttet til kundeforhold og oppdragstype legges til grunn for om det er mulighet for endring og for å beregne evt. gebyrer som skal faktureres.	A			Bilag 2
6	Krav i forbindelse med avbestilling av oppdrag
6.1	Det skal være mulig for kunde å avbestille et oppdrag innenfor fristen for avbestilling	M
6.2	Tolkeformidlere skal varsles dersom en tolk avbestiller et oppdrag.	M
6.3	Ved avbestilling fra kunde bør regler for endring knyttet til kundeforhold og oppdragstype legges til grunn for mulighet for avbestilling og for å beregne evt. gebyrer som skal faktureres.	A			Bilag 2
6.4	Tolk kan trekke fra oppdrag innen frist for avbestilling gjennom portal. tolke får melding om å henvende seg til tolketjenesten for å melde avbud etter frist	A			Bilag 2

4.4 Funksjonelle krav i forbindelse med støtteprosesser

Krav Nr.	Beskrivelse av krav	Krav- kode	Svarkode Leverandør skal svare J/N/T om kravet oppfylles	Har Leverandør forbehold til kravet Beskrives i Vedlegg Forbehold	Leverandør skal beskrive sin oppfyllelse av kravet i	Type priselement
		(M, A, B)	(J/N/T)	(J/N)	Xxxxx	S/B
1	Fakturere kunder
1.1	Interne brukere med riktig tilgang skal kunne generere et fakturagrunnlag for en gitt periode.	M
1.2	Det skal være mulig å generere en avstemming fil til regnskapet.	M
1.3	Oppdrag og hendelser som danner grunnlaget for faktura skal vises på en oversiktlig måte.	M
1.4	Det skal være enkelt å velge hvilke oppdrag og hendelser som skal være med i generert fakturagrunnlag.	M
1.5	Det skal være enkelt å endre/overstyre alle satser og verdier knyttet til hvert oppdrag fra oversikten. Alle endringer skal loggføres og gjøres sporbar.	M
1.6	Oppdrag der kunde ikke har avlagt rapport innenfor fristen inngår som grunnlag for faktura etter gjeldende sats.	M
1.7	Løsningen bør kunne generere korrigerings grunnlag basert på endringer gjort på allerede fakturerte oppdrag	A			Bilag 2
2	Lønne tolker
2.1	Kun oppdrag tolk har rapportert på innenfor fristen inngår som grunnlag for lønn.	M
2.2	Løsningen bør automatisk overføre lønnsgrunnlag til lønnssystem via en egen integrasjon.	A			Bilag 2
2.3	Interne brukere med riktig tilgang skal ha mulighet til å ta ut oversikt over lønnsgrunnlag overført til lønnssystem for en gitt periode.	M
2.4	Interne brukere med riktig tilgang kan overstyre hvilke oppdrag som inngår som lønn.	M
2.5	Løsningen må håndtere endring i allerede oversendt lønnsgrunnlag om dette blir endret på.	M
2.6	Når tolkeoppdrag avlyses etter frist så skal godtgjørelse godskrives. Dersom tolken får nytt oppdrag i hele eller deler av samme tidsrom så skal ikke tolken få dobbelt betalt per tidsenhet. (Kan ikke få dobbelt betalt for en times arbeid)	A			Bilag 2

3	Oppdatere tilgjengelighet for tolk
3.1	En tolk må kunne sette sin tid som ledig, på forespørsel eller sperret i en kalender.	M
3.2	En tolk skal ikke ha mulighet til å sperre i tidspunkter de allerede har fått tolkeoppdrag uten å sende avbestilling først.	M
3.3	Tolk må varsles om at de ikke har satt sin egen status på kommende måned / uke / dag	A			Bilag 2
4	Uttak av lønn/fakturagrunnlag for tolk/oversetter
4.1	En tolk må kunne ta ut en rapport som viser lønns- eller fakturagrunnlag basert på hvordan avtale denne tolken er satt opp med i løsningen	A			Bilag 2
4.2	Det bør være mulig å ta ut denne rapporten som et pdf dokument	A			Bilag 2
4.3	Det bør være mulig å se en oversikt i systemet om hvilke oppdrag som inngår i grunnlaget	A			Bilag 2
4.4	Det bør være mulig å kontakte tolkeformidlere	A			Bilag 2

4.5 Andre funksjonelle krav knyttet til brukertyper

Krav Nr.	Beskrivelse av krav	Krav- kode	Svarkode Leverandør skal svare J/N/T om kravet oppfylles	Har Leverandør forbehold til kravet Beskrives i Vedlegg Forbehold	Leverandør skal beskrive sin oppfyllelse av kravet i	Type priseleme nt
		(M, A, B)	(J/N/T)	(J/N)	Xxxxx	S/B
1	Bestillere
1.1	Skal ha mulighet til å se se tidligere oppdrag med statuser i løsningen	M
1.2	Skal ha mulighet for å se fremtidige oppdrag med statuser i løsningen	M
1.3	Skal ha mulighet for å se varsler og nyheter fra Tolketjenesten i løsningen	M
2	Tolk/Oversetter
2.1	Skal ha mulighet for å se oppdrag på flere ulike vis. Blant annet skal følgende visninger være mulig: - Dagens oppdrag i liste og kalender i løsningen. - Oppdrag som er utført men ikke rapportert - Oppdrag som er utført og ferdig rapportert - Oversikt over sine egne oppdrag basert på valgte fra og til datoer	M
2.2	Mulighet for å se alle oppdrag med detaljinfo (kontaktperson, dato, tidspunkt, språk, referansenr. Minoritetsspråklige brukers navn og fødselsdato, tolkeform, oppmøtested, tema) Klientinformasjon i oppdrag skal vises fram til aksept, eller fram til gjennomføring dersom tolk ikke aktivt har godkjent oppdrag.	M
2.3	Skal ha mulighet til å vise beregnet utbetalinger basert på oppdrag innen valgte fra og til datoer	M
3	Interne brukere (Tolkeformidlere, Lønnsmedarbeidere, Admin)
3.1	Tilgjengelige grensesnitt skal være i forhold til hvilke tilganger en intern bruker har. F.eks. må brukere med tilgang til formidling har gode oversikter for å vise saksbehandlings gangen med forskjellige statuser for å kunne gjøre jobben effektivt.	M

4.6 Integrasjoner, samhandling mot andre systemer og api-er

Krav Nr.	Beskrivelse av krav	Krav- kode	Svarkode Leverandør skal svare J/N/T om kravet oppfylles	Har Leverandør forbehold til kravet Beskrives i Vedlegg Forbehold	Leverandør skal beskrive sin oppfyllelse av kravet i	Type priselement
		(M, A, B)	(J/N/T)	(J/N)	Bilag	S/B
1	Løsningen bør ivareta sikker og fleksibel autentisering av brukere. Det vil blant annet legges vekt på at: Løsningen støtter at brukere kan autentiseres med Føderert identitet fra kommunens identitetstjenester (for tiden Microsoft Azure AD og Google cloud Identity) via rådende standarder for føderert identitet inkl. SAML og OIDC. Hvis fagsystemet selv tilbyr autentisering av bruker, skal fagsystemet sikre: - At krav til passordkvalitet kan konfigureres i tråd med kommunens sikkerhetspolicy. - At gjentatte feilede påloggingsforsøk forhindres og forsinkes for å beskytte mot passordgjetting. - At eventuelle muligheter for å resette passord kan deaktiveres av kommunen, og at fagsystemet benytter sikre mekanismer for å bekrefte brukernes identitet. - At passord lagres på en måte som forhindrer at de kan gjenskapes. - At en sikker mekanisme for sterk autentisering benyttes i tillegg til brukernavn og passord. Tillatte mekanismer bør kunne konfigureres av kommunen. Det er mulig å konfigurere hvilke IP-adresser som tillates for lovlig kommunikasjon mot løsningen Leverandøren skal beskrive hvordan løsningen legger til rette for fleksibel autentisering opp mot Trondheim kommunes eksisterende infrastruktur.	A			Bilag 2
2	Løsningen bør kunne autentisere eksterne brukere ved hjelp av ID-porten. Integrasjon mot ID-porten skal verifiseres mot ID-portens Integrasjonsguide og krav til verifikasjonstester.	A			Bilag 2

3	Løsningen bør støtte at eksterne bestillere/kunder som ikke er på AD må kunne benytte seg av felles brukernavn og passord for kunden med mulighet for å velge hvem hos kunden de bestiller for. Løsningen bør i slike tilfeller ta hensyn til personvern. Det skal i ikke være mulig å identifisere klienter på en enkel måte via en slik innlogging. Leverandør bes om å beskrive hvordan hensynet til personvern blir ivaretatt.	A			Bilag 2
4	Det vektes positivt at løsningen kan tilby grensesnitt/API for å opprette, endre og slette brukerkontoer og tilganger/roller, og legge til rette for automatisert tilgangsadministrasjon. Løsningen bør støtte standarder for synkronisering av identitetsinformasjon, som for eksempel SCIM v2. Løsningen bør ha støtte for synkronisering av gruppe/rolletilhørighet fra kommunens systemer. Leverandøren skal beskrive hvilke kapabiliteter løsningen og grensesnittene har for automatisert og manuelt ajourhold av identiteter, samt hvilke standarder og hvilke typer kataloger det kan synkroniseres gruppe-/rolletilhørighet med.	A			Bilag 2
5	Integrasjon mot Agresso Unit 4 (LIFT) for faktureringsgrunnlag. Integrasjon skal fungerer slik at det skal være mulig å ta ut grunnlagsfiler for overføring til LIFT. Disse filene skal skal være i formatet LG04. Det forventes at nødvendige parametere for å eksportere til LG04 formatet. Her er det spesielt viktig at korrekte artikkelnummer benyttes. I tillegg til fil må det være mulig å ta ut en avstemmingsrapport som kan brukes for regnskap for å forsikre seg over at all data er kommet over i fil integrasjon.	M
6	Integrasjon mot Visma Bluegarden for lønnsgrunnlag og reiseutgifter. For denne integrasjon er det sterkt ønskelig at fagprogrammet har en direkte integrasjon. Dvs. at grunnlaget for hvert enkelt oppdrag overføres til Bluegarden etter hvert som oppdragene er ferdigstilt. Nødvendige felter for integrasjon er spesifisert i vedlegg 3 til Bilag 1	A			Bilag 2
7	Integrasjon mot Nasjonalt tolkeregister IMDI. Det forventes at systemet kan integrere med Nasjonalt tolkeregister for å hente ut informasjon om tolker basert på deres unike identifikasjon, få varsler om vesentlige endringer hos tolker og mulighet til å søke direkte i tolkeregisteret etter tolker, uavhengig om de er registrert som tolker hos Trondheim Kommune.	M
8	Det vil vektes positivt om systemet tilbyr api-integrasjoner for alle eller store deler av løsningen. Dette gjelder ikke bare uthenting av data, men også mulighet for å utføre handlinger, s.feks. booking av et tolkeoppdrag mm. Trondheim Kommune er på jakt etter et system som skal forenkle og effektivisere formidling av tolk og oversettelse. Det kan i fremtiden bli aktuelt å integrere løsningen i andre fagsystem og det er derfor ønskelig med	A			Bilag 2

	denne muligheten allerede nå. Dette gjelder spesielt med tanke på arkivering. All informasjon knyttet til behandling og oppdrag burde kunne hentes ut via AP i løsningen. Autentisering og Autorisering for bruk av API må støtte moderne protokoller.
9	Integrasjon mot Google meet eller en annen videotolking løsning	A			Bilag 2
10	Integrasjon mot Google e-post	M

5 IKKE-FUNKSJONELLE KRAV OG TEKNISKE KRAV

Krav Nr.	Beskrivelse av krav	Krav- kode	Svarkode Leverandør skal svare J/N/T om kravet oppfylles	Har Leverandør forbehold til kravet Beskrives i Vedlegg Forbehold	Leverandør skal beskrive sin oppfyllelse av kravet i	Type priselement
		(M, A, B)	(J/N/T)	(J/N)	Xxxxx	S/B
1	Brukerstøtte, opplæring og dokumentasjon
1.1	Alle brukerstøtte skal utføres på norsk språk.	M
1.2	Fagsystemet skal tilby kontekstuell hjelp og brukerveiledning/-støtte i bruk av fagsystemet. Med kontekstuell menes hvilken aktivitet eller arbeidsoppgave brukeren jobber med.	M
1.3	Leverandøren er ansvarlig for utarbeidelse av en opplæringsstrategi og -plan som skal godkjennes av Kunden. Disse må inneholde følgende: - Leverandøren skal i starten av etableringsprosjektet gi alle prosjektdeltakerne en grundig innføring i så vel løsningskonsept som implementeringsmetode - Leverandøren skal gjennomføre opplæring av brukere (rollebasert opplæring) som skal teste løsningen før akseptansetesten skal utføres av Kunden.	M
1.4	Det vektlegges positivt om leverandørs beskriver hvordan deres brukerstøtte kan samhandle med Trondheim Kommunes IT-Brukerhjelp (1. linje) basert i ITIL-prosesser for drift. Det er ønskelig at Leverandør kan integrere deres system for brukerstøtte/oppfølging av feil og andre henvendelser opp mot Trondheim Kommunes ServiceNOW.	A			Bilag 2
2	Informasjonssikkerhet og personvern

2.1	Løsningen skal støtte at Kunden er i stand til å sikre at de grunnleggende prinsippene for behandling av personopplysninger er oppfylt. Prinsippene som beskrevet i Lov om behandling av personopplysninger (GDPR/POL) artikkel 5: - Prinsippet om lovlighet, rettferdighet og åpenhet - Prinsippet om formålsbegrensning - Prinsippet om dataminimering - Prinsippet om riktighet - Prinsippet om lagringsbegrensning - Prinsippet om integritet og konfidensialitet Øvrige krav til fagsystemets oppbevaring og behandling av personopplysninger følger av enhver tids gjeldende lover og forskrifter. Løsningen skal ha innebygget personvern og de mest personvernvennlige valgene som standardinnstilling. Se også Datatilsynets beskrivelse av de syv prinsipper for innebygd personvern. Disse skal følges.	M			Bilag 2
2.2	Løsningen må sikre at klientinformasjon ikke trenger å være tilgjengelig lengre enn strengt tatt nødvendig. F.eks. Skal navn og personnummer for klienter ikke lengre vises på et gjennomført og ferdig rapportert oppdrag	M
2.3	Løsningen bør ha robuste mekanismer som sørger for at personopplysninger og annen informasjon sikres med hensyn til integritet, konfidensialitet, tilgjengelighet, sporbarhet og robusthet (IKTSR). Integritet (I): Personopplysninger og annen informasjon sikres mot utilsiktet og ulovlig ødeleggelse, tap og endringer. Konfidensialitet (K): Personopplysninger og annen informasjon sikres mot uautorisert utlevering og tilgang. Tilgjengelighet (T): Personopplysninger og annen informasjon er tilgjengelig for autoriserte. Sporbarhet (S): Endringer som gjøres i programvaren og på personopplysninger og annen informasjon dokumenteres. Sporing har som formål å kunne håndtere sikkerhetsbrudd. Robusthet (R): Programvaren som behandler personopplysninger og annen informasjon, er beskyttet mot for eksempel sårbarheter, angrep, og uhell. Det vil blant annet legges vekt på: ● I hvilken grad løsningen har robuste mekanismer for å beskytte mot ødeleggelse og tap av data.	A			Bilag 2

	● I hvilken grad løsningen har robuste mekanismer for sikre at opplysninger ikke er tilgjengelig for eller kan endres av uautoriserte, som kryptering og tilgangsstyring, både ved lagring og overføring ● I hvilken grad løsningen har robuste mekanismer for å beskytte mot tjenestenektangrep og gjenoppretting av drift ved uforutsette hendelser. ● I hvilken grad løsningen har robuste mekanismer for å identifisere og autentisere brukere, og spore aktiviteter i løsningen slik at det er mulig å spore all endring og tilgang til personopplysninger. ● I hvilken grad løsningen har hensiktsmessige mekanismer for å gjøre sikkerhetshendelser tilgjengelig for Kunden på strukturerte formater. ● I hvilken grad løsningen har robuste mekanismer for å oppdage, beskytte mot og håndtere angrep og uautoriserte handlinger som OWASP top 10 og lignende. ● I hvilken grad sikkerhetsmekanismene er dekkende for alle grensesnitt Beskriv hvordan løsningen sikrer IKTSR.
2.4	Løsningens driftsplattform bør være robust, skalerbar og er velprøvd. Det vil blant annet legges vekt på: ● I hvilken grad driftsplattformen har relevante sertifiseringer og følger relevante bransjestandarder. ● I hvilken grad driftsplattformen er velprøvd med kommersiell utbredelse, og i hvilken grad den er geografisk redundant. ● I hvilken grad driftsplattformen leverer skalerbarhet, tilgjengelighet og kontinuerlig drift for fagsystemet. ● I hvor stor grad plattformen har mekanismer og prosesser for monitorering av ytelse, feil og brukeropplevd responstid. ● I hvilken grad driftsplattformen har mekanismer for å detektere sikkerhetshendelser (IDS/IPS, bli utsatt for ondsinnet kode, applikasjonsbrannmurer, DDoS-beskyttelse, tiltak som forhindrer eller sikrer at man oppdager uautoriserte eller ikke-planlagte endringer). ● I hvilken grad driftsplattformen har mekanismer for å håndtere privilegert tilgang til driftsmiljø, overvåkning, sporbarhet og kontroll med egne driftsressurser og tredjeparter. Leverandøren beskriver hvordan kravet oppfylles	A			Bilag 2
2.5	Løsningen bør sikre at det er full separasjon mellom data fra ulike Kunder. Data fra ulike kunder/behandlingsansvarlige skal være skilt fra hverandre på en sikker måte. Løsningen skal beskytte mot at feil i konfigurasjon, feil i	A			Bilag 2

	administrasjonsgrensesnittet, menneskelige feil eller ondsinnede handlinger og angrep fører til at det oppstår datalekkasje mellom ulike kunder i løsningen, eller mellom produksjons- og testmiljøer. Leverandøren skal beskrive hvordan full separasjon mellom informasjon fra ulike kunder sikres, samt hvordan Leverandøren validerer effektiviteten av separasjonsmekanismene.
2.6	Kommunikasjonssikkerhet All kommunikasjon med Løsningen og mellom komponenter i Løsningen skal foregå over krypterte kanaler, og det skal være mulig å blokkere eventuelle usikre/ukrypterte kommunikasjonsporter. Det skal benyttes anerkjente krypteringsmekanismer uten kjente sårbarheter. Alle tjenester som benytter SSL-sertifikater skal benytte offentlige sertifikater med god dekning i standard nettlesere, og uten kjente svakheter. Validering vha. SSL Labs minimum karakter A kan benyttes for å validere oppfyllelse. Alle tjenester som konsumerer andre SSL-baserte tjenester skal validere sertifikater mot et tiltrodd tillitsanker.	M
2.7	Epostsikkerhet For løsninger som skal sende ut epost med avsenderadresse under Trondheim kommunes domenenavn, skal utsendelsen primært foregå via Trondheim kommunes epostløsning. Om løsningen sender epost fra egen server, skal denne ha ip som kan registreres i TKs SPF-record og støtte DKIM signering.	M

2.8	Styringssystem for informasjonssikkerhet Leverandøren bør ha et styringssystem for informasjonssikkerhet knyttet til driften av løsningen, basert på ISO/IEC 27001 eller tilsvarende anerkjent standard for informasjonssikkerhet. Styringssystemet skal dekke alle organisasjonsenheter, fysiske lokasjoner, systemer og tjenester som inngår i leveranseprosessen. Leverandøren skal ha et aktivt forhold til endringer i regulative forhold, og tilpasse tjenesten til endringer i lov og forskrift som berører Kunden. Leverandøren skal sikre forsvarlig kontroll med underleverandører, som public cloud leverandører. Leverandøren skal ha dokumentasjon som tilfredsstiller kravene til god sikkerhetspraksis, i henhold til anerkjente standarder for styringssystem for informasjonssikkerhet. Leverandøren skal beskrive sitt styringssystem, sikkerhetsorganisering og tekniske og organisatoriske sikkerhetstiltak for leveransen. Beskrivelsen skal være egnet for å kunne brukes som vedlegg til Databehandleravtalen.	A			Bilag 2
2.9	Leverandøren bør gjennomføre penetrasjonstester i driften av løsningen. Leverandøren skal gjennomføre penetrasjonstester på løsningen minimum en gang i året. Penetrasjonstestene skal gjennomføres iht. anerkjent metodikk for penetrasjonstesting, eksempelvis NIST SP800-115, og dekke kritiske komponenter i løsningen. Testene skal dekke både interne og eksterne angrepsvektorer, infrastruktur og applikasjoner, og skal gjennomføres av kvalifisert personell. Kunden, eller tredjepart utpekt av Kunden, skal ha rett til å gjennomføre sikkerhetstester av løsningen så lenge dette ikke innebærer unødig risiko eller uforholdsmessig påvirker løsningenskapasitet.	A			Bilag 2
2.10	Løsningen bør utvikles i samsvar med en anerkjent utviklingsprosess for sikker programvareutvikling. En utviklingsprosess for sikker utvikling skal sikre at: ● Løsningen utvikles i tråd med anerkjente rammeverk og veiledninger for sikker utvikling som for eksempel OWASP Application Security Verification Standard (ASVS), ISO/IEC 27034, Microsoft SDL, eller tilsvarende og Datatilsynets veileder «Programvareutvikling med innebygd personvern».	A			Bilag 2

	● Alle utviklere gis opplæring i sikker utvikling. ● Løsningen blir utviklet med input fra en etablert trusselmodell, samt misbrukstilfeller for systemet, basert på anerkjente metoder som STRIDE/DREAD eller tilsvarende. ● Leverandøren fører kontroll med all tredjeparts biblioteker og komponenter i løsningen for avdekkede sikkerhetssårbarheter ● Leverandøren gjennomfører koderevisjon og sikkerhetstesting som en integrert del av utviklingsprosessen ● Leverandøren benytter versjonshåndteringsløsninger som ikke har kjente sikkerhetshull, samt sporer hvem som utfører endringer av kildekoden.
3	Prosjekt- , fremdriftsplan og administrative bestemmelser
3.1	Leverandør skal utarbeide en realistisk og fremdriftsplan for implementering. Prosjekt- og fremdriftsplanen skal ta hensyn til Xxxxxx sitt bidrag i gjennomføringen, samt krav til utarbeidelse og godkjenning av dokumentasjon. Plan skal som et minimum inneholde følgende aspekter: - Beskrivelse på hvordan samarbeidet med Kunden er tenkt løst herunder rapportering av status og fremdrift, godkjenning av leveranser etc. - Beskrive hvordan implementeringen i praksis skal gjennomføres i forhold til digitale møteplasser og fysisk tilstedeværelse hos Kunden slik at man sikrer en god gjennomføring av leveransen. - Beskrive hvilken kompetanse og kapasitet som Kunden må stille tilgjengelig overfor Leverandøren i implementeringsfasen.	M			Bilag 2
3.2	For alle nøkkelfunksjonene i leverandørens organisering skal leverandøren stille til rådighet navngitte ressurser (nøkkelressurser). Leverandøren skal sikre at ressursene har tilstrekkelig kapasitet til å kunne gjennomføre leveransen iht plan.	M
3.3	Leverandøren og eventuelle underleverandører skal på forespørsel i avtaleperioden dokumentere lønns- og arbeidsvilkårene til ansatte som medvirker til å oppfylle avtalen. Kunden forbeholder seg retten til å gjennomføre nødvendige sanksjoner, dersom leverandøren eller eventuelle underleverandører ikke etterlever kontraktens klausul om lønns- og arbeidsvilkår.	M
3.4	Leverandøren skal stille med egen dedikert ressurs som møter Xxxxxx sin avtaleansvarlig. Det skal gjennomføres faste møter med Kunden som har som formål å følge opp leveransen og å se på forbedringsområder. Dette skal skje i kunden sine lokaler der annet ikke er avtalt. Leverandøren har ansvar for å skrive møtereferat. Alle rapporter som er knyttet til oppfølging av leveransen skal sendes Kunden en uke før møtet.	M
4	Testing og godkjenning

4.1	Leverandøren er ansvarlig, i samarbeid med Xxxxxx, for å utarbeide et underlag til Kundens akseptansetest og akseptansetestplan med detaljerte beskrivelser av hva som skal testes med akseptansekriterier. Det skal utarbeides brukerveiledning til testpersonene og generell bistand i gjennomføringen av akseptansetesten.	M			Bilag 2
4.2	Leverandør har ansvar for å ha gjennomført og dokumentert ytelsestest med hensyn til krav til responstid.	M
4.3	Leverandøren skal beskrive hvordan prøvekonvertering og konvertering av data fra Kundens eksisterende løsninger til ny løsning er tenkt løst	M			Bilag 2
4.4	Leverandøren bør stille verktøyet til rådighet for Kunden for registrering av identifiserte feil.	A			Bilag 2
5	Drift, vedlikehold og ytelse
5.1	Fagsystemet skal leveres som en skybasert SaaS-tjeneste som er tilgjengelig over internett. Med SaaS menes at fagsystemet leveres som en tjeneste som ikke krever installering av klientprogramvare hos brukerne eller serverprogramvare i kommunene, og at Leverandøren gjennomfører all drift, forvaltning, vedlikehold, videreutvikling og oppdateringer av fagsystemet.	M
5.2	Systemet skal ha tilgjengelighetsgrad på middels: Dvs. høyere enn 98,00 %	M
5.3	Tjenesten skal være tilgjengelig i åpningstiden mellom kl. 07:00 og 22:00.	M
5.4	Løsningen må fortsette å tilby funksjonalitet selv i tilfeller det er feil på systemer som løsningen er integrert med.	M
5.5	Fagsystemet bør kunne benyttes kontinuerlig, hele døgnet. Med kontinuerlig mener Xxxxxx at det ikke skal være vesentlige driftsavbrudd- og/eller driftsforstyrrelser ved oppdateringer eller annen forutbestemt nedetid.	A			Bilag 2
5.6	Leverandøren skal løpende informere Xxxxxx og Xxxxxxx brukere ved uforutsette driftsforstyrrelser, inkludert når det forventes at tjenesten igjen er fullt operativ. Her skal informasjonsrutinene mot Xxxxxx og Xxxxxxx brukere ved uforutsette hendelser, deriblant ressurser og verktøy som er tilgjengelige, samt opplysninger om ansvarsfordelingen beskrives.Besvarelsen begrenses til en halv side.	M
5.7	Leverandøren skal stille med verktøy som Kunden kan melde inn sine saker. Kunden skal kunne se status på saker i henhold til avtalt tjenestenivå, type sak og prioritet.	M
5.8	Løsningens ytelse skal være så god at responstiden ikke oppleves som ventetid i de vanlige oppgaver. Ventetid skal ikke aksepteres i vanlige lese- og registreringsbilder. Leverandør bes beskrive hvordan responstiden i løsningen vil oppleves av kunden, med relevante størrelser for måling av responstid.	M			Bilag 2

6	Brukskvalitet
6.1	Det kommer klart fram at Trondheim kommune er ansvarlig for løsningen,	M
6.2	Det vektes positivt at løsningen utformes i tråd med Trondheim kommunes grafiske profil. Tilpasninger til profilen gjøres i samråd med Kommunikasjonsenheten.	A			Bilag 2
6.3	Det vektes positivt at fagsystemet er utformet slik at de ansattes arbeidsoppgaver kan utføres på en brukervennlig måte, inkludert på mobile løsninger.	A			Bilag 2
6.4	Det vektes positiv at fagsystemet er utformet i henhold til forskrift om universell utforming av IKT-løsninger. Det vil blant bli lagt vekt på følgende: - I hvilken grad Leverandøren har metodikk for å ivareta universell utforming i sin utvikling, videreutvikling og forvaltning av fagsystemet, som tilfredsstiller WCAG 2.0. - Hvordan, og i hvilken grad, fagsystemet ivaretar de fremhevede kravene i forskriften fra WCAG 2.0-standarden - I hvilken grad Leverandøren viser avveiinger i sine beslutninger om å ikke dekke ivareta spesifikke krav i WCAG 2.0. - Hvordan, og i hvilken grad, Leverandøren har metodikk og planer for å ivareta den varslede skjerpingen av krav til universell utforming Gru som gjelder fra 1. januar 2021, som følge av EU sitt webdirektiv om universell utforming av nettsteder og mobilapplikasjoner (WAD og WCAG 2.1). Merk at nivå AAA (trippel A) ikke blir en del av det norske regelverket.	A			Bilag 2