Bilag til

Utviklings- og tilpasningsavtalen for GIS GIS T Bilag 1 - Kundens kravspesifikasjon

Avtalepart	Avtalen gjelder foretak	Saksarkivnummer	Avtalenummer
Helse Vest IKT AS	X
Helse Nord RHF	X	xxxx/xxxx	XXXXX
Helse Midt-Norge RHF	X
Helse Sør-Øst RHF	X

Kunde	Leverandør
Fyll inn logo	Fyll inn logo
Fylles inn	Fylles inn
Administrerende direktør	Administrerende direktør

Innholdsfortegnelse

INNHOLDSFORTEGNELSE

29

1 Innledning

Dette er GIS T Bilag 1 - Kundens kravspesifikasjon til AMK IKT-delområde 2: GIS-løsning. AMK IKT anskaffelsen legger til grunn to delanskaffelser, AMK-løsning og GIS-løsning.

AMK-løsningen (delområde 1) er et komplett hendelses- og oppdragshåndteringsverktøy. Løsningen skal kunne fungere selvstendig, samt at den inneholder og bearbeider all relevant informasjon.

Hovedoppgaven til AMK-operatøren er å

• besvare medisinsk nødtelefon 113, innhente og registrere informasjon, og beslutte kriterium med tilhørende hastegrad og respons

• alarmere og koordinere ressurser i medisinske nødsituasjoner

• formidle eller varsle i situasjoner med lavere grad av hast

• gi råd eller instruksjon, i hovedsak i påvente av at annen hjelp kommer fram

• planlegge og koordinere ambulansetransport

AMK-løsningen utgjør brukerflaten (GUI) for operatør, og all funksjonalitet for hendelses- og oppdragshåndteringen tilgjengeliggjøres i denne løsningen. For å øke funksjonaliteten i AMK-løsningen kommuniserer serveren med en nasjonal GIS-løsning via et definert grensesnitt. Informasjonsflyt mellom løsningene er toveis og skal oppleves sømløst for operatør.

GIS-løsningen

Det skal leveres en nasjonal GIS-løsning for AMK- sentralene i Norge. GIS-løsningen skal installeres i serverpark hos Norsk Helsenett SF. GIS-løsningen er primærleverandør for kartdata og annen stedfestet informasjon til AMK-løsningen, men skal også kunne benyttes av andre aktører i helsetjenesten.

GIS-løsningen vil være navet i datasamling knyttet til kart, posisjonstjenester, flåtestyring, ruteoptimering, eiendomsinformasjon (matrikkeloppslag) og lignende. Posisjonsdata vises kun i sanntid. Den nasjonale GIS-serveren lagrer ingen data knyttet til pasient eller hendelse. Lagring av sensitive data som

omhandler hendelse, posisjonsdata og pasient skjer i sin helhet i AMK-løsningen. GIS-løsningen skal også kunne benyttes av andre aktører i helsetjenesten.

Dataflyt mellom løsningene

AMK- og GIS-løsningen deler informasjon i sanntid. For

at AMK-løsningen skal kunne håndtere oppdragsporteføljen effektivt, er tilgang på nødvendig informasjon i sanntid en forutsetning. Brukeropplevelsen mellom løsningene må være sømløs. En AMK operatør skal kunne peke på et objekt, slå av eller på et kartlag eller veksle mellom ulike zoom-nivå uten å oppleve forsinkelse i hendelseshåndteringsverktøyet på grunn av dataflyten mellom AMK- og GIS-løsningen.

GIS-løsningen skal kunne hente inn data fra AMK-løsningen for å gjøre beregninger, deretter skal disse kunne visualiseres i AMK-løsningen. GIS-løsningen inneholder (i tillegg til kartdata) oversikt over ressurser, demografidata, historiske hendelser (på forespørsel i AMK-løsning) og kan støtte AMK-løsningen med regnekraft.

Avklaring

Samhandling mellom valgt GIS- og AMK-leverandør, vil avklares før kontraktsinngåelse.

Redundans

GIS-løsningen skal kunne levere karttjenester til AMK-løsningen selv om koblingen mellom GIS-løsningen og eksterne kilder (internett) faller ned. AMK-løsningen skal kunne operere selv om koblingen til nasjonal GIS-løsning faller ned. Kartlag og data som benyttes i AMK-løsningen skal være lokalt lagret i AMK-løsningen for å sikre en redundans mot nasjonale GIS-serveren.

2 Formål og omfang

Formålet med avtalen er å regulere innhold og levering av GIS-løsningen. Det er kritisk for helseregionene å utnytte geografisk informasjon ved koordinering av helserelaterte hendelser. AMK IKT-prosjektet skal innføre ny GIS-løsning som en integrert del av den nye AMK-løsningen som innføres. Det er samtidig ønskelig å etablere en GIS-løsning (delområde 2) som legger grunnlaget for en trinnvis utvikling av geografisk innhold og funksjonalitet i AMK og for øvrige virksomhetsområders behov (f.eks. ambulansetjeneste / beredskapsplanlegging).

2.1 Overordnet leveranseplan

AMK IKT-prosjektet er delt i tre faser. For GIS-løsningen betyr dette:

• Fase 1 – Innføre ny GIS-løsning som har en robust teknisk plattform. Løsningen skal understøtte og gi informasjon til den nye AMK-løsningen som innføres i det samme prosjektet. GIS-løsningen skal tilby funksjonalitet som spesifisert i krav i dette dokumentet.

• Fase 2 - Innføre ny funksjonalitet for å støtte ytterligere arbeidsprosesser ved AMK-sentralene. Dette innbefatter vurdering av beredskap, dynamiske karttjenester og forbedret informasjonsdeling.

• Fase 3 - Ta i bruk innovativ funksjonalitet for ytterligere å øke kvaliteten og understøtte oppgavene til AMK-sentralene.

Se AMK T Bilag 1 - Kundens kravspesifikasjon for ytterligere detaljer.

Ved realisering og implementering av GIS-løsningen, skal følgende underpunkt være oppnådd:

Fase 1

• En robust teknisk GIS-plattform er etablert

• En robust, standardisert og fleksibel integrasjon mot ny AMK-løsning

• Skal ha oversikt over posisjon til alle AMK sine ressurser til enhver tid Ny løsning som inneholder grunnleggende geografisk kartinformasjon, for å bidra til enkel flåtestyring i ny AMK-løsning

• Robuste integrasjoner mot eksterne datakilder for innhenting av kartinformasjon

• Kartlag for oppfølging av luftambulansehelikoptre og flight following Beslutninger i Fase 1 skal ikke hindre målbildene i senere faser

Fase 2

• Det er etablert funksjonalitet for å planlegge optimal gjennomføring av transportoppdrag med hensyn på tid, ressurser, kjørelengde, etc. (f.eks. ruteplanlegging)

• Det er etablert funksjonalitet for mulighet til å gjennomføre analyser, basert på tilgjengelig informasjon

• Det er etablert funksjonalitet for å få assistanse til optimering av tjenesten, for eksempel plassering av ambulansestasjoner, standby-punkter og så videre.

Fase 3

GIS løsningen fullt implementert vil understøtte oppgavene til AMK-sentralene, men løsningen skal ikke være en statisk løsning. Løsning skal videreutvikles i takt med oppgaver, nye behov og den teknologiske utviklingen generelt. Fase 3 er derfor ikke detaljspesifisert, men kan inneholde funksjoner og verktøy som omhandler prediksjon og bruk av kunstig intelligens. Krav til fase 3 fremgår av avtalene GIS Avtale om videre leveranser og videreutvikling og GIS Vedlikeholdsavtale (Vedlikeholdbarhet over tid).

Krav til fase 3 finnes i GIS avtale for videre leveranse og utvikling (GIS A Bilag 1 - Kundens kravspesifikasjon), og inngår ikke i dette bilaget.

3 Kategorisering av krav

Kravene er kategorisert etter følgende modell:

Type	Beskrivelse
O	Obligatoriske krav som må oppfylles (Minstekrav). Manglende oppfyllelse av kravet vil medføre avvisning av tilbudet. Tilbyder skal bekrefte oppfyllelse av kravet, samt beskrive hvordan det obligatoriske kravet er oppfylt.
P	Primære krav som inngår i Oppdragsgivers evalueringsarbeid. Primære krav vil vektes høyest av kravene i evalueringen. Oppfyllelse av P-krav vil kunne verifiseres av Oppdragsgiver gjennom demo/use-cases. Tilbyder skal bekrefte om kravet er oppfylt, samt gi en utfyllende beskrivelse av oppfyllelsesgraden.
S	Sekundære krav som inngår i Oppdragsgivers evalueringsarbeid. Sekundære krav er også viktig for Oppdragsgiver men vil ha lavere vekt enn P-krav. Oppfyllelse av S-krav vil kunne verifiseres av Oppdragsgiver gjennom demo/use-cases. Tilbyder skal bekrefte om kravet er oppfylt, samt gi en utfyllende beskrivelse av oppfyllelsesgraden.

4 Krav til GIS-løsning

ID	Beskrivelse av kravet	Kategori O/P/S
GT4-1	Leverandøren bør gi en overordnet beskrivelse av hvordan tilbudt løsning imøtekommer formålet (Executive Summary). Det forventes en god overordnet beskrivelse av løsningen med de fordeler og utfordringer leverandører ser for seg ift. Kundens samlede behov. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P Kravet vektes særlig.
GT4-2	Gis-leverandøren skal legge til rette for et rollebasert brukergrensesnitt. Ulike roller med begrenset innsyn, avklares senere. Brukergrensesnittet bør støtte anerkjente retningslinjer for gode brukergrensesnitt, designmessig tiltalende, uten forstyrrende elementer. Funksjonelle krav beskrevet i fase 1 og 2, skal (hvis mulig) være tilgjengelig i løsningen, forutsatt rolle med innsyn. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4-3	Det skal etableres et programmeringsgrensesnitt (API) mellom AMK- og GIS løsningen som legger til rette for en effektiv integrasjon med et fremtidsrettet API. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4-4	API-et som benyttes bør være toveis standardisert API, tilsvarende REST, eller annet moderne og egnet grensesnitt. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4-5	Responsen fra API-et bør være i henhold til kjente internasjonale standarder og spesifikasjoner som eksempel; GML, Esri FGDB, GeoJson, JSON, eller andre moderne og egnede standarder. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4-6	GIS-løsningen skal kunne levere karttjenester til AMK-løsningen selv om koblingen mellom GIS-løsningen og eksterne kilder (internett) faller ned. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4-7	API: Data og funksjoner i løsningen skal være tilgjengelig i et API som kan brukes av flere eksterne parter. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O

4.1 Funksjonelle krav (samhandling med delområde 1 - Fase 1)

ID	Beskrivelse av kravet (Fase 1)	Kategori O/P/S
GT4.1-1	Nasjonale kart: Løsningen skal leveres med egnede bakgrunns kart, sjøkart, ortofoto, topografiske kart og tekniske kart (avtales med kunde). Det skal også kunne leveres med oppmerkede flyruter for Low Level Area Navigation Routes og inn- og utflygningskart til sykehus og til luftambulansebaser (helikopter). Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-2	Kvalitet av levert kartløsning (Ref. G1A) bør være høy. Minimum zoomnivå 1:400 i alle kart lag hvis mulig. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P Kravet vektes særlig.
GT4.1-3	Helsetjenesten utfører oppdrag i grenseområder, og i noen tilfeller over Norsk riksgrense. AMK løsningen skal derfor leveres med kart over nabolandene (Russland, Sverige og Finland). Løsningen skal leveres med bakgrunns kart, sjøkart og topografiske kart. Kvalitet av levert kartløsning (detaljgrad, o.l.) skal være egnet til formålet og kartene må dekke minimum 10 mil fra Norsk riksgrense inn i nabolandet. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-4	Henting av kartlag (med ulike zoomnivå) skal foregå med minimal forsinkelse. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-5	Løsningen bør støtte gjeldende internasjonale spesifikasjoner for utveksling av kartinformasjon, herunder OGC WMS 1.3.0, WMTS 1.1.0, WCS 1.1.0. Bruk av industry standards er tillatt. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-6	Kartlagene som benyttes av løsningen skal oppdateres minimum hver måned eller så ofte som det kommer nye versjoner. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-7	Løsningen skal kunne håndtere/administrere kart tjenester som levere raster data. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-8	Løsningen bør kunne håndtere/administrere vektordata/vektor tiles/vektorkart. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-9	Løsningen bør kunne håndtere/administrere 3D kart. Komplekse 3D objekter (multipatch) og GEO refererte punktsky. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-10	Løsningen skal benytte et oppdatert veinett for Norge. Nyutvikling/endring av veinettet skal oppdateres regelmessig, minst en gang pr uke. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O

ID	Beskrivelse av kravet (Fase 1)	Kategori O/P/S
GT4.1-11	Løsningen skal til enhver tid benytte siste tilgjengelige versjon av GEO referert demografidata og tettstedsformer utgitt av Statistisk sentralbyrå (SSB) Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-12	Løsningen skal støtte registrering og visning av midlertidige veier og innlegging av veisperringer via AMK-løsningen eller API. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-13	Løsningen skal støtte innrapportering av kartfeil til kartverket og andre ansvarlige parter. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-14	Løsningen bør ha et dynamisk symbolbibliotek som muliggjør valg av flere standardiserte symboler. Eksempelvis symboler som benyttes i Kartverket, Vegvesenet, Meteorologisk institutt, NVE med flere. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	S
GT4.1-15	Løsningen skal bruke tjenester (internt og eksternt) som følger standard digital kart kartografi prinsipper, inkludert tilpasning av kart til målestokk nivå og etikettlesbarhet. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-16	Løsningen skal støtte forskjellige datum, projiseringer og koordinatsystem, samt beregne og presentere mellom disse. AMK-løsningen benytter primært metrisk og nautisk måleenhet. Standard er primært datum (WGS 84) og projeksjon (UTM 33). Det skal være mulig å konfigurere hvilket datum, projeksjon og måleenhet som skal benyttes. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-17	Alle data skal lagres i det samme koordinatsystemet, og dette skal være konfigurerbart. EPSG:4258 skal være et alternativ. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-18	Løsningen bør kunne levere dynamiske og statiske objekter levert fra mobile enheter, andre interne datasystem, eksterne sensorer og relevante eksterne datakilder. Eksempelvis AIS. Objektene vises som et eget lag over aktuelt kart. (Hentes fra GIS- løsningen og visualiseres i AMK-løsningen.). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-19	Forhåndsdefinerte utvalg, eksempelvis ferger [filtrert utvalg] skal kunne vises live i aktuelt kartlag. Eksempelvis: Visning av fergesamband innenfor eget ansvarsområdet, uten visningen av øvrig skipstrafikk. Alle objektene skal være søkbare. (Hentes fra GIS-løsningen og visualiseres i AMK-løsningen.) Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O

ID	Beskrivelse av kravet (Fase 1)	Kategori O/P/S
GT4.1-20	Løsningen bør inneholde turstier, fjellstier og skiløyper. Datapunktene bør kunne legges over aktuelle kartlag som benyttes. Oppdateres ukentlig. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-21	Løsningen bør ha en oppdatert database av interessepunkt (POI). Disse bør kunne importeres og brukes uten ekstern nettilgang (internett). De bør kunne opprettes, redigeres og slettes av bruker (via AMK-løsningen), dette bør være rollebasert og styrt av eierskap til POI. POI-ene bør være søkbare med prioritering basert på kontekst. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-22	Løsningen bør kunne importere, hente inn/synkronisere og bruke dataobjekter fra relevante eksterne datakilder. Hvilke dataobjekter som brukes skal være konfigurerbart. POI-ene bør være søkbare med prioritering basert på kontekst. Eksempel: Forhåndsdefinerte landingsplasser for luftambulanse- og redningshelikoptre (LZ-North), oppmerkede hinder (luftspenn og master), hjertestarterregisteret, bedrifter, butikker, hoteller, bensinstasjoner, stedsnavn, fjelltopper, veikryss, skoler, flyplasser, legevakter, o.l. med navn og evt annen nyttig informasjon. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-23	Løsningen bør gi mulighet for eksport og import/synkronisering av datasett til/fra ulike standardiserte formater. Minimum: CSV, GPX, XML, GML, KMZ/KML, SOSI, Shape, Geotiff, GeoJSON, DATEX2, xls, xlsx, og lignende. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	P
GT4.1-24	Løsningen bør kunne motta og levere posisjonsdata knyttet til fartøy i sanntid. Retning, hastighet, ETA, status og aktuelt oppdrag for egne og andre ressurser. (Alle AMK sentraler skal kunne se alle ambulanser i Norge). Øvrige etaters ressurser bør kunne tilgjengeliggjøres. (Dette forutsetter tilgang over andre etaters ressurser). (Hentes fra GIS-løsningen og visualiseres i AMK-løsningen.) Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-25	Løsningen bør kunne levere retning, hastighet, status og aktuelt oppdrag for egne og andre ressurser med nødnettsambandet som GPS-formidler. (Redundans for transmobil, og eventuell posisjonsmarkering utenfor vei). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-26	Løsning skal kunne ta imot informasjon knyttet til hendelser, ressursobjekter og andre objekter fra AMK-løsningen. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O

ID	Beskrivelse av kravet (Fase 1)	Kategori O/P/S
GT4.1-27	Løsningen skal kunne tilby ruteberegning, kjøretider og ETA for ressurser. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.1-28	Løsningen bør kunne søke i objekter, søkeresultater og andre oppslag. Søket bør kunne avgrenses på ulike attributter, tid, nærhet og geofence. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.1-29	Løsningen bør ha funksjonalitet for å hente inn radiodekning/dekningskart til nødnett (bakke og luft). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	S
GT4.1-30	Løsningen bør ha funksjonalitet for å hente inn GEO-sperre knyttet til ulike talegruppe i nødnett. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	S

4.2 Funksjonelle krav (samhandling med delområde 1 - Fase 2)

Beskrivelse av kravet (Fase 2)

Kategori O/P/S

GT4.2-1

Løsningen bør kunne foreslå beredskapsforflytning av ledige ressurser for å oppnå maksimal dekning av populasjonen innenfor et geografisk avgrenset område (regelsett). Løsningen bør ta hensyn til demografidata, historiske helsehendelser og til enhver tid gjeldende responstidsanbefalinger for helsetjenesten.

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

Kravet vektes særlig.

GT4.2-2

Løsningen bør kunne benyttes til ruteplanlegging (transportplanlegging).

Alle oppdrag (grønne/gule) bør kunne inngå i kjøreplanen og løsningen bør innfri alle leverings og hentefrister (så nært optimum som mulig) med utgangspunkt i en begrenset ambulanseflåte. Akuttberedskapen for området bør være adekvat/intakt [Regelsett].

Rekalkulering bør utføres fortløpende uten at bruker opplever forsinkelser. Kartmotor for ruteplanlegging, skal nyttiggjøre trafikkinformasjon, historikk og sanntidsdata.

Noen vesentlige problemstillinger som bør tas hensyn til er; tid, hastegrad, hentested/leveringssted, tilgjengelig ressurser, ambulansens transportkapasitet (1 eller 2 pasienter), aktiv / passiv vakt (økonomi), veistandarder, veinett hastighet, kø- problematikk og kompetanse (transport-, akutt-, eller intensivambulanse).

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

Kravet vektes særlig.

ID	Beskrivelse av kravet (Fase 2)	Kategori O/P/S
GT4.2-3	Løsningen bør kunne tilby funksjonalitet for deling av informasjon og objektet tilknyttet en hendelse med fremtidige eksterne systemer (mobile) i sanntid. Løsningen må være toveis. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2-4	Løsningen bør støtte mottak av datakorreksjoner, manuell innlegging av midlertidige veier og veisperringer registrert av AMK-løsningen, eller mobile enheter (helseressurser). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2-5	Løsningen bør støtte fjernåpning av bommer. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2-6	Løsningen bør kunne innhente sanntidsdata fra ulike kilder som viser trafikkinfo, trafikale belastninger og statusmeldinger i sanntid. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2-7	Løsningen bør kunne tilby funksjonalitet for deling av data mellom operasjonssentraler og andre aktuelle enheter/ledelsesapparat. Deling av POI, kartutsnitt, søksområde, HELSE ressurser bør kunne gjøres i sanntid med øvrige nødetater. (Kravet innebærer at deling av informasjon gjøres i GIS-løsningen, mens visningen gjennomføres i AMK-løsningen.) Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P Kravet vektes særlig.
GT4.2-8	Løsningen skal understøtte at Kunden kan utføre strategiske GIS-analyser med utgangspunkt i datagrunnlaget som genereres i AMK-løsningen. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT4.2-9	Analyser som bør være tilgjengelig for bruker innbefatter, men er ikke begrenset til: • Heatmap/ hotspot (Hvor historisk er det flest ambulanseoppdrag?) • Responstidsanalyser (Hva er utrykningstiden til aktuelt oppdrag?) • Lufthindringer (Støtteinformasjon/LA) • Frisiktanalyse fra punkt, linje, polygon (hva ser vi fra området?) • Visualisering av historiske utrykningstider • Nærhetsanalyse (hva finnes av interessepunkter innenfor en gitt radius) • Hot zone, warm zone, cold zone? (Bufferanalyser med forhåndsdefinerte avstander, skal også kunne deles til utrykkende ressurser). • Knutepunktsanalyse (hvor er trafikknutepunkter i området rundt hendelsessted) Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 10	Løsningen bør tilgjengeliggjøre informasjon om skadested/POI i gateperspektiv (tilsvarende «Street view»), som presenteres for operatør i AMK-løsningen. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P

ID	Beskrivelse av kravet (Fase 2)	Kategori O/P/S
GT4.2- 11	Løsningen bør kunne presentere dynamiske og statiske objekter levert fra mobile enheter, andre interne datasystem, eksterne sensorer og relevante eksterne datakilder. Eksempelvis satellitt overvåkning av fly/helikopter, ADS-B, Bane Nor, bølgehøyde, værdata, vannføring (flom), mm. Kravet forutsetter at resultatene kan presenteres i AMK-løsningen, som et eget lag over aktuelt kart. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 12	Løsningen bør kunne støtte geofence med ulike geometriske former. Aktuelt geofence skal kunne være tidsavgrenset, og skal kunne gi notifikasjon til ressurser/enheter i berørt område. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 13	Løsningen bør kunne bruke værdata og produsere et eget kartlag med justerbar gjennomsiktighet. Værkartet skal kunne legges over øvrige kartlag (målestokkriktig). Eksempelvis værdata legges over et kart som viser skadestedet, hvor vindpiler, temperatur og øvrig informasjon fremkommer godt synlig. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 14	Løsningen bør kunne innhente og presentere sanntidsdata fra ulike kilder som viser trafikkinfo, trafikale belastninger og statusmeldinger i sanntid. (Eksempelvis: veiarbeid, redusert fremkommelighet, kø problematikk). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 15	Veisperringer og midlertidige veier bør hensyntas av GIS-løsningens øvrige funksjoner, eksempelvis ruteplanlegging. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 16	Løsningen bør kunne angi raskeste kjørerute for ressursene som hensyntar «kø» problematikk og stengte veier. Den valgte kjøreruten for hver ressurs bør kunne oversendes og vises i mobile enheter. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 17	Løsningen bør blant annet muliggjøre innhenting av: • Matrikkeluttrekk (Hvem eier her?) • Uttrekk fra Folkeregister (Hvem bor her?) • Liste over adresser i et gitt område • Liste over utvalgte typer objekter i området Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT4.2- 18	Løsningen bør ha funksjoner for visning over veitrafikk-kamera, HemsWX (luftambulanse) og andre offentlige tilgjengelige kamerakilder. Kameraoversikten bør kunne presenteres i kart og bør kunne tilgjengeliggjøre link til livestream eventuelt bilde fra ekstern kilde. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P

Beskrivelse av kravet (Fase 2)

Kategori O/P/S

GT4.2- 19

Løsningen bør ha funksjonalitet som unngår duplikat av import fra eksterne/interne kilder. Eks. Import av turstier fra to kilder, hvor begge kildene leverer samme vektordata. Felles attributt bør benyttes som ID. Risiko for fjerning av feilaktige kartopplysninger må minimaliseres.

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

GT4.2- 20

Løsningen bør ha funksjonalitet for å hente inn radiodekning/dekningskart til nødnett (bakke og luft) i sanntid.

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

5 Tekniske forhold

Funksjonelle behovsbeskrivelser i kapittel 4 ivaretar brukerperspektivet. De tekniske kravene forholder seg til bakenforliggende områder som må fungere for å gi sluttbrukeren en god systemløsning som støtter arbeidsprosessene.

Beskrivelse av Kundes eksisterende tekniske miljø fremkommer av GIS T Bilag 3 - Kundens tekniske plattform.

5.1 Tekniske krav

Disse kravene beskriver hvordan tekniske komponenter og infrastruktur ønskes innrettet.

Kravene må sees i sammenheng med Kundens eksisterende tekniske miljø, som fremkommer i GIS T Bilag 3 - Kundens tekniske plattform.

ID	Beskrivelse av kravet	Kategori O/P/S
GT5.1- 1	Leverandøren skal, som en del av leveransen, fremlegge detaljerte beskrivelser av teknisk løsningsdesign som på en tydelig og oversiktlig måte viser de relevante hovedkomponenter, dataflyt og kommunikasjonsgrensesnitt for løsningen slik den foreslås etablert. Vennligst bekreft at kravet oppfylles.	O
GT5.1- 2	Leverandøren bør fremlegge beskrivelser av teknisk løsningsdesign som på en tydelig og oversiktlig måte viser de relevante hovedkomponenter, dataflyt og kommunikasjonsgrensesnitt for løsningen slik den foreslås etablert. Vennligst beskriv hvordan kravet oppfylles. Kravet vektes særlig.	P
GT5.1- 3	Løsningen skal ha et design som sørger for at komponenter og programvare har hensiktsmessig feiltoleranse og redundans for feil som kan oppstå i løsningens komponenter eller nettverkskommunikasjon. Vennligst bekreft at kravet oppfylles.	O
GT5.1- 4	Leverandøren bes beskrive hvordan komponenter og programvare har hensiktsmessig feiltoleranse og redundans for feil som kan oppstå i løsningens komponenter eller	P

Beskrivelse av kravet

Kategori O/P/S

nettverkskommunikasjon ivaretas.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 5

Løsningen skal ha et design som sørger for at hensiktsmessig ytelse i komponenter og programvare kan skalere i takt med endringer i mengde brukere, last og tilleggsfunksjonalitet.

Vennligst bekreft at kravet oppfylles.

GT5.1- 6

Leverandøren bes beskrive hvordan designet sørger for at ytelse i komponenter og programvare kan skalere i takt med endringer i mengde brukere, last og tilleggsfunksjonalitet ivaretas.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 7

Løsningen skal ha et system som opprettholder god integritet for data i løsningen. Systemet skal prosessere, lagre og transportere slike data slik at informasjonen beskyttes mot uautorisert innsyn.

Systemet skal også lagre sporingsinformasjon som viser hvem som har opprettet, aksessert, endret eller slettet slike data.

Vennligst bekreft at kravet oppfylles.

GT5.1- 8

Leverandøren bes beskrive hvordan løsningen opprettholder god integritet for data i løsningen, hvordan systemet prosesserer, lagrer og transporterer data slik at informasjonen beskyttes mot uautorisert innsyn. Leverandøren bes også beskrive hvordan løsningen lagrer sporingsinformasjon som viser hvem som har opprettet, aksessert, endret eller slettet slike data.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 9

Med henvisning til beskrivelser i GIS T Bilag 3 - Kundens tekniske plattform, bør Leverandøren etablere løsningen med bruk av Kundens eksisterende klientmaskinvare og operativsystem.

Kundens Windows operativsystem har typisk installert anti-malware.

Beskriv hvordan løsningen bruker Kundens eksisterende klientmaskinvare og operativsystem.

Beskriv også eventuelle behov for annen klientfunksjonalitet i løsningen.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 10

Med henvisning til beskrivelser i GIS T Bilag 3 - Kundens tekniske plattform, bør Leverandøren etablere løsningen med bruk av Kundens eksisterende server maskinvare og operativsystem.

Server maskinvare er fortrinnsvis virtuell. Kundens Windows operativsystem har typisk installert anti-malware.

Beskriv hvordan løsningen bruker Kundens eksisterende server maskinvare og operativsystem.

Beskriv også eventuelle behov for annen serverfunksjonalitet i løsningen.

Beskrivelse av kravet

Kategori O/P/S

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 11

Med henvisning til beskrivelser i GIS T Bilag 3 - Kundens tekniske plattform, bør Leverandøren etablere løsningen med bruk av Kundens eksisterende verktøy for utrulling av programvare (deploy) til klienter og servere.

Beskriv hvordan løsningen bruker Kundens eksisterende utrullingsverktøy for programvare. Beskriv og begrunn eventuelle behov for annet utrullingsverktøy i løsningen.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 12

Med henvisning til beskrivelser i GIS T Bilag 3 - Kundens tekniske plattform, bør Leverandøren etablere løsningen med bruk av Kundens eksisterende databaser. Beskriv hvordan løsningen bruker Kundens eksisterende databaser.

Beskriv også eventuelle behov for annen databasefunksjonalitet i løsningen.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 13

Med henvisning til beskrivelser i GIS T Bilag 3 - Kundens tekniske plattform, bør Leverandøren etablere løsningen med bruk av Kundens eksisterende lagringsløsninger. Beskriv hvordan løsningen bruker Kundens eksisterende lagringsfunksjonalitet.

Beskriv også eventuelle behov for annen lagringsfunksjonalitet i løsningen.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 14

Med henvisning til beskrivelser i GIS T Bilag 3 - Kundens tekniske plattform, bør Leverandøren etablere løsningen med bruk av Kundens eksisterende nettverk og nettverksfunksjoner.

Beskriv hvordan løsningen bruker Kundens eksisterende nettverk og nettverksfunksjoner. Beskriv også eventuelle behov for annen nettverksfunksjonalitet i løsningen.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 15

Løsningen bør ha et system som sørger for at komponenter og programvare i løsningen får god monitorering med hensyn til proaktiv detektering av feil.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 16

Med henvisning til beskrivelser i GIS T Bilag 3 - Kundens tekniske plattform, bør Leverandøren etablere løsningen med integrasjon mot Kundens eksisterende overvåkningssystem.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 17

Med henvisning til beskrivelser i GIS T Bilag 5 - Testing og godkjenning, skal Leverandøren etablere løsningen i tråd med Kundens regime for testing.

Vennligst bekreft at kravet oppfylles.

GT5.1- 18

Med henvisning til beskrivelser i GIS T Bilag 5 - Testing og godkjenning, skal Leverandøren beskrive hvordan foreslått løsning er i tråd med Kundens regime for testing.

Vennligst bekreft at og beskriv hvordan kravet oppfylles.

Beskrivelse av kravet

Kategori O/P/S

(Beskrives i GIS T Bilag 5 under kapittel «Leverandørens beskrivelse av testgjennomføring»)

GT5.1- 19

Løsningen bør ha et system som sørger for at komponenter og programvare i løsningen får god support.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 20

Løsningen bør ha et system som sørger for at komponenter og programvare i løsningen får god sikkerhet.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 21

Løsningen bør ha et system som sørger for at komponenter og programvare i løsningen får god dokumentasjon.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 22

Løsningen bør ha et design som sørger for at komponenter og programvare i løsningen får god gjenopprettingsmulighet ved fysisk og logisk feil.

Dette løses vanligvis gjennom et gjennomtenkt regime for (re)oppretting av tjenester, backup og restore.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 23

Løsningen bør ha et system som sørger for at relevante komponenter og programvare i løsningen har felles klokkesynkronisering.

Løsningen bør også automatisk håndtere overgang mellom sommer- og vintertid.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 24

Løsningen bør ha et system som kan innrette seg til driftsrelaterte ITIL prosesser. Typisk er dette produksjonssetting (Release), endring (Change) og hendelser (Incident).

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 25

Løsningen bør ha et design som sørger for at komponenter og programvare i løsningen kan kommunisere hensiktsmessig på tvers av subnett og brannmurer.

Leverandøren bes beskrive løsningens behov for brannmuråpninger mellom løsningskomponentene, samt støtte for TCP keep-alive.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 26

Løsningen bør ikke være avhengig av spesifikk nettleser eller benytte nettleserplugins som Flash, Silverlight eller Java.

Beskriv eventuelle avvik fra dette.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 27

Krav til brukerkontoer.

- Løsningens brukerkontoer bør ikke være lokale, det bør benyttes domenebrukere eller servicebrukere.

- Løsningens brukerkontoer bør ikke kreve mer enn normal brukertilgang på servere og

Beskrivelse av kravet

Kategori O/P/S

klienter.

- Løsningens brukerkontoer bør være unike per bruker (ikke bruk av felles brukerkonto)

- Løsningens brukerkontoer bør ikke ha løsningsspesifikke brukernavn.

- Løsningens brukerkontoer bør ikke ha løsningsspesifikke passord.

- Løsningens brukerkontoer bør støtte periodisk bytte av passord.

Leverandøren bes bekrefte støtte for dette og eventuelt beskrive og begrunne eventuelle behov for avvik fra dette i løsningen.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 28

Inndata i løsningen bør håndtere relevante tegnsett, typisk skandinaviske og samisk tegnsett. Dette gjelder både gjennom brukergrensesnitt og integrasjoner.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 29

Løsningen bør ha gjennomgående og konsekvent bruk av format for tid/dato og koordinater (posisjonsdata). Dette gjelder både utveksling, logging og lagring av slike data.

Dersom Leverandøren tilbyr både GIS og AMK løsning, gjelder dette på tvers av de to del- leveransene.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 30

Data i løsningen bør kunne eksporteres, der sensitive data bør kunne anonymiseres.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 31

Loggdata i løsningen bør kunne klassifisere loggdata med hensyn til innholdets sensitivitet, samt regulere tilgang til logger med sensitivt innhold.

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 32

Loggdata i løsningen bør kunne eksporteres til sentrale loggservere i Kundens infrastruktur (til bruk i sentralisert logganalyse).

Vennligst beskriv hvordan kravet oppfylles.

GT5.1- 33

Leverandøren skal ikke knytte andre kunder eller kundeløsninger inn i løsningen uten samtykke. Leverandøren skal heller ikke anvende Kundens data til andre formål uten samtykke.

Vennligst bekreft at kravet oppfylles.

GT5.1- 34

Kryptering av trafikk over https bør benytte TLS v1.2 eller høyere, eksempelvis ved bruk av webserver for webapplikasjon eller webservices for integrasjonsformål.

Vennligst beskriv hvordan kravet oppfylles.

6 Generelle krav til personvern og informasjonssikkerhet

Kravene under dette kapittelet er tilnærmet identiske for delområde 1: AMK-løsning og delområde 2: GIS-løsning. Samhandling mellom delområdene vil avgjøre hvilke av de underliggende kravene som også må dekkes av den tilbudte GIS-løsningen. I den grad person- og helseopplysninger blir behandlet i GIS-løsningen, vil lover og regler som beskrevet under i kapittel 6.1 med etterfølgende krav i kapittel 6.2, gjelde for GIS-løsningen fullt ut.

6.1 Lover og regler som må etterleves

Bakgrunnen for AMK IKT prosjektet var opprinnelig rapporten til Helsedirektoratet fra 2012 «Læring for bedre beredskap – helseinnsatsen etter terrorhendelsene 22. juli 2011», på oppdrag fra Helse og omsorgsdepartementet. Rapporten beskriver behovet for «å få på plass robuste løsninger som sikrer at alle AMK-sentraler henger sammen i ett og samme system som sikrer kontinuitet og kapasitet, slik at sentralen kan avlaste hverandre og ta over for hverandre.»

Den konkrete anbefalingen var at «De regionale helseforetakene må sikre at det etableres systemer som gjør det mulig å holde oversikt over ambulanse- og luftambulanseressurser på tvers av AMK, foretaks- og regionale nivå. AMK- sentralene bør også kunne avlaste hverandre og utnytte hverandres kompetanse og kapasitet, og at det innføres et enhetlig nasjonalt system for triagering av pasienter.»

Dagens IT-systemer ved AMK sentralene, henger ikke sammen i et landsdekkende nett. Dette er til hinder for effektivt samarbeid mellom sentralene, kontinuitet, og rasjonell ressursutnyttelse i helseforetakenes prehospitale virksomhet.

NOU 2015:17 (Først og fremst — Et helhetlig system for håndtering av akutte sykdommer og skader utenfor sykehus) (xxxxx://xxx.xxxxxxxxxxx.xx/xx/xxxxxxxxxx/xxx-0000-00/xx0000000/xxx00) peker på en rekke forhold som understreker behovet for ny teknologi for AMK- og LV-sentraler. Utredningen peker på at befolkningen søker hjelp gjennom andre kanaler enn telefoni, at smarttelefoner innebærer grunnleggende endringer, og at det er mangel på teknologisk støtte for samhandling, logistikkverktøy og beslutningsstøtte. Utredningen forutsetter at dette endres gjennom det prosjektet som ble stanset juni 2017.

Akuttmedisinforskriften1 § 1 2.ledd “Formål” definerer at den skal “bidra til at utstyr som inngår i helse- og omsorgstjenestens kommunikasjonsberedskap fungerer i et landsdekkende nett og sikrer prioritert informasjonsflyt både innenfor og mellom medisinske institusjoner, til mobile enheter og til samarbeidende etater.”

I revisjon av Akuttmedisinforskriften (2015) er det kommet inn nye fokusområder. Det er et mål for prosjektet å etablere systemstøtte i AMK sentralene som bidrar til å innfri krav som ikke innfris med eksisterende teknologiske plattform og løsninger for sentralene. Dette gjelder spesielt:

• § 4 “Samhandling og samarbeid mellom virksomheter som yter akuttmedisinske tjenester”: Det forutsettes i forskriften av kommuner og helseforetak skal «sikre hensiktsmessig og koordinert innsats i de ulike tjenestene i den akuttmedisinske kjeden, og sørge for at innholdet i disse tjenestene er samordnet med de øvrige

nødetatene, hovedredningssentralene og andre myndigheter.”

• § 14 “Medisinsk nødmeldetjeneste” stiller krav til samordning mellom «den kommunale legevaktordningen, legevaktsentralene, brannvesen, politi, hovedredningssentralene og andre samarbeidspartnere».

AMK sentralene mangler full systemstøtte for kunne utføre denne koordineringen og samhandlingen Dette svekker mulighet for effektive arbeidsprosesser, samhandling, tåleevne, og sikkerhetsmarginer og gjør arbeidet i AMK-sentraler uakseptabelt arbeidskrevende og kognitivt belastende for operatørene.

• § 10 “Ambulansetjenesten” stiller krav om at de regionale helseforetakene har «beredskap for å kunne dekke behovet for ambulansetjenester ved større ulykker og kriser innenfor egen helseregion og på tvers av region- og landegrensene, og at bil-, båt og luftambulansetjenesten i nødvendig grad er samordnet nasjonalt.” Videre (§

1 Forskrift 20. mars 2015 nr. 231 om krav til og organisering av kommunal legevaktordning, ambulansetjeneste, medisinsk nødmeldetjeneste m.v. (omtalt over som Akuttmedisinforskriften), xxxxx://xxx.xxxxxxxxxxx.xx/xx/xxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxx/xx0000000/

15) at «AMK-sentralene skal «ha et system for å holde oversikt over den akuttmedisinske beredskapen i og

utenfor eget ansvarsområde”.

Det mangler systemstøtte for å koordinere og holde oversikt over ambulanseressurser på tvers av helseforetak, og det er ingen tilpasset systemstøtte for å samordne nasjonalt. AMK-sentralene har mangelfull oversikt utenfor eget område.

• § 15 stiller krav til svartider. AMK-sentralene innfris i hovedsak kravene (90 % innen 10 sek), men er sårbare ved større hendelser.

• § 17 “Kommunikasjonsberedskap” stiller krav om at personell i vakt er «umiddelbar tilgjengelig i et felles, lukket, enhetlig og landsdekkende kommunikasjonsnett for helsetjenesten, jf. § 4, og kan kommunisere med hverandre og med andre nødetater.”

For tale en-til-en og i talegrupper er dette ivaretatt gjennom Nødnett. Funksjonalitet for deling av sanntids strukturert hendelsesinformasjon inkludert geografisk informasjon er begrenset til den enkelte sentrales område.

Øvrig relevant lovverk tilbudt løsning må understøtte og ivareta:

• Lov om behandling av helseopplysninger ved ytelse av helsehjelp (pasientjournalloven), xxxxx://xxxxxxx.xx/xxxxxxxx/XX/xxx/0000-00-00-00

• Forskrift om pasientjournal, FOR-2019-03-01-168, xxxxx://xxxxxxx.xx/xxxxxxxx/XX/xxxxxxxxx/0000-00-00-000

• Forskrift om IKT-standarder i helse- og omsorgstjenesten, xxxxx://xxxxxxx.xx/xxxxxxxx/XXX/xxxxxxxxx/0000-00- 01-853

• Lov om pasient- og brukerrettigheter (pasient- og brukerrettighetsloven), xxxxx://xxxxxxx.xx/xxxxxxxx/XX/xxx/0000-00-00-00

• Lov om helsepersonell mv. (helsepersonelloven), xxxxx://xxxxxxx.xx/xxxxxxxx/XX/xxx/0000-00-00-00

• Lov om behandling av personopplysninger (personopplysningsloven), xxxxx://xxxxxxx.xx/xxx/#xxxxxxxx/XX/xxx/0000-00-00-00 . LOV-2018-06-15-38

• Personvernforordningen (GDPR, (EU) 2016/679

• Forskrift om behandling av personopplysninger (personopplysningsforskriften), FOR-2018-06-15-876, xxxxx://xxxxxxx.xx/xxxxxxxx/XX/xxxxxxxxx/0000-00-00-000

• Norm for informasjonssikkerhet og personvern i helse- og omsorgstjenesten, xxxxx://xxxxxx.xx/Xxxxxxxxx/Xxxxxx/Xxxxxxxxxxx/Xxxxxx%000.0.xxx

• Lov om helseregistre og behandling av helseopplysninger (helseregisterloven), xxxxx://xxxxxxx.xx/xxxxxxxx/XX/xxx/0000-00-00-00

• Forskrift om ledelse og kvalitetsforbedring i helse- og omsorgstjenesten, xxxxx://xxxxxxx.xx/xxxxxxxx/XXX/xxxxxxxxx/0000-00-00-0000

Beskrivelse av kravet

Kategori

O/P/S

GT6.1- 1

Leverandøren plikter å etterleve sin del av løsningen i tråd med lover og forskrifter nevnt i teksten over.

6.2 Personvern og Informasjonssikkerhet

Sikkerhetsprinsipper og –krav for ny GIS-løsning er en sammenstilling av nødvendige prinsipper og krav for å oppnå tilfredsstillende informasjonssikkerhet i infrastruktur og applikasjon. Alle krav i dette kapittelet er forankret i Norm for informasjonssikkerhet og personvern i helse og omsorgstjenesten .

6.2.1 Sikkerhetskrav - Behandling av personopplysninger

Med behandling av personopplysninger menes all registrering, prosessering, bruk og lagring som gjennomføres. Det er databehandlingsansvarlig som beslutter formålet med databehandlingen. Driftspartner for GIS-løsningen er databehandler og utfører sin del av behandlingen etter avtale med databehandlingsansvarlig.

Personopplysninger skal slettes når formålet med behandlingen er oppfylt og det ikke foreligger oppbevaringskrav i annet regelverk som har forrang i forhold til slettekravet av personopplysningsloven. Sletting involverer en fullstendig sletting av opplysninger, fra alle medier opplysningene er lagret på, inklusive sikkerhetskopier.

Behandling av personopplysninger er forankret i personvernsforordningen.

Beskrivelse av kravet

Kategori O/P/S

GT6.2.1- 1

Leverandøren som utfører databehandling på vegne av virksomheten, eller arbeid hvor innsyn i helse- og personopplysninger er jevnlig forventet å forekomme, skal signere databehandleravtale.

Vennligst bekreft at og beskriv hvordan kravet oppfylles.

GT6.2.1- 2

Leverandøren som skal behandle helse- og personopplysninger skal kunne dokumentere egen informasjonssikkerhet

Vennligst bekreft at og beskriv hvordan kravet oppfylles.

6.2.2 Sikkerhetskrav – Autentisering

Med autentisering menes som regel verifisering av en brukerkonto gjennom passord eller andre mekanismer. En digital identitet kan ha flere brukerkontoer, og tilgang til informasjonssystemer styres som hovedregel gjennom autentiseringen av en brukerkontos passord.

Pasientjournalloven § 22 angir at det skal være tilgangsstyring, logging og etterfølgende kontroll.

ID	Beskrivelse av kravet	Kategori O/P/S
GT6.2.2- 1	Sikkerhetskrav Autentisering – eksisterende autentiseringsløsninger: Løsningen skal benytte regionale autentiseringsløsninger og nasjonale fellesløsninger for autentisering, typisk regional AD og HelseID nasjonalt. Beskriv integrasjon med eksisterende autentiseringsløsninger, ref. GIS T Bilag 3 – Kundens tekniske plattform, «Autentiseringstjenester integrasjon». Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT6.2.2- 2	Sikkerhetskrav – Autentisering – SSO: Sluttbruker skal kunne arbeide i systemet på tvers av moduler uten gjentatte pålogginger. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT6.2.2- 3	Sikkerhetskrav - Autentisering Sluttbruker bør kunne benytte systemet selv om regional og/eller nasjonal autentisering ikke fungerer. Beskriv hvordan dette kan løses og hvilke funksjonsnivå dette kan gi. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT6.2.2-	Sikkerhetskrav - autentisering mot eksterne kilder:	P

GIS-løsningen bør ha mulighet til å hente informasjon fra en rekke kilder. Autentisering mot slike kilder bør støtte xxxxxxxx autentisering ved bruk av for eksempel OpenID Connect eller SAML. Beskriv eksisterende støtte for xxxxxxxx autentisering.

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

6.2.3 Sikkerhetskrav - Autorisasjon

Med autorisering menes å gi korrekte tilganger til en autentisert identitet.

Det settes en rekke krav til tilgangskontroll for journalsystemer og registre. Pasientjournalloven § 22 sier at “det skal

gjennom planlagte og systematiske tiltak sørges for tilfredsstillende informasjonssikkerhet med hensyn til

konfidensialitet, integritet og tilgjengelighet”. “Dette omfatter blant annet å sørge for tilgangsstyring, logging og

etterfølgende kontroll”.

Pasientjournalloven åpner for nye måter å organisere pasientjournaler og tilganger til slike journaler. Xxxxx endrer imidlertid ikke på kravet og forutsetningen om at det kun skal gis tilgang til opplysninger som er nødvendige og relevante for å yte helsehjelp, og rammene for helsepersonells taushetsplikt er ikke endret i forhold til den tidligere lovgivningen. Dette følger av alminnelige regler om taushetsplikt for helsepersonell, og forutsetningen er presisert i blant annet pasientjournalloven § 6, § 7 og i § 19. Dette innebærer at løsninger med felles behandlingsrettede helseregistre må kunne ivareta de grunnleggende kravene knyttet til konfidensialitet om pasientenes helseopplysninger.

ID	Beskrivelse av kravet	Kategori O/P/S
GT6.2.3- 1	Sikkerhetskrav - Autorisasjon – Roller: Tilganger skal være basert på rollestyring. Beskriv støtte for systemets bruk av roller for autorisasjon Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT6.2.3- 2	Sikkerhetskrav - Autorisasjon - Attributtbasert tilgangskontroll: Rollen og attributtene brukeren har i AMK-løsningen bør kunne avgjøre hvilken tilgang brukeren får til informasjon og funksjonalitet. Det kan også være andre tilleggsopplysninger om bruker eller kontekst som avgjør tilgang. Attributtbasert tilgangskontroll benytter kontekst i tillegg til statiske roller for beslutning om tilgang. Beskriv systemets støtte for attributtbasert tilgangskontroll (ABAC). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	S
GT6.2.3- 3	Sikkerhetskrav – Autorisasjon – Rettigheter: Rettigheter i systemet bør være konfigurerbare og kunne knyttes til roller. Beskriv systemets støtte for konfigurasjon av rettigheter. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT6.2.3- 4	Sikkerhetskrav – Autorisasjon – Beslutningsstyrt tilgangskontroll: Rollen den ansatte innehar i AMK-løsningen bør gi mulighet for den ansatte selv til å beslutte tilgang til ikke-aktive pasienter/hendelser. Beskriv systemets støtte for beslutningsstyrt tilgang. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	S
GT6.2.3- 5	Sikkerhetskrav - Autorisasjon - ekstern tilgangskontroll: Beskriv støtte for ekstern tjeneste for tilgangskontroll. Beskriv også hvilke standarder som	S

er i bruk (eksempelvis XACML).

6.2.4 Sikkerhetskrav Sporbarhet

Med sporbarhet menes å kunne bevare nødvendige detaljer knyttet til en handling. Under begrepet sporbarhet ligger også begrepet uavviselighet, som er å bekrefte at en handling eller et informasjonselement er uendret, og at det entydig kan knyttes til en bestemt digital identitet. Uavviselighet er i mange sammenhenger også omtalt som ikke- benekting. Uavviselighet benyttes også i sammenheng med autorisering og autentisering.

Pasientjournalloven § 22 angir at det skal være tilgangsstyring, logging og etterfølgende kontroll. Bruk av informasjonssystem skal dokumenteres. Dette følger av pasientjournalloven § 22, jf. personopplysningsforskriften § 2- 8 og § 2-14. Det stilles videre krav om at loggene skal kontrolleres.

Pasientjournalloven § 18 angir at “pasienten eller brukeren har rett til informasjon og innsyn i behandlingsrettede helseregistre etter pasient- og brukerrettighetsloven § 5-1, helsepersonelloven § 41 og personopplysningsloven § 18 flg. Dette omfatter også innsyn i hvem som har hatt tilgang til eller fått utlevert helseopplysninger som er knyttet til pasientens eller brukerens navn eller fødselsnummer.”

Behandlingsrettede helseregistre må derfor understøtte krav om sporbarhet på hvem som har fått tilgang til eller utlevert helseopplysninger.

ID	Beskrivelse av kravet	Kategori O/P/S
GT6.2.4- 1	Sikkerhetskrav – Logging – Generelt: Alle relevante handlinger skal logges. Relevante handlinger skal måles opp mot informasjonssystemet, men som et minimum skal følgende logges: - Alle typer innlogginger, inkl. forsøk på innlogginger - Oppretting, endring og sletting av informasjonsobjekter - Innsyn eller endring i helseopplysninger - Endringer, eller forsøk på endringer, i systemkonfigurasjonen Beskriv hvordan systemet logger handlinger. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT6.2.4- 2	Sikkerhetskrav – Logging – Tilgangsstyring: Logger skal tilgangsstyres slik at de beskyttes mot manipulering/endring. Beskriv systemets støtte for tilgangsstyring av logger. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT6.2.4- 3	Sikkerhetskrav – Logging – Aktiviteter: All definert aktivitet i behandlingsrettede helseregistre skal loggføres, men ikke være begrenset til følgende funksjoner/aktiviteter: a) pålogging b) utlogging c) åpning av journal d) lesing i journal e) skriving i journal	O

	f) «sletting» av journal g) sperring av journal h) fletting i) utskrift j) oppretting og endring av tilganger og rettigheter k) kopiering og sletting av brukerroller l) eksport av datasett m) søk som er gjort Det skal være mulig å konfigurere hvilke aktiviteter systemet logger. Beskriv systemets logging av aktiviteter. Vennligst bekreft at og beskriv hvordan kravet oppfylles.
GT6.2.4- 4	Sikkerhetskrav – Logging – Informasjon: Følgende informasjon skal minimum lagres ved tilgang og aktivitet i et behandlingsrettet helseregister: a. Bruker, og hvilken av brukerens roller som var aktiv, som har forsøkt utført eller gjennomført tilgang/enhver form for aktivitet b. Dataelement endret c. Om dataelement endret er opprettet, lest, endret, skrevet ut, slettet eller annen aktivitet som det er mulig for autoriserte brukere å gjennomføre d. Tidspunkt for gjennomføring/hendelsen e. Angivelse av organisatorisk enhet hvor aktivitet/uautorisert tilgang er forsøkt utført og evt. Gjennomført Det skal være mulig å konfigurere hvilke informasjonselementer systemet logger. Beskriv hvilke informasjonselementer systemet logger eller. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT6.2.4- 5	Sikkerhetskrav – Logging – Eksport: Løsningen bør ha mulighet for manuelt og automatisert å hente ut loggdata fra AMK- løsningen. Beskriv støtte for eksport av loggdata fra systemet. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	S
GT6.2.4- 6	Sikkerhetskrav – Logging – Integrasjoner: Løsningen bør ha mulighet for at tilgang og bruk fra eksterne systemer som er integrert med AMK-løsningen kan logges. Beskriv systemets håndtering logg for integrasjoner. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT6.2.4- 7	Sikkerhetskrav – Logging – Kommunikasjon: All kommunikasjon mellom brukere/kontaktpersoner uavhengig av kommunikasjonsmedium bør lagres og tidspunkt for kommunikasjonen bør kunne logges. Beskriv systemets støtte for lagring og logging av kommunikasjon. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P

7 Krav til arkitektur

Arkitekturprinsippene er kortfattede og konsise regler som skal bidra til at spesialisthelsetjenesten utvikles i tråd med dens visjoner, mål og strategier. Lover, forskrifter, regler, teknologiske muligheter og utviklingstrekk er også med på å sette rammer for, og forme, virksomhetsarkitekturen.

Arkitekturprinsippene gjelder for alle domener av virksomhetsarkitekturen: forretning, informasjon, applikasjon og teknologi.

Prinsippene gjelder alle prosjekter og aktiviteter som involverer IKT i spesialisthelsetjenesten.

I Vedlegg 1.1 er arkitekturprinsippene gjengitt. Her finnes også en utdyping av bakgrunnen for, og hensikten med, prinsippene.

For noen av arkitekturprinsippene har vi tydeliggjort elementer av stor viktighet for nye løsninger til AMK (leveransene/kontraktene «AMK» og «GIS»), og utdypet hvordan prinsippet kan etterleves. Det er viktig å understreke at hele prinsippet er gyldig, selv om gitte føringer er fremhevet og illustrert.

Det er også verdt å merke seg at arkitekturprinsippene adresserer løsningen og innføringen som helhet, det vil si leveranser fra valgt(e) tilbyder(e) i samvirke med leveranser fra «kunde» (helseregionene, HDO, Norsk Helsenett, og så videre).

Beskrivelse av kravet

Kategori O/P/S

GT7- 1

Tilbydere bes beskrive hvordan deres løsning samsvarer med arkitekturprisnippene gjengitt i Vedlegg 1.1.

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

7.1 Krav til applikasjonsarkitekturen

ID	Beskrivelse av kravet	Kategori O/P/S
GT7.1- 1	Løsningen bør kunne skalere både for å kunne håndtere en økt mengde oppdrag (kapasitet, hastighet, lagring, etc) og en økt mengde brukere (mulighet for utvidelse, legge til HW, etc). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT7.1- 2	Løsningen bør være modulær og lagdelt. Tilbyder bør levere en oversikt over og beskrivelse av modulene og lagene i løsningen. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT7.1- 3	Grensesnittene mellom modulene bør være basert på tjenesteorientert arkitektur. Tilbyder bør levere oversikt og beskrivelse av tjenestelagene mellom modulene. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT7.1- 4	Grensesnittene mellom modulene bør være standardiserte (vedtatte og godkjente standarder, industristandarder eller de-facto standarder). Tilbyder bør levere oversikt over støttede standarder inkl. standarder som er planlagte implementert innen 12 måneder. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P

ID	Beskrivelse av kravet	Kategori O/P/S
GT7.1- 5	Eksterne grensesnitt bør være standardiserte (vedtatte og godkjente standarder eller industristandarder). Tilbyder bør levere oversikt over støttede standarder inkl standarder som er planlagte implementert innen 12 måneder. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT7.1- 6	Tilbyder skal beskrive anbefalt og mulige integrasjoner og samhandling mellom AMK- (CAD) og GIS-løsning. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT7.1- 7	Tilbyder bes beskrive hvordan løsningen håndterer feil (exception strategy) og hvordan brukeren blir skjermet fra disse, evt informert om disse.	P
GT7.1- 8	Brukeren bør kunne velge språk i sin profil og dette valg skal gjelde til det gjøres et nytt valg. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	S
GT7.1- 9	Løsningen bør inneholde funksjonalitet for brukerhjelp (tilsvarende F1, hints, etc). Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P

7.2 Krav til informasjonsarkitekturen

ID	Beskrivelse av kravet	Kategori O/P/S
GT7.2- 1	Tilbyder skal levere en (normalisert) informasjonsmodell som løsningen bygger på. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT7.2- 2	Løsningen bør kunne hente inn «masterdata» fra forskjellige kilder. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT7.2- 3	Løsningen skal kunne bruke etablert kodeverk, definert av Kunden. Vennligst bekreft at og beskriv hvordan kravet oppfylles.	O
GT7.2- 4	Løsningen bør kunne bruke vedtatte kodeverk, enten definert av Kunden (Dokumentet “Nasjonalt datasett for ambulansetjenesten ”, IS-2476, xxxxx://xxxxxxxxxxxxxxxxx.xx/xxxxxxxxxxxxx/xxxxxxxxx-xxxxxxxx-xxx-xxxxxxxxxxxxxxxxxx) eller standardiserte terminologier, for eksempel SNOMED CT, inkludert SNOMED-baserte subsett beregnet for prehospitale tjenester. Dette skal gjelde alle deler av løsningen. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P
GT7.2- 5	Løsningen bør ikke tillate direkte tilgang til data. Data bør kun kunne aksesseres gjennom tjenester - gjelder også intern tilgang. Vennligst bekreft om og beskriv hvordan kravet oppfylles.	P

Beskrivelse av kravet

Kategori O/P/S

GT7.2- 6

Løsningen bør kunne tilby tilgang til all data og informasjon i løsningen gjennom standardiserte grensesnitt (vedtatte og godkjente standarder, industristandarder eller de- facto standarder). Tilbyder bør kunne levere oversikt over støttede standarder inkludert standarder som er planlagte implementert innen 12 måneder.

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

GT7.2- 7

All data og informasjon i løsningen bør være søkbar.

Vennligst bekreft om og beskriv hvordan kravet oppfylles.

8 Krav til prosjektgjennomføring

Vi viser til GIS T Bilag 4 – Prosjekt- og fremdriftsplan, GIS T Bilag 5 – Testing og godkjenning og GIS T Bilag 6 – Administrative bestemmelser der krav til prosjektgjennomføring (fremdrift, testing og prosjektorganisering) skal besvares. I tabellen nedenfor beskrives de krav Xxxxxx stiller til Leverandøren.

8.1 Prosjektgjennomføring

ID	Beskrivelse av kravet	Kategori O/P/S
GT8.1- 1	Leverandøren bes foreslå en realistisk og hensiktsmessig organisering for alle faser i prosjektet: • Forberedelsesfasen • Spesifiseringsfasen • Utviklingsfasen • Akseptansetestfasen • Idriftsettelse og godkjenningsperiode Dette med basis i fremdriftsplan definert i GIS T Bilag 4 - Prosjekt- og fremdriftsplan for etableringsfasen. Besvares i GIS T Bilag 6 - Administrative bestemmelser.	P
GT8.1- 2	Alle felles prosjektaktiviteter/møter mellom Kunde og Leverandør bør, om ikke annet er avtalt eksplisitt, foregå i Kundens lokaler. Leverandør bør derfor påregne reising til hoved lokasjonene i regionen. Besvares i GIS T Bilag 6.	S
GT8.1- 3	Kunden anvender Microsoft Lync for digital samhandling. Dette som substitutt for en del av de fysiske møtene. Leverandøren bes angi om dette støttes alt foreslår alternative løsninger for digital samhandling. Besvares i GIS T Bilag 6.	S
GT8.1- 4	Leverandøren bes beskrive hvilken kompetanse og kapasitet som Kunden må stille tilgjengelig ovenfor Leverandøren for hver av fasene (forberedelse, spesifikasjon, utvikling, akseptansetest og idriftsettelse/godkjenning). Besvares i GIS T Bilag 6.	P

ID	Beskrivelse av kravet	Kategori O/P/S
GT8.1- 5	Leverandøren bes om å navngi hvilke ressurser som vil dekke følgende nøkkelroller i leverandørens organisering: • Styringsgruppemedlem (prosjektansvarlig) • Prosjektleder • Løsningsarkitekt (ansvarlig for at alle krav er forstått, utvikling hos Leverandør og at løsningen fungerer) • Integrasjonsansvarlig (ansvarlig for integrasjoner) • Testledelse (ansvarlig for testplan, testgjennomføring) Implementeringsansvarlig (bistå i produksjonssetting, feilretting/patcher, pilot og utrulling) Besvares i GIS T Bilag 6.	P
GT8.1- 6	For alle nøkkelressursene bes det om at relevant kompetanse og erfaring dokumenteres i form av CV som vedlegges tilbudet. CV vedlegges GIS T Bilag 6.	P
GT8.1- 7	Leverandøren skal varsle Kunden senest 2 måneder før utskiftning av nøkkelpersoner. Ved utskiftning av øvrig personell er varslingsfristen 1 måned. All utskiftning skal skje til ressurs med tilsvarende eller høyere kompetanse/erfaring enn utgående ressurs. Overlapp med ny ressurs skal skje på Leverandørens regning. All utskiftning skal godkjennes av Kunden. Kundens godkjenning kan ikke nektes uten saklig grunn. Bekreftes.	O
GT8.1- 8	Kunden kan kreve at Leverandøren skifter ut ressurser grunnet manglende kompetanse, manglende erfaring eller eventuelle samarbeidsproblemer. Bekreftes.	O
GT8.1- 9	Leverandøren skal varsle Kunden senest 3 måneder før skifte2 av underleverandør. I varselet skal det redegjøres for hvilke tiltak Leverandøren iverksetter for å holde kunden skadesløs som følge av skiftet. Kunden skal innen 10 (ti) virkedager vurdere om varselet godkjennes. Kundens godkjenning kan ikke nektes uten saklig grunn. Xxxxxx Xxxxxx finner at tiltakene for å holde ham skadesløs er mangelfulle kan han be Leverandøren iverksette ytterligere tiltak for egen regning for å avhjelpe eventuelle negative konsekvenser ved skifte av underleverandør. Bekreftes.	O
GT8.1- 10	Kunden kan ved behov initiere prosjektrevisjoner for egen regning. Prosjektrevisjonene kan gjennomføres av Kunden selv, eller av nøytral tredjepart engasjert av Kunden. Prosjektrevisjonen vil ha fokus på gjennomføringen av prosjektet, ikke foreliggende resultater. Kunden vil i tillegg gjennomføre sikkerhetsrevisjoner (ROS-analyser). Kunden varsler Leverandøren senest 10 (ti) virkedager før oppstart av prosjekt- og/eller sikkerhetsrevisjoner som utføres av Kundens egne ressurser. Varslingsperioden kan forkortes i særlige tilfeller. Kunden varsler Leverandøren om valg av tredjepart senest 1 måned før oppstart av prosjekt- og/eller sikkerhetsrevisjon som utføres av tredjepart. Leverandøren skal innen 10 (ti) virkedager etter mottak av slikt varsel meddele om han motsetter seg engasjementet. Bekreftes.	S

2 Leverandøren kan ikke skifte ut underleverandører som har bidratt til å oppfylle kvalifikasjonskravene, ettersom grunnlaget for deltakelse i konkurransen da faller bort.

ID	Beskrivelse av kravet	Kategori O/P/S
GT8.1- 11	Leverandøren bes utarbeide og ajourholde den prosjektdokumentasjon som følger av Kundens prosjektmetodikk, samt utarbeide og oversende statusrapportering i samsvar med denne metodikken. Endelig omfang av prosjektdokumentasjon og hyppighet på statusrapportering avtales i planleggingsfasen. Bekreftes.	P

8.2 Opplæring

Beskrivelse av kravet

Kategori O/P/S

GT8.2- 1

Leverandør bes utarbeide en opplæringsplan og opplæringsløp for Kundens personell i GIS T Bilag 6, der Kunde selv skal lære opp sluttbrukerne. Planen skal omfatte instruktører, sluttbrukere, teknisk personell og administrativ personell. Innhold i kursene bør fremgå av besvarelsen.

GT8.2- 2

Leverandør bes oppgi om de har standardiserte e-læringskurs Kunden kan benytte i forbindelse med intern opplæring. Om tilfelle bør dette fremgå av GIS T Bilag 6.

Vennligst bekreft om og beskriv hvordan kravet oppfylles

8.3 Hjelpefunksjonalitet og brukerdokumentasjon

Beskrivelse av kravet

Kategori O/P/S

GT8.3- 1

Leverandør skal levere versjonsriktig bruker- og tekniskdokumentasjon for programvaren. Brukerdokumentasjon skal være på norsk, mens teknisk dokumentasjon kan være på norsk eller engelsk. Gjeldende brukerdokumentasjon skal vedlegges tilbudet.

Vennligst bekreft at og beskriv hvordan kravet oppfylles.

GT8.3- 2

Leverandør bes beskrive hvilken hjelpefunksjonalitet som finnes i systemet. Vennligst bekreft om og beskriv hvordan kravet oppfylles.

9 Integrasjonsoversikt

GIS T Vedlegg 1.2A viser en oversikt over ønsket integrasjoner. Behovene for integrasjon er beskrevet i de funksjonelle kravene, mens de detaljerte integrasjonsbeskrivelse ligger i GIS T Vedlegg 1.6B.

10 Ordliste (basert på Definisjonskatalogen for den akuttmedisinske kjede)

Begrep/forkortelse	Beskrivelse
ABAC	Attribute Based Access Control (attributtbasert tilgangsstyring)
AED	Hjertestarter (Automated External Defibrillator)
AEPJ	Ambulansejournal
Ambulansetransport	Transport av pasienter fra hentested til leveringssted ved hjelp av ambulanse.
Akuttmedisin	Medisinsk diagnostikk, rådgiving, behandling og/ eller overvåking ved akutt oppstått/ forverring av sykdom eller skade, blant annet akutte psykiske lidelser og rusproblemer og akutte tilstander etter vold og overgrep, der rask medisinsk hjelp kan være avgjørende for pasientens liv og helse. Kilde: Akuttmedisinforskriften 2015.
Akuttmedisinsk beredskap	Planer, utstyr og personell som skal sikre befolkningen nødvendige akuttmedisinske tjenester. Kilde: Akuttmedisinforskriften 2015.
Akuttmedisinske tjenester	Prehospitale tjenester som til enhver tid innrettet for eller i beredskap for akuttmedisinsk innsats. Kilde: Akuttmedisinforskriften 2015.
Ambulansekoordinator	(1: Definisjonskatalogen) Vakthavende helsepersonell i AMK-sentral som primært har ansvar for å koordinere ambulanseoppdrag. Se også ressurskoordinator
AMIS®	Det system AMK-sentraler benytter for hendelseshåndtering (dokumentasjon). Inneholder ikke støttesystem. Finnes moduler for akuttmottak, legevaktsentral (brukes av noen få), ambulanse (Vestfold/Telemark).
AMK /AMK-sentral	Akuttmedisinsk kommunikasjonssentral (håndterer 113-anrop)
AMK aktiveringstid	Tiden fra det ringer i AMK til enhet (ambulanse og eller lege) er varslet
AMK aksesstid	Tiden fra det ringer på 113 til AMK-operatør besvarer telefonen
AMK-LA	AMK med luftambulansekoordinering
AMK-område	Det området som AMK-sentralen mottar 113 fra og koordinerer
AMK-operatør	Felles benevnelse på AMK-sykepleier og ressurskoordinator
AMK reaksjonstid	AMK aksesstid + AMK aktiveringstid
API	Applikasjonsgrensesnitt (Application Programming Interface)

Begrep/forkortelse	Beskrivelse
Beslutningsstøtte (BS)	Beslutningsstøtte i denne sammenheng kan være statisk støtte i form av retningslinjer, algoritmer for veiledning og instruksjon, eller annen systematisert kunnskapsstøtte. Dette vil i begrenset grad være tilgjengelig under operativt stress. Med beslutningsstøtte menes kontekstsensitiv beslutningsstøtte. Dette forutsetter «forretningsregler» på grunnlag av kunnskapsstøtte og felles rutiner/prosedyrer og ressursdatabaser, knyttet opp mot kontekst i hendelseshåndteringsverktøy. I dette ligger medisinsk, operativ og taktisk beslutningsstøtte. Jfr 2.1a: Enkel medisinsk beslutningsstøtte: Medisinsk vurdering gjennomføres. Algoritme for dialog med innringer ligger til grunn for startbildet, og fungerer som prosess-støtte og sjekkliste i innhenting av informasjon om hendelse. Ett eller flere nøkkelord, evt synonymer til nøkkelord, aktualiserer og sannsynliggjør ett eller flere oppslag/kriterier. Output: Besluttet kriterium/hastegrad. 2.1b: Avansert medisinsk beslutningsstøtte: Flere datakilder utnyttes for å styrke grunnlag for medisinsk beslutning. Medisinsk beslutningsstøtte utvikles til å være kontekstsensitiv (kilde bl.a. EPJ, tid/sted/situasjon). Nøkkelord/kriterier utvikles på grunnlag av analyse av pro/retrospektive aggregerte pasientforløp. Maskinlæring (AI) utnyttes. (se f eks xxxxx://xxx.xxxxxxxx.xxx/0000/0/00/00000000/xx-xxxxxxx-xxxxxx-xxxxx- emergency-call-response )
Bestilling	Bestilling av planlagt transport (rekvisisjon). Se «Bestilt oppdrag»
Bestiller	Person som bestiller en planlagt transport (rekvirent).
Bestilt oppdrag (transportbestilling)	Bestilling av «planlagt transport», der det er behov for ambulansetjenestens ressurser. Transportbestillinger kan enten være registrert av bestiller, eller av AMK-operatør basert på en henvendelse fra bestiller.
CAD	Datastyrt kommunikasjonssentral (Computer Aided Dispatch)
CLI	Identifisering av oppringende linje (Calling Line Identification)
CR	Kontrollrom
Den akuttmedisinske kjeden	Samfunnets samlede organisatoriske, personellmessige og materielle beredskap for å kunne yte befolkningen akutt helsehjelp (NOU 2015:17).
DHCP	Dynamic Host Configuration Protocol
DNS	Domain Name System
DSB	Direktoratet for samfunnssikkerhet og –beredskap
eIDAS	Electronic Identification and Trust Services-forskrift
EPJ	Elektronisk pasientjournal
Etappetransport	Transport av pasient med ambulanse hvor transporten består av flere etapper.
ETA	Estimated time of arrival (Ankomsttid)
First responders	Personell med førstehjelpsopplæring og hjertestarter som kan alarmeres og rykke ut.
FKS	Flykoordineringssentral
Fleetmap	Oversikt over alle talegrupper, rettigheter for brukere, nummerstruktur, statusmeldinger og kallesignaler. (Sambandsstruktur)

Begrep/forkortelse	Beskrivelse
Flight following (FF)	(1) Monitorering og oppfølging av helikopter på oppdrag for å ivareta sikkerhet ved uventede hendelser. Anmerkning: Flight following innebærer å innhente flyrute og antatt landingstidspunkt, samt antall personer om bord ved alle forflytninger av helikopter. I tillegg iverksettelse av nødvendige tiltak hvis kontakt med helikopter blir brutt, innenfor beskrevne kriterier. Flight following ivaretas av AMK-LA og er en funksjon i ambulansehelikoptertjenesten i henhold til europeisk luftfartsregelverk.
Flykoordineringssentralen	Funksjon i ambulanseflytjenesten, som har som oppgave å drive med operativ koordinering og bemannes med flykoordinator som er ansvarlig for planlegging, koordinering og gjennomføring av ambulanseflyoppdrag ut fra operative forhold som vær, tilgjengelige ressurser (fly, flygere, flyplass), luftfartsbestemmelser og medisinske prioriteringer. Anmerkning: FKS tilhører Luftambulansetjenesten HF og er samlokalisert med AMK Tromsø. Forholder seg til medisinsk prioritering formidlet fra Medisinsk koordinerende punkt.
Flåtestyring	Kontrollrommets samlede disponering av de ressurser som er under sentralens ansvarsområde og styring. Innebærer ressursvalg knyttet til hendelser, og endringer som følge av beredskapsmessige behov.
Free seating	Ethvert anrop til medisinsk nødmeldetjeneste vil kunne besvares og følges opp fra hvilken som helst AMK-sentral.
Funksjonalitet	I denne sammenheng prosesser eller resultater som kan oppnås gjennom brukerhandlinger.
GAB	(1) register over grunneiendommer, adresser og bygninger. Se også Matrikkel.
GIS	Geografisk informasjonssystem (Geographical Information System)
GSM	Mobil telefoni
XXX	Xxxxxxx brukergrensesnitt (Graphical User Interface)
Hastegrad	(1) Gradering som forteller i hvilken grad det haster med respons på en hendelse. Anmerkning: Hastegrad deles inn i kategoriene Akutt (rød), Haster (gul) og Vanlig (grønn) ihht. Norsk indeks for medisinsk nødhjelp. Hastegrad grønn – vanlig (1) Hastegrad for tilstander der det antas at tidsmomentet medisinsk sett ikke er avgjørende og som kan forelegges lege til vurdering ved første passende anledning. Hastegrad gul – haster (1) Hastegrad for antatt alvorlig tilstand der de vitale funksjonene kan bli truet og der det er behov for umiddelbar situasjonsvurdering av lege eller transport til sykehus. Hastegrad rød – akutt (1) Hastegrad for antatt kritisk tilstand der de vitale funksjoner kan være truet eller manifest forstyrret og der ambulanse skal rykke ut og lege alarmeres.
Helseplattformen	Ny PAS/EPJ-løsning i Midt-Norge
HemsWX	Værapplikasjon for web, smarttelefon og nettbrett. Tjenesten gir tilgang til bl.a. sanntidsbilder fra værkameraer som er plassert på strategiske steder i Norge, værprognoser fra xxx.xx og lokale trykk-/temperaturmålinger. Eies av NLA Solutions AS.

Begrep/forkortelse	Beskrivelse
Hendelse	(1) Situasjon hvor det oppstår medisinsk hjelpebehov. Anmerkning 1: Hovedkategorier av hendelser er: somatisk og psykiatrisk sykdom, trafikkulykke, annen ulykke, annen medisinsk nød (rus, vold, brannskade, fødselshjelp).
Hendelsesbilde	Mest mulig av relevant informasjon i sanntid, som tale og data (strukturert tekst, bilde, video) knyttet til hendelse.
Henvendelse	Melding til AMK-/legevaktsentral. Henvendelsen kan være utløst av en hendelse, men kan også være en anmodning om transport (transportbestilling) eller annet som ikke kan knyttes til en hendelse.
HF	Helseforetak
HKP	Helikopter
HL7	Internasjonal standard for informasjonsutveksling mellom ulike dataplattformer xxxxx://xxx.xx0.xx/.
HRS	(1) Hovedredningssentral.
IAM	Identity and access management (Identites- og tilgangsstyring)
ICCS	Står for Integrated Communication Control System (integrert radio- og telefonibetjening) for håndtering av anrop og meldinger fra nødnettet (radiotrafikk) og det offentlig telefoninettet. (3)
IFR	Instrument Flight Rules (å fly på instrument)
IKT	Informasjons- og kommunikasjonsteknologi
Informasjonsdeling	Dynamisk (fortløpende) deling av hendelsesbilde, ved at en henter informasjonen fra samme datakilde.
Informasjonsutveksling	Utveksling av informasjon om hendelser som talt informasjon eller meldingsutveksling (ustrukturert, statisk).
Integrasjonsbuss	Presenterer data fra en kilde til en eller flere konsumenter. Håndterer gjerne logging, tilgang, sikkerhet og ulike dataformater.
Involvert part	Superentitet for individer som, på en eller annen måte, er involvert i en Hendelse. Disse deler en rekke informasjonselementer, som fødselsnummer, navn, adresse, osv.
IP	Internet Protocol
Kjernejournal	Elektronisk tjeneste som inneholder viktige opplysninger om helsen din, som både du som innbygger og helsepersonell har tilgang til. Blir du akutt syk, har helsepersonell rask og sikker tilgang til opplysningene i din kjernejournal. Kilde xxxxx://xxxxxxxxxx.xx/xxxxxxxxxxxxx
KoKom	Nasjonalt kompetansesenter for helsetjenestens kommunikasjonsberedskap
Kommunikasjonsgrensesnitt	Det definerte grensesnittet både fysisk og elektronisk mellom to komponenter i en kommunikasjonskjede.
Kommunikasjonsløsning	Løsning for AMK (og «små kontrollrom» (akuttmottak/LVS)) sin styring av nødnett, telefoni og oppdragsinformasjon.
Kommunikasjonskanal	Kommunikasjonskanal som er brukt for å kontakte AMK.
Kompetanse	Den kompetanse som personell besitter og som er nødvendig for å kunne utføre oppdrag som fastsettes av AMK.
Konsept	Et konsept er en mulig måte å gå frem på for å løse et problem eller skape en endring. (Difi ref xxxxx://xxx.xxxxxxxxxxxxxxxxxx.xx/xxxxxxxxxxxx)
Kontrollrom	(2) Lokasjon som har ICCS.

Begrep/forkortelse	Beskrivelse
Kriterier	I denne kontekst kriteriebasert respons (1) Respons basert på 1) symptomer, 2) kliniske tegn, 3) hendelse, eller en kombinasjon av disse, gjerne på grunnlag av utsagn fra innringer, eller nøkkelord i utsagn. Kilde: Kriterienummer (1) Nummer som ifølge Norsk indeks for medisinsk nødhjelp tegner et kriterium. Kriterium (1) henhold til Norsk indeks for medisinsk nødhjelp:1) et symptom, 2) et klinisk tegn, 3) en hendelse, eller en kombinasjon av disse.
LA	Luftambulanse
L-AMK	Lokal AMK i helseforetak
Legevaktsentral (LVS)	(1) Fagsentral betjent av helsepersonell, normalt for mottak, prioritering og formidling av henvendelse til legevakt eller oppdrag til hjemmesykepleier og jordmor, rådgivning til innringer og varsling av leger ved behov for medisinsk nødhjelp. Anmerkning: Forkortes til LV-sentral eller LVS.
Logistikk beslutningsstøtte	GIS-basert verktøy som utnytter regelsett og kartdata for valg av ressurser og planlegging av gunstigste vei.
LTE	Long Term Evolution mobilnett (4G+/5G/senere generasjoner).
LV	Legevakt
Lydlogg	System for opptak, avspilling og lagring av muntlig kommunikasjon mellom innringer og AMK- og legevaktsentral. Kilde: Akuttmedisinforskriften 2015. Logging kan inkludere andre funksjoner enn lyd. Leverandør/type; Racal/Nice®.
Matrikkel	Offentlig register over grunneiendommer (eiendomsregister).
Medisinsk beslutningsstøtte	Se beslutningsstøtte CDS – Clinical Decision Support er et omfattende fagfelt, der databasert kunnskap om pasient, hendelse, ressurser og klinisk situasjon er bakgrunnen for at regelsett ved gitte verdier trigger råd, anbefalinger, aktualisering av bestemte prosedyrer, destinasjon osv. CDS er verktøy som kan utnytte store datamengder til å foreslå neste tiltak, gjøre helsearbeideren oppmerksom på tilgjengelig informasjon som kanskje ikke er kjent, og fange opp potensielle problemer (som f.eks. legemiddelinteraksjoner). Se feks xxxxx://xxx.xxxx.xxx.xxx.xxx/xxx/xxxxxxxx/XXX000000/
Medisinsk nødmeldetjeneste	Den landsdekkende kommunikasjonsberedskapen for varsling og håndtering av henvendelser for akuttmedisinsk hjelp og kommunikasjon innen helse- og omsorgstjeneste, der medisinsk nødtelefon (113) og akuttmedisinske kommunikasjonssentraler (AMK), nasjonalt legevaktnummer (116 117) og legevaktsentraler (LVS), felles kommunikasjonstjenester og driftsorganisasjon inngår Kilde: Akuttmedisinforskriften 2015 (reformulert).
Medisinsk nødnummer	(1) Telefonnummer, 113, som befolkningen kan ringe ved behov for medisinsk nødhjelp. Anmerkning: Nødnummeret skal alltid uttales siffer for siffer, ikke som “hundreogtretten”. Dette av hensyn til at barn, utviklingshemmede og eldre da lettere kan slå nummeret. Det betinger at alle aktører, inkl. media, bruker korrekt uttalemåte i alle sammenhenger.

Begrep/forkortelse	Beskrivelse
Medisinsk operatør	(1) AMK-operatør som primært har ansvar for mottak og vurdering av 113- henvendelser, og for å gi medisinsk rådgivning og veiledning.
NGICCS	Neste generasjon ICCS (se ICCS)
Norsk indeks for medisinsk nødhjelp NIMN	Et veilednings- og støttesystem for personell i AMK-sentral og (1) legevaktsentral, og i hovedsak et verktøy for fastsettelse av hastegrad, valg av respons, medisinsk rådgiving og instruksjon.
NRDB	Nasjonal referansedatabase. Register for oppslag i telefonnummer. Alle telefon- leverandører har plikt til å levere informasjon til NRDB.
NRDB-AML	Advanced Mobile Location er et system som sender informasjon for posisjonering til NRDB (øker presisjon i lokalisering av anrop fra mobiltelefon).
NTP	Network Time Protocol
NVE	Norges vassdrags- og energidirektorat
Nødmeldesentral	(1) Stasjon/sentral som tar imot, tolker, gir råd til melder og beordrer respons på bakgrunn av nødmeldinger.
Nødnett	(2) Digitalt radionett for nødetatene. Landsdekkende sambandssystem som er basert på TETRA-standarden.
Område	Et avgrenset område i et kart. Avgrensningen skal kunne gjøres både av systemet (kommune, region, AMK-område, etc) eller manuelt som et polygon.
Operativ beslutningsstøtte:	a. Operativ beslutningsstøtte: Systemet skal liste nærmeste ressurser til et gitt geografisk punkt, med estimert tid og km, basert på faktisk fremkommelighet for gitt ressurs (luft, vann eller vei). b. Operativ beslutningsstøtte: Operatør som har mottatt henvendelsen (eventuelt annen operatør) mottar ved hjelp av beslutningsstøtten operativ prosedyre, ressursoversikt med best egnet ressurs samt web-baserte inndata (web kamera, veidata, meteorologiske forhold, hjertestartere etc.). Presentasjonen av informasjonen er konktekstsensitiv slik at ikke operatøren drukner i informasjon.
Oppdrag	Tiltak som innebærer aktivering av ressurser i form av personell og materiell som inngår i samfunnets akuttmedisinske beredskap.
Opprinnelsesmarkering	(1) Teknisk telefontjeneste som ved henvendelse til AMK eller andre nødmeldesentraler gir opplysninger om innringerens/abonnentens geografiske lokalisering, navn, adresse og tidspunkt for henvendelsen.
Optimering (Flåteoptimering)	GIS-basert system basert på prediksjon, der ressurser posisjoneres dynamisk, basert på forventning om behov (se prediksjon).
Overflow	Anrop til 113 går til alternativt definert sentral etter 20 sekunder i HMN. Det er også etablert lignende ordninger i andre helseregioner.
Pasient	Den eller de som er rammet av en Hendelse.
Personell	Personell som bemanner ressursene som AMK håndterer.
POI / Point of interest	Et identifisert punkt i et kart. POI skal kunne opprettes manuelt og det skal kunne knyttes informasjon, linker og regler til en POI.
PABX	private automatic branch exchange. «Hussentral», telefonsentral f.eks. for bygning eller organisasjon.
Prediksjon	GIS-basert system/algoritme som beregner sannsynlighet for neste hendelser, basert på historiske data og andre kilder, og som gir grunnlag for preemptiv posisjonering av ressurser.
Prehospital	omhandler hendelser, handlinger, tjenester og personell utenfor sykehus og er oftest relatert til pasientforløp som ender i sykehus.

Begrep/forkortelse	Beskrivelse
Prehospitale tjenester	Tjenestene utenfor sykehus som er eller kan bli involvert i håndteringen av pasienter som trenger øyeblikkelig hjelp. Disse er fastlege, legevakt, pleie- og omsorgstjeneste i kommunen (inkludert kommunale øyeblikkelig hjelp døgntilbud), nødmeldetjeneste (AMK- og legevaktsentral) og ambulansetjeneste (bil-, båt- og luft). Alle disse tjenestene er ikke nødvendigvis til enhver tid innrettet for eller i beredskap for akuttmedisinsk innsats. NOU 2015:17
PTT	Push-To-Talk (Trykk-for-å-snakke)
PSTN	Public switched telephone network (vanlig fast telefoni)
R-AMK	AMK-sentral med spesielt ansvar for enhetlig systemutvikling og samordning av brukerkrav i regionen og mellom regionene. Spesielt koordineringsansvar ved krisesituasjoner i regionen
RBAC	Role based access control (rollebasert tilgangsstyring)
Redundans	Teknisk løsning for å sikre høy oppetid på AMK-systemene.
Resilience	Renn (2008) definerer resilience som en beskyttelsesstrategi som sørger for at hele systemet har forsvar mot en ukjent eller usikker risiko.
Respons	Det eller de tiltak (se Tiltak) AMK eller LVS iverksetter for å gi helsehjelp. Er knyttet til hastegrad, men respons vil variere ut fra tid, sted, situasjon, ressurstilgang, lokale bestemmelser. Kategoriseres som Akutt (rød) (pri 1), haster (gul)(pri 2), vanlig (grønn) (pri 3). Ressurser som varsles vil ha tilsvarende begreper.
Ressurs	(1) Organisatorisk, personellmessig eller materiell enhet/innretning som kan bidra til å bibringe eller gjennomføre et oppdrag.
RHF	Regionalt helseforetak
RFI	Request for information (anskaffelse)
Robust	Motstandsdyktighet mot belastning, evne til å tåle større hendelser (dette kan inkludere evne til å fordele belastning).
Ruteplanlegging	GIS-basert verktøy som kalkulerer f.eks. korteste og raskeste rute for en eller flere tilgjengelige ressurser mellom to eller flere punkter, med korrigering for aktuell status for samferdselsåre (se Optimering).
Rådgiving/instruksjon	Gi innringer/pasient råd og/eller instruksjon basert på medisinskbeslutningsstøtte eller operativ informasjon.
Sambandsvei	(1) Gjennom hvilken kanal eller på hvilken måte man oppnår kontakt med nødmeldesentral.
SIP	Session Initiation Protocol (SIP) er et protokoll som benyttes for å kontrollere multimediakommunikasjonsøkter, dvs stemme- og video over IP-nettverk. SIP er spesifisert i RFC 3261 og benyttes bla for IP-telefoni, videokonferanser, IM, spill, osv.
SSO	Single Sign-On
TETRA	Terrestrial Trunked Radio. Åpen radioteknisk standard.
Tiltak	(1) Iverksettelse av en konkret handling som del av responsen på henvendelse. Anmerkning: Tiltak kan være råd eller instruksjon, eller det kan være aktivering av en ressurs/ambulanse.
TransMed®	Det system som for tiden benyttes for GIS i landets AMK-sentraler og for kommunikasjon med landets ambulanser (kommuniserer med TransMobile via Transcom®).
TransMobile®	Det system som for tiden benyttes for GIS og overføring av strukturert tekst med mer i landets ambulanser (kommuniserer med TransMed via Transcom®).

Begrep/forkortelse	Beskrivelse
Triage	(1) Prosess der en vurderer hastegrad på pasientbehandling basert på alvorlighetsgrad av skade eller sykdom.
Tverretatlig	Nødmeldetjeneste helse, politi og brann. Trippelvarsling (1) Intern varsling mellom alle nødetatenes 11X-sentraler i ett geografisk område. Varsling av de to andre nødetatene ved behov for alle tre. Anmerkning: Trippelvarsling kan foregå med eller uten innringer i konferanse Tverrvarsling (2) Intern varsling mellom to av nødetatenes 11x-sentraler i ett geografisk område.
UI	User Interface (brukergrensesnitt) – Se også GUI
Utalarmering	Samtidig varsling av flere ressurser i nødnett.
Utstyr	Utstyr som er nødvendig for å kunne utføre oppdrag.
Virtuell AMK / Virtuell kolokasjon	Virtuell AMK er en felles AMK-sentral der personalet befinner seg fysisk på flere lokasjoner, men arbeider i et felles, virtuelt (kunstig) kontrollrom. Virtuell AMK i en helseregion er det systemet, og den organisasjon, som sikrer at regionens AMK-sentraler kan tilby en sammenhengende og sømløs håndtering av nødmeldinger.
WCAG	Standarden Retningslinjer for tilgjengelig webinnhold
WINS	Windows Internet Name Service

Document Metadata

Table of Contents

Bilag til

Document Metadata