Innholdsfortegnelse

Målet er å innføre et gjennomprøvd fagsystem, heretter kalt ”Systemet” Vi ønsker et elektronisk sporbarhetssystem for kirurgiske instrumenter og som et ledd i infeksjonskontrollprogrammet ved Sykehuset Østfold. Sporbarhetssystemet må kunne knyttes opp mot eksisterende maskinpark for vask og desinfeksjons- og steriliseringsprosesser inkludert identitetsnummerering av instrumenter og utstyr for å sikre optimal sporbarheten i instrumentflyten i hele sykehuset.

Sterilsentralene er fordelt på 3 klinikker i Fredrikstad, Moss og Sarpsborg. Det nye Østfoldsykehuset som er under bygging og ferdigstilles i 2015 planlegges med to sterilsentraler.

Sykehuset Østfold ønsker at det nye Systemet skal kommunisere på tvers av klinikkene og avdelingene.

Kvalitetssikring av sterilforsyningskjeden er viktig av hensyn til pasientsikkerheten. Det skal være full sporbarhet fra et instrument blir rengjort, desinfisert, pakket, sterilisert og levert, slik at prosessen kan spores tilbake dersom pasienten får en infeksjon. Det er også viktig å kunne spore hvor ulike gjenbruksartikler befinner seg på lokale lagre for sterilt gods på forbrukende enheter. All sporingsinformasjon må lagres i Systemet.

Det skal etableres et lokalt lager med lagerstyring for selve sterilsentralen med registrering av alle artikler fra forbrukende enhet. Videre skal det være mulighet for lagerstyring av de enkelte behandlingsposters forbrukslager. Det skal kunne registreres når en enhet tas ut for forbruk og hvem som gjør det. For enkelte artikler vil det kunne bli benyttet to-bakk system.

Sterilsentralene steriliserer også en rekke instrumenter og verktøy som lånes og leies fra eksterne leverandører som det er ønskelig å etablere sporing av. Dette innebærer sporing av hvilken organisasjon/enhet som har lånt utstyret (inkludert når det er returnert), samt informasjon når den ble sterilisert sist med tilhørende holdbarhetsdato skal registreres.

1.1 Prosesskart mottak, vask og kontrollprosessen

Prosess 1

Prosess 2

Prosess 3

Prosess 4

Vask i dekontaminator

Ikke ok

Mottak av brukte brikker / instrumenter

Xxxxx / Smitte

Demontering og Behov for ekstra kontroll Behandling

Uttak / godkjenning av vask

Visuell pakking og kontroll (ref. steriliserings- prosessen)

Nei Registrere mottak Nei Lasting av vask Ok

Vask i dekontaminator

Spyling e.l.

Demontering og kontroll

• Kontroll i forhold til renhet, behov for ekstra behandling (spyling).

• Demonteringsanvis ning på fil.

Lasting av art til vask

• Intr. Registreres inn i vaskemaskin. Hvilke instrumenter og riktig program. Strekkodeleser. Varsling hvis ”motstridende” artikler lastes i samme vaskeprogram.

Vasking i dekonteminator

• Grensesnitt mellom systemet og vaskemaskin. For overvåkning av vaskeprosess. Dette lagres for å muliggjøre senere oppslag.

• Vaskeprosess (egen ”boks” i flytskjema)må godkjennes ved uttak. Artikler som ikke er godkjent går tilbake til demontering og kontroll.

Mottak av brukte fl.g. instr

• Registreres inn i systemet, brikker og løs pakkede instrumenter (strekkodeleser).

• Artikler med puss/smitte blir sendt rett til vaskemaskin for deretter å gå tilbake til registrering og ny vask.

Figur 1

Enkelte flergangsartikler (f.eks. prøveproteser, diatermier mm) kan kun brukes et begrenset antall ganger før det må kasseres. I tillegg skal enkelte artikler etter et visst antall ganger gjennomgå enklere service/vedlikehold og enkelte instrumenter etter et visst antall steriliseringer gjennomgå vedlikehold/service.

Sykehusets sterilsentraler rengjør, desinfiserer, klargjør og steriliserer ulike typer flergangsartikler (instrumenter, sett med utstyr/instrumenter – kalles ”instrumentbrikke”, etc.) som leveres ut til forbrukende enheter, og som så etter bruk tas tilbake rengjøres og desinfiseres, klargjøres og steriliseres på nytt. Hver type flergangsartikler (f.eks. enkeltinstrument, instrumentbrikke) har et fast

definert innhold og kan i lagersystemet betraktes om en artikkel med eget artikkel- og produktnummer

1.2 Prosesskart kontrollpunkter, pakking og autoklavering

Prosess 5

Prosess 6

Prosess 7

Prosess 8

Prosess 9

Nei

Visuell kontroll og montering

Er utstyret ok?

Pakking av brikker

Autoklavering

Er autoklaveringen ok?

Lager sterilt gods

Uttak fra sterilt lager

Suppleres med artikler fra rent lager:

- engangsartikler

- flergangsutstyr

- emballasje

Urent: returneres til ”demontering og kontroll” Ødelagt: erstattes, fra lager eller bestilles ny

Nådd levealder: erstattes, fra lager eller bestilles ny Behov for teknisk kontroll: sendes MTA

Lager sterilt gods

• Brikker og utstyr plasseres i henhold til lokasjon på etikett. Dette inkluderer sending opp til operasjon i de tilfeller lokasjon = lager operasjon.

Autoklavering

• Brikker lastes på vogner.

• Strekkodeleser.

• Registrere hvilke brikker og løse instrumenter som er i autoklaven.

• Sanntidsovervåkning av prosessen.

Uttak og kontroll

• Visuelt kontrollere last.

• Godkjenne autoklaveprosessen.

• Underkjente brikker / produkter går tilbake til ”visuell kontroll og pakking”.

• Strekkodeleser for registrering.

• Godkjenning av autoklaveprosess = plassert på lager iht. etikett (lokasjon).

Uttak fra sterilt lager

• Brikker plukkes og plasseres i prosedyrevogn basert på operasjonsplanen eller bestilling fra avdeling.

• Skjer fortløpende. Starter kvelden før for første operasjon.

• Strekkodeleser for uttak.

• Varer registreres ut fra lager.

Visuell kontroll og pakking

• Instrumenter monteres og funksjonstestes.

• Eventuelt urent utstyr går tilbake til demontering og kontroll.

• Ødelagte utstyr fjernes.

• Suppleres med varer fra rentlager; engangs og flergangs (ved behov).

• Brikker som ikke er komplette blir satt tilside i påvente av nødvendig utstyr (fra vask eller innkjøp av nye).

• Strekkodeleser.

• System: bilder, video (montering), innholdsfortegnelse, etc.

• Varsel i forhold til antall steriliseringer (kasseres, teknisk sjekk).

• Utskrift av etiketter, innholdsfortegnelse, mangellapp.

Uttak og kontroll

Figur 2

Sterile produkter rengjøres og desinfiseres i dekontaminatorer (vaskemaskiner) og steriliseres deretter i autoklaver. Det skal for hver enhet registreres i hvilken dekontaminator/vaskeprogram og i hvilken autoklave/steriliseringsprosess som er benyttet med tilhørende dato/tidspunkt. Det benyttes både damp- og plasmaautoklave. Denne informasjonen skal registreres i Systemet. Det er ønskelig at dette også registreres ved rengjøring i ultralydbad.

1.3 Prosesskart bestilling, registrering og oppbevaring - lager

Prosess 10

Prosess 11

Prosess 12

Prosess 13

Prosess 14

Behov for varer basert på forventet aktivitet

Bestilling Lagervare

-styres av min/max nivå

- 3-5 ganger per uke

Rent lager:

- flergangsartikler og andre varer som ikke er sterilisert (papir, plast,

reservedeler osv.)

Ankomstregistrering

- på rampe

- kun kollikontroll

Bestilling Skaffevare

- bestilles fortløpende

ved behov

Utpakking

- stripping av xxxxxxxxxxxxxxx x

utpakningsrom

Mottak:

- kontroll mot pakkseddel / ordre

- mottak i systemet

- evt. fjerning av mellomemballasje

Sterilt lager:

- sterile engangsartikler

-steriliserte brikker

løspakkede instrumenter

Lager operasjon:

- Implantater

- Sterile engangsartikler som ikke skal prosedyrepakkes

- Beredskapslager

Varsel om endret behov:

- kan generere skaffevarebestilling

- justering av min/xxx xxxxxx

- kan være for en kortere periode eller på mer permanent basis

Lager operasjon

• Implantater.

• Sterile engangsartikler som ikke prosedyrepakkes.

• Beredskapslager.

Behov oppstår

• Skille mellom lagervare og skaffevare (bestilles ved behov).

• Xxxxxx behov knyttet til operasjon: Sterilsentral må informeres (behov for prosedyre?).

Utpakking og mottak

• Stripping av ytteremballasje i utpakningsrom.

• Kontroll mot pakkseddel/ordre (gjøres i sluse).

• Mottak registreres i systemet (i sluse).

• Evt. mellomemballasje fjernes i sluse før fysisk plassering i lager.

• 3 ulike lager: rent og sterilt ved sterilsentralen + sterilt instrumentlager operasjon.

Uttak fra lager

• Implantater.

• Sterile engangsartikler som ikke prosedyrepakkes.

• Beredskapslager.

• Etterfylling til brikker.

• Emballasje til brikker.

• Supplering av løs pakkede instrumenter.

• Plukking til prosedyrevogner på bakgrunn av operasjonsplan.

• Etter bestilling fra øvrige avdelinger.

• Håndteres av operasjon.

Sterilt lager

• Sterile engangsartikler.

• Steriliserte brikker og løspakkede instrumenter.

Bestilling

• Lagervare: styres etter min/max nivå. Kalnes: daglige bestillinger EFS og leverandør.

• Skaffevarer fortløpende.

• Planlegging i tilfeller hvor det blir gitt informasjon om ekstraordinær aktivitet.

• Noe justering av min xxx på bakgrunn av sesong (glatta).

• Evt standardisering av produkter kan i liten grad skje men initiativ fra sterilsentralen – må komme via andre kanaler.

Uttak av varer:

- håndteres av operasjon

Uttak av varer:

- plukking til prosedyrevogner på bakgrunn av operasjonsplan

- plukking etter bestilling fra øvrige avdelinger

Uttak av varer:

- etterfylling til brikker

- emballasje til brikker

- supplering av løspakkede instrumenter

Xxxx og annen emballasje (returneres til servicegården)

Figur 3

Operativ virksomhet er en sentral del av pasientbehandlingen. Systemet skal benyttes som et verktøy i et behandlingsforløp med operativ virksomhet. Systemet skal bidra til å sikre nødvendig kvalitet i pasientbehandlingen, pasientsikkerhet, sporing, logistikk for operasjonsinstrumenter samt gi nødvendig informasjon til innkjøp og økonomi/regnskap systemet. Planlegging av operasjonsvirksomheten og optimal ressursutnyttelse er nødvendig for styring og drift av virksomheten. I tillegg til at Systemet må ivareta de spesifikke funksjoner knyttet til sterilsentralen beskrevet over, og det må være integrasjoner mot følgende systemer:

• Sporing

Alle artikler både enkeltartikler og som del av en definert instrumentbrikke må kunne spores og systemet må ha en kontrollfunksjon som varsler dersom en instrumentbrikke ikke har korrekt innhold ut fra en innholdsfortegnelse. Alt instrumenter må kunne spores til gjennomført vaske- og steriliseringsprosess og systemet må varsle antall ganger enkelte definerte instrumenter har vært benyttet. Leverandør bør legge frem forslag til sporingsløsninger som også gir oss status på lokale lagre og hvor merkede produkter befinner seg til enhver tid.

• Nytt logistikk- og regnskapssystem.

Dette omfatter både instrumenter og medisinske forbruksvarer knyttet til operasjonsvirksomhet som implantater, engangsutstyr osv. Systemet må være tilstrekkelig integrert mot lager og innkjøpssystem til å sikre nødvendig oversikt over lokale lager på både sterilsentral og operasjonsavdelinger. Innkjøp og logistikksystemet vil i fremtiden fungere som master for denne funksjonaliteten.

Systemet må gi nødvendig informasjon til økonomi- og regnskapssystemet slik at innkjøp og utlån av instrumenter belastes rett ansvar og prinsipper for verdifastsettelse av lagerbeholdning med mer ivaretas. Økonomi- og regnskapssystemet vil i fremtiden fungere som master for denne funksjonaliteten.

• Operasjonsplanlegging (Opsjon)

Det benyttes i dag en modul i DIPS for planlegging og oppsett av operasjonsprogram. Systemet skal bidra til å sikre god pasientlogistikk og effektiv ressursutnyttelse. Det innebærer bl.a. at nødvendig instrumenter og forbruksvarer er tilgjengelig i forbindelse med operative inngrep. Operasjonsplanleggingssystemet bør kunne benyttes som et ressursplanleggingsverktøy som bidrar til at rett pasient, operatør og annet nødvendig personale, operasjonsstue, instrumenter, medisinske forbruksvarer og medisinsk teknisk utstyr er tilgjengelig. Sterilsentralsystemet må integreres mot modulen og via DIPS gi nødvendig og god brukerintegrasjon.

• GAT (Opsjon)

Leverandør bes å redegjøre for hvilke muligheter som finnes for integrasjon mot personalsystem. Prinsipper utarbeidet av norsk IKT arkitekturgruppe er førende.

• Sporing (Opsjon)

Leverandør bes å redegjøre for hvilke elektroniske sporingsløsninger basert på RFID/ultralyd som er tilgjengelig for denne leveransen.

2 Definisjoner som benyttes i kravtabellen

PAS/EPJ = elektronisk pasient- og journalsystem ved SØ, Dips. SØ = Sykehuset Østfold HF.

Ressursbruker = en ressursperson overfor annet personell mht bruk av løsningen, og som skal gjennomføre opplæring av andre ansatte, samt interne bestillere i SØ.

GPL = Gjeldene produktliste.

ERP = Enterprise resource planning (Nytt økonomi- og logistikksystem)

3 Utfylling av kravtabeller

Kolonnene ”Beskrivelse av krav” og ”Kravkategori” er utfylt av oppdragsgiver.

O =	Obligatorisk. Dersom krav med denne klassifiseringen i sin helhet ikke er innfridd i leverandørens svar, vil tilbudet avvises. Det presiseres at ALLE obligatoriske krav må innfris.
H =	Høy viktighet. Meget viktig for utnyttelse av løsningen at kravet er innfridd.
M =	Middels viktig. Viktig at kravet er innfridd.
L =	Lav viktighet. Ikke avgjørende for å kunne ta løsningen i bruk, men ønskelig.
B =	Beskrivelse. Fremkommer sammen med ”H”, ”M” eller ”L”. Krav som det skriftlig skal redegjøres nærmere for, eventuelt med skisser/tegninger el. Dersom svaret er utfyllende, skal besvarelse skrives på eget bilag, med tydelig henvisning til kravnummer.

Leverandør skal fylle ut kolonnene ”Møter krav” og ”Leverandørens svar/kommentarer”. Beskrivelse av ”Krav kategori”:

I =	Informasjon. Informasjon fra SØ. Punktet krever ingen besvarelse fra leverandør.

Selv om det ikke fremkommer i det enkelte krav at det kreves dokumentasjon eller ytterligere beskrivelse, har tilbyderne mulighet å gjøre det også for disse. Beskrivelse kan gjøres på egne vedlegg. Disse må ha tydelig henvisning til kravnummer.

4 Obligatoriske krav

Dette punktet inneholder alle obligatoriske krav. Dette er krav som det ikke kan tas forbehold mot. De som ikke svarer et ubetinget ”JA” på disse kravene, vil få sine tilbud avvist.

Nr	Beskrivelse av obligatoriske krav	Krav- kategori	Møter krav JA/NEI
4.1.1	Leverandøren skal tilby opplæring på norsk.	O
4.1.2	Leverandøren må forholde seg til gjeldene lover/forskrifter som har relevans til anskaffelsen (jf SSA-K, kap 9), herunder: Lov om vern av smittsomme sykdommer Kap.6.4 siste avsnitt, Kap. 6.9.1, 6.9.2 og gjeldende normer (EN285 og EN554) samt kvalitetssikring av prosessene via ISO 9001:2001.	O
4.1.3	Leverandørens ansatte skal lese og signere følgende skjemaer; databehandleravtale, taushetsplikt og taushetserklæring.	O
4.1.4	Alle kostnader relatert til anskaffelsen skal fremkomme i Prisskjemaet. Prisskjemaet vil være en del av K Bilag 7 Samlet pris og prisbestemmelser.	O
4.1.5	Det elektroniske sporbarhetssystemet som tilbys skal kunne ivareta de overordnede målene med anskaffelsen som er angitt i punkt 1.	O
4.1.6	Leverandøren skal ha inngående kjennskap til sterilforsyning og drift av sterilsentraler.	O

5 Generelle krav

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
5.1.1	Leverandøren skal tilby online dokumentasjon/brukerveiledning.	H/B
5.1.2	Leverandøren skal gi eksempler på investeringsavkastning fra andre tilsvarende installasjoner. Disse eksemplene bør være fra referansebedriftene.	H/B
5.1.3	Systemet skal tilby innovative enkle løsninger som er lett å tilpasse for en ressursbruker.	M/B
5.1.4	Betalingsplan fremkommer i punkt 3 i K Bilag 7 Samlet pris og prisbestemmelser.	H

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
5.1.5	Alle kostnader i forbindelse med reiser til og fra installasjonssted skal være inkludert i tilbudsprisen; reisetid, reisekostnader, dietter, overnatting mv., jf Prisskjema.	H
5.1.6	Leverandøren skal beskrive alle vesentlige forutsetninger knyttet til leveransen av kontrakten.	H/B
5.1.7	Åpenbare feil/mangler i kundens kravspesifikasjon skal beskrives.	H/B
5.1.8	Forslag til prosjekt- og fremdriftsplan utarbeides i henhold til bestemmelsene i SSA- K med henblikk på faser, kundens og leverandørens ansvar og oppgaver. Prosjekt- og fremdriftsplan innarbeides i K Bilag 4 til kjøpsavtalen.	H/B
5.1.9	Leverandøren har det fulle ansvar for samarbeid med tredjepart, jf SSA-K punkt 5.4.	H
5.1.10	Leverandøren skal være den part som følger opp eksterne leverandører i forbindelse med oppdrag som skal gjennomføres. For eksempel opp mot Dips, Sykehuspartner med flere.	H
5.1.11	Vi ønsker at leverandøren redegjør for de ulike typer av sporingsteknologi som tilbudte system støtter både fra et bruker- og teknologiskperspektiv.	H/B
5.1.12	K Bilag 8 inneholder kundens krav til endringer i den generelle avtaleteksten. Leverandøren skal bekrefte endringene. Leverandøren skal i samme bilag legge inn eventuelle egne forbehold og endringsforslag til avtaleteksten. Disse skal merkes og begrunnes i bilaget.	H

6 Funksjonelle krav

6.1 Kompetanse

Beskrivelse av krav

Krav kategori H/M/L/

(B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

6.1.1

Leverandøren skal gi en oversikt over nøkkelpersoner med relevante kvalifikasjoner/kompetanse som skal ha ansvar for eventuell kontraktsutførelse. Dette skal dokumenteres (CV/vitnemål):

- Navn

- Stilling/tittel, utdanning

H/B

Beskrivelse av krav

Krav kategori H/M/L/

(B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

- Rolle i utførelsen av oppdraget (prosjektleder, testleder mf)

- Spesifisert kompetanseprofil

- Referanser siste 3 år (inkl rolle)

6.2 Opplæring

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
6.2.1	Leverandøren skal levere forslag til kurs og opplæringsplan.	H/B
6.2.2	Leverandøren skal stå for opplæring av et nødvendig antall ressursbrukere, inntil ti personer.	H/B
6.2.3	Leverandøren skal stå for opplæring av brukere i kundens lokaler, inntil 50 personer, samt redegjøre for opplæringsmetode.	H/B
6.2.4	Leverandøren skal utvikle og levere kursdokumentasjon til alle deltakere skriftlig og elektronisk.	H

6.3 Artikkelregister

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
6.3.1	Systemet skal ha ett artikkelregister hvor alle artikler registreres med varenummer, beskrivelse, referansenummer, kommentarer osv. Leverandøren må beskrive hvilke felter registeret håndterer. Oppgi antall tegn som de enkelte feltene disponerer. Integreres mot nytt økonomi og logistikk system	H/B
6.3.2	Det skal være mulig å definere ”produkter” (instrumentsbrikker) som består av et sett med artikler. Det skal være mulig å opprette nye ”produkter” basert på allerede definerte artikler. (dvs. en instrumentbrikke er utgangspunkt for definisjon av en ny type instrumentbrikke). Integreres mot nytt økonomi og logistikk system	H/B
6.3.3	For gjenbruksartikler (pr. individ) skal det etableres et sporingsregister hvor det skal registreres antall ganger sterilisert,	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	siste sterilisering, dato for sterilisering, holdbarhetsdato og nåværende lokasjon (lager, bestillingssted, service ol)
6.3.4	For ulike typer instrumentsbrikker skal det være mulig å definere kvalitetskontroller med tilhørende sjekkpunkter i sterilsentralen, operasjonsavdelingen, dagkirurgi post, poliklinikker, spesialposter og sengeposter.	H/B
6.3.5	Alle gjenbruksartikler skal kunne bokstavmerkes (type instrument for visuell kontroll) og spores.	H/B
6.3.6	Det skal være mulig å definere tilhørighet mellom artikler/instrumentbrikker, og mellom artikler og bruk (operasjonstyper, f.eks. ortopedi, gastro, laparaskopi)	M/B
6.3.7	Det skal være mulig å legge inn bilder/dokumenter av ulike artikler/brikker for å forenkle prosessen for brukeren. Det er også ønskelig at det skal være mulig å legge inn videoklipp som f.eks monteringsanvisning knyttet til artikkel/brikke.	H/B
6.3.8	Det skal være fritekst/kommentarfelt knyttet til brikker hvor man kan legge inn kommentarer om instrumenter til reparasjon, spesielle ting som vedlikehold knyttet til brikken osv.	H/B

6.4 Rengjørings- og desinfeksjonsprosessen

Sterilsentralen mottar brukte artikler. Alle mottatte artikler registreres, og eventuelle mangler i forhold til utleverte mengder blir registrert og rapportert til brukerstedet.

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
6.4.1	Alle instrumenter/gjenbruksartikler som returneres til sterilsentralen skal registreres i systemet ved mottak i sterilsentralene. Se fig. 1. «Mottak av instrumenter».	H/B
6.4.2	Ved registrering av instrumenter/brikker skal det være mulig å få opp bilde/film/dokument med f.eks monterings-/demonteringsanvisning eller annen relevant informasjon. Se fig. 1. «Demontering og kontroll».	H/B
6.4.3	Når en vaskekurv/innsats klargjøres for bruk, skal det registreres hvilket	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	vaskeprogram som skal benyttes samt hvilken vaskekurv innsats som skal benyttes. Se fig. 1. «Lasting av vask».
6.4.4	Det skal i systemet registreres hvilke artikler som lastes til en gitt vaskekurv/innsats, og systemet skal varsle bruker dersom artikler som lastes til kurven ikke kan benytte valgt program (basert på egenskaper ved artikkelen).	H/B
6.4.5	Systemet skal via grensesnitt kunne angi overfor vaskedekontaminatorer hvilket program som skal benyttes for en gitt vaskekurv/innsats.	H/B
6.4.6	Systemet skal kunne motta informasjon fra vaskedekontaminatorer og autoklavene om hvilken vaskemaskin/program som er benyttet for en gitt vaskekurv/innsats, og dette skal registreres pr. artikkel/instrumentbrikke. Se fig. 1. «Vasking».	H/B
6.4.7	Systemet skal kunne motta sanntidsinformasjon om vaskeprosessen fra vaskemaskinene. Denne informasjonen skal lagres digitalt, men skal også kunne skrives ut på papir ved behov.	H/B
6.4.8	Når en vaskeprosess er ferdig skal brukeren manuelt sjekke lasten. Deretter skal brukeren godkjenne hele eller deler av lasten i Systemet. Se fig. 1. ”Uttak/Godkjenning av vask”.	H/B
6.4.9	Kassering og reparasjoner/service/vedlikehold av gjenbruksartikler skal registreres i systemet, samt supplering av instrumenter til instrumentbrikker. Det skal være mulighet for å opprette egne koder og årsaker knyttet til dette. Se fig. 1.«Visuell kontroll og pakking av utstyr».	H/B
6.4.10	Systemet skal kunne skrive ut innholdslister med tilhørende strekkoder el. som skal inngå i de enkelte sterile forpakninger. Utskrifter skal tåle autoklaveringsprosesser.	H/B
6.4.11	Systemet skal ha mulighet for individstyring på artikler/instrumentbrikker.	H/B
6.4.12	Systemet skal kontrollere at alle instrumenter/artikler som skal inngå i en instrumentbrikke, er inkludert før	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	godkjenning. Det må være mulig å manuelt godkjenne en brikke som har avvikende innhold. Det skal kunne skrives ut en ’mangellapp’ om kan klistres på utsiden av brikken.
6.4.13	Det skal etableres funksjoner i systemet som varsler når et instrument har vært igjennom for eksempel 5 autoklaveringsprosesser slik at man kan gjennomføre service og vedlikehold på instrumentet.	H/B
6.4.14	Tilsvarende varsling skal gis når artikler skal kasseres.	H/B
6.4.15	Service og vedlikehold, samt kassering av instrumentene skal registreres i systemet. Integreres mot nytt økonomi og logistikk system	H/B
6.4.16	Det skal i tilknytning til hver enkelt instrumentbrikke registreres hvilken emballasje som er benyttet for pakking, størrelse, hvem som utførte pakking og hvilken steriliseringsmetode som er benyttet. Dette skal kunne skrives ut på etikett fra Systemet og festes på emballasjen til instrumentet/brikken for visuell identifikasjon,	H/B
6.4.17	Systemet skal kunne angi overfor autoklavesystemet hvilken steriliseringsprosess som skal benyttes for et gitt produkt, og dette skal registreres pr. artikkel/instrumentbrikke. Se fig. 2. «Autoklavering».	H/B
6.4.18	Systemet skal kunne motta informasjon fra autoklavene om hvilken autoklave/prosess som er benyttet for et gitt produkt, og dette skal registreres pr. forpakning.	H/B
6.4.19	Systemet skal registrere status etter sterilisering for alle forpakninger/artikler med type prosess, tidspunkt og evt. holdbarhet, samt hvem som kontrollerte. Se fig. 2. «Uttak og kontroll».	H/B
6.4.20	Dersom det avdekkes feil i kontrollen (våt last, hull i papir), prosessen underkjennes eller instrument/instrumentbrikke skal resteriliseres, skal dette registreres med tidspunkt.	H/B
6.4.21	Systemet skal holde oversikt over alle typer steriliserte gjenbruksartikler (instrumenter, instrumentbrikker), dvs. hvor de befinner seg. Det skal være mulig å legge inn	H/B

Beskrivelse av krav

Krav kategori H/M/L/

(B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

egendefinerte lagerlokasjoner på instrumenter/brikker som vises på utskrevet etikett. Dette for å lette arbeidet med å lagre utstyret på rett

plass. Se fig. 3. «Sterilt lager».

6.4.22

Det skal være mulig å skrive ut tilbakekallingslister for instrumentbrikker og instrumenter som har gått ut på

holdbarhetsdato slik at dette kan tilbakekalles.

H/B

6.5 Arbeidsflyt

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
6.5.1	Det skal registreres i systemet hvilke instrumenter/instrumentbrikker som leveres til hvilke steder ((operasjonsposter (inkl. dagkirurgi), sengeposter, poliklinikker)).	H/B
6.5.2	Når en instrumentbrikke benyttes, skal det kunne registreres tidspunkt, sted samt hvem som tok det i bruk. (evt. pasientidentifikasjon)	H/B
6.5.3	Det skal være inkludert en modul for å styre produksjonen, kontroll og vareflyt i sterilsentralen.	H/B
6.5.4	Bruker med fullmakt til dette skal være i stand til å definere/endre arbeidsflyten knyttet til ulike deler av arbeidsprosessene.	H/B
6.5.5	Systemet skal kunne skrive ut produksjonslister basert på innlagte bestillinger i systemet.	H/B

6.6 Rapportering – Sanntidsdata - Sporbarhet

Beskrivelse av krav

Krav kategori H/M/L/

(B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

6.6.1

Systemet skal fremvise sanntidsdata både på skjerm og i rapportform, hvor

ulike instrumenter/instrumentbrikker befinner seg.

H/B

6.6.2

Systemet skal periodisk rapportere: Antall enheter (brikker/individer) kontrollert, antall steriliseringsprosesser,

osv.

H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
6.6.3	Systemet skal utarbeide produksjonskurver over døgnet i forbindelse med steriliseringsprosessene.	H/B
6.6.4	Leverandøren skal beskrive standard rapporter og evt. tilleggs-rapporter som er nødvendig for å følge opp sterilsentralens produksjon og lager.	H/B
6.6.5	Det skal være mulighet for å kunne utarbeide egne rapporter/spørringer i Systemet.	H/B
6.6.6	Rapporter skal kunne skrives ut i de mest vanlige formater; word, excel, pdf, dump av skjermbilder med flere.	H/B
6.6.7	Det må finnes en funksjon for forhåndsvisning av rapporter.	H/B
6.6.8	Kunde må selv kunne editere layout på de rapporter som genereres. Eksempelvis skal SØ sin logo kunne brukes på utskrifter.	H/B
6.6.9	Systemet bør kunne generere trendanalyser iht. spesifikasjoner som sterilsentralen fritt kan sette.	M/B
6.6.10	Statistikker / rapporter skal kunne vises / forhåndsvises på skjermbilde i forskjellige varianter.	H/B

6.7 Lokal lagerstyring i applikasjonen

Sykehuset jobber med anskaffelse av nytt ERP system, som skal dekke områdene logistikk økonomi og sentral felles registre. Som en del av denne anskaffelsen vil det bli vurdert funksjoner som logistikk modul og sentral felles registre opp mot system anskaffelsen. Vi ønsker at leverandøren redegjør for hvordan tilbudte lokal lagerstyring kan samspille med vårt nye ERP system.

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
6.7.1	Det er ønskelig at leverandør beskriver hvordan operasjonsavdelingene kan legge inn bestillinger til sterilsentralene basert på Dips operasjonsmodul.	M/B
6.7.2	Systemet skal kunne integreres med sentralt logistikk og lagerstyringssystemet, slik at bestillinger og annen nødvendig informasjon kan overføres fra systemet til sentral løsning.	H/B
6.7.3	Systemet skal ha oversikt over lagerbeholdning av engangsartikler og flergangsartikler, samt hvor flergangsartikler befinner seg.	H/B
6.7.4	Ved sterilsentralenes lokale lagre skal det være mulig å registrere både utlevering til	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	forbrukende enhet, mottak etter bruk og ferdig sterilisering for sterile artikler.
6.7.5	Sterile varer har begrenset holdbarhet, og alle registreringer må kunne referere til et varepartinummer(LOT/Batch/Ordrenummer).	H/B
6.7.6	For hver type artikkel må Systemet kunne gi oversikt over: - Antall som finnes på hver forbrukende enhet(antall levert ut, men ikke returnert). - Totalt og fordelt på partinummer. - Antall av et gitt partinummer som finnes på de ulike forbrukende enheter. - Antall som er mottatt etter bruk, men ikke ferdig sterilisert. - Antall ferdig sterilisert og disponibelt på sterilsentralen, totalt og pr partinummer. - Artikler som er utgått på dato, sortert pr avdeling(kunde) eller lager.	H/B
6.7.7	Dersom det avdekkes problemer med en autoklave skal Systemet kunne liste ut sporing av alle instrumentbrikker som er berørt, inkludert innhold i brikken, produksjonsdato, leveringsdato, forbruksdato og sted.	H/B
6.7.8	Viktig at samme varenummer og tekst følger varen fra hovedlager inn på lokalt lager. Det skal være mulig å legge inn alias varenummer og tekst for enkelt produkter i tillegg til tilleggskommentarer.	H/B
6.7.9	Når varer blir levert ut til forbrukende avdelinger fra lokale lager skal de faktureres avdelingene.	H/B
6.7.1	Sykehuset Østfold ønsker at leverandørene gir et tilbud på en løsning hvor Systemet håndterer lagerbeholdning, bestillinger, innkjøp og internfakturering.	H/B
6.7.1	Tilbudt system må ha grensesnitt for overføring av data og transaksjoner mot våre administrative systemer. Leverandør må legge frem skisser og tekniske løsninger på hvordan integrasjoner kan gjennomføres.	M/B
6.7.1	Produkt endringer sentral skal oppdateres automatisk lokalt i logistikksystemet. Brukere ved Sterilsentralen skal motta melding når varelinjer med mer blir oppdatert fra sentral logistikksystem. Alias og egen tekst i det lokale logistikksystemet må opprettholdes når erstatningsprodukt blir lagt inn.	H/B

6.8 Sentralt Økonomi og logistikk -system

Det skal anskaffes et nytt økonomi- og logistikksystem til sykehuset. For å oppnå størst mulig gevinstrealisering og unngå dobbeltregistrering av data, planlegges det sentrale registre i det nye økonomi- og logistikksystem som skal være “master” for andre systemer.

For systemer opp mot nytt økonomi- og logistikksystem innebærer dette i hovedsak at disse systemene omfattes av løsningen:

• Felles standarder for administrative prosesser og data innen logistikk og økonomi

• Felles systemløsninger for administrative støttefunksjoner innen logistikk og økonomi

• Felles forvaltning og utførelse av transaksjonsorienterte prosesser innen logistikk og økonomi

Nytt økonomi- og logistikksystem vil fungere som master for utvalgte grunndata, registre, logistikk og økonomi -funksjoner/prosesser. Tilbudt systemet må kunne benyttes uavhengig av nytt økonomi- og logistikksystem. Når nytt økonomi- og logistikksystem er tilgjengelig må systemet sende over oppsamlede data og oppdatere “master data”. Fremtidig vedlikehold av utvalgte “master data” vil da gjennomføres i det nye økonomi- og logistikksystemet.

Overordnede arkitekturmålbilder for IKT-tjenester i helseregionen omfatter utvikling mot en tjenesteorientert arkitektur. Dette innebærer blant annet at masterdata gjøres tilgjengelig ved hjelp av definerte tjenester på en regional/lokal tjenestebuss. Trafikken skal i hovedsak være meldingsbasert, i motsetning til filbasert som mange av integrasjonene er i dag.

De tjenesteområder som økonomi-/logistikk systemet i samspill med systemet skal dekke, er:

• Inngående varelogistikk

• Utgående varelogistikk

• Inngående tjenestelogistikk

• Utgående tjenestelogistikk

• Inn- og utgående fakturabehandling

• Inn- og utgående betaling

• Reskontro

• Konsernintern og foretaksintern handel

• Regnskap og rapportering

Beskrivelse av krav

Krav kategori H/M/L/

(B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

6.8.1

Leverandør skal beskrive sin løsning basert på kravene over.

H/B

7 IT- Tekniske krav

Systemet skal leveres med integrasjon mot ulike tekniske systemer, Pasientadministrativt system (PAS)/Elektronisk pasientjournal (EPJ), medisinsk-teknisk utstyr (MTU), Ledelses- og informasjonssystem (LIS) med flere. Løsningen skal understøtte Sykehuspartners (SP) IKT-arkitektur (SQL, BizTalk).

Systemet skal inneholde egenskaper for lagring av sanntidsdata i tidsserier samt for sporing av hendelser

Løsningen må kunne utveksle informasjon med øvrige sentrale systemer, som for eksempel PAS/EPJ. Løsningen skal også kunne levere informasjon til en portalløsning, for fremstilling av dette.

Systemet skal ha mulighet for lagring av informasjon om prosessdesign og tilhørende informasjon, til kontinuerlig forbedring av prosesser.

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	Generelt
7.1.1	Systemet skal fungere på sykehusets IT- plattform, jf K Bilag 3 Kundens tekniske plattform.	H/B
7.1.2	Leverandør skal beskrive eventuelle behov for oppgradering/endring av kundens tekniske plattform, jf K Bilag 3.	H/B
7.1.3	Nasjonal IKT og Xxxx har beskrevet gjeldende arkitekturprinsipper for spesialisthelsetjenesten. Leverandør må beskrive hvordan IKT-løsningen oppfyller og understøtter relevante prinsipper. Her følger et utdrag av disse: - Interoperabilitet. - Forsvarlig tilgang til informasjon. - Endringsevne og fleksibilitet. - Leverandøruavhengighet. - Gjenbruk av informasjon gjennom tjenester. - Kontrollere teknologivariasjoner. - Modne standarder og teknologier. - Pålitelighet, skalerbarhet og robusthet. Se link xxx.xxxxxxxxxxx.xx samt xxx.xxxx.xx.	M/B
7.1.4	Leverandør skal informere om minimumskrav for systemet.	H/B
7.1.5	Leverandør skal beskrive hvilke lisenstyper som tilbys og prise disse i henhold til prisskjemaet.	H/B
7.1.6	Leverandør skal beskrive hva som omfattes av en eventuell site-lisens og prise denne i prisskjemaet. Dersom en site-lisens faller rimeligst i pris, vil denne i stedet bli gjenstand for evaluering.	H/B
7.1.7	Installasjon av systemet og utrulling av applikasjonen utføres i samarbeid med Sykehuspartner.	H
7.1.8	Feilretting utføres i samarbeid med Sykehuspartner.	H
7.1.9	Det skal beskrives hvordan systemet fungerer/integreres mot f.eks. - Web. - Pda. - tablet løsning.	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	- Rfid.
	Tjener- og databaseplattform
7.1.10	Løsningen må kunne kjøres på en virtuell server infrastruktur. I de tilfeller der sertifisering og/eller lisensiering av produkter som inngår i løsningen hindrer en kostnadseffektiv utnyttelse av en virtuell infrastruktur må dette gjøres rede for.	H/B
7.1.11	Løsningen skal kunne driftes i et teknisk miljø med HA-design (high availability) som inkluderer clustring av tjenester (database), speiling av data og eventuelt andre HA mekanismer.	H/B
7.1.12	Tjenerinstallasjonen skal kunne installeres på Microsoft Windows Server 2008 R2. RedHat Enterprise Linux 6 eller nyere i henhold til Sykehuspartner GPL (Gjeldene produktliste).	H
7.1.13	Tjenerinstallasjonen skal kunne installeres på Microsoft SQL Server 2008 R2, Oracle 12g eller nyere i henhold til Sykehuspartner GPL.	H
7.1.14	Ved integrasjon mot katalogtjenester skal eksisterende katalogtjeneste basert på Microsoft Active Directory benyttes.	H/B
7.1.15	Alle tjenerne skal inngå i Sykehuspartner sitt automatiske patche regimet som innebærer automatisk installasjon av godkjente Windows oppdateringer innenfor kategoriene kritiske- og sikkerhetsoppdateringer. Servere klassifiseres i forhold til hva disse er usatt for av trusler. F.eks. mest utsatt = DMZ servere, mindre utsatt = interne servere og om brukerne er berørt ved installasjon av patch. Patcher og oppdateringer klassifiseres i forhold til viktighet, sikkerhet. Dette patch management regimet følger Sykehuspartner sin prosess for change management, som blant annet inkluderer prosedyrer for test, godkjenning, rollback osv.	H
7.1.16	Alle tjenere blir levert med antimalware beskyttelse. Behov for eventuelle ekskluderinger eller andre tilpasninger skal beskrives av Leverandør	H/B
7.1.17	Alle tjenester må starte automatisk ved restart. Det skal ikke være behov for manuelle rutiner rundt oppstart av tjenester etter en omstart av tjener.	H

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
7.1.18	Alle programmer må kunne startes som servicer, ikke pålogget desktop på server. Det skal ikke være behov for manuelle innlogging av driftspersonell for å starte opp tjenester etter en omstart av server.	H
7.1.19	Bør støtte dynamiske innstillinger (FQDN, DFS, UNC etc.). Det er ikke ønskelig å benytte IP adresser og andre statiske verdier i konfigurasjonen. Dette bør i stedet håndteres ved bruk av FQDN ved referanse til tjenernavn osv.	B
7.1.20	Applikasjoner må støtte installasjon på annet enn system (C) disk. Det er ønskelig å holde applikasjoner adskilt fra systemdisk, og applikasjonene må derfor kunne støtte installasjon på annen stasjonsbokstav.	H
7.1.21	Løsningen bør ikke kreve fysiske “dongle” eller annet fysisk tilkoblet utsyr på tjeneren.	B
	Applikasjonsleveranse
7.1.22	Applikasjonen med alle plugins skal kunne installeres og kjøres uten utvidede rettigheter på klienten. Med dette menes standard brukerrettigheter.	H/B
7.1.23	Programvare leveres som ferdige installasjonspakker som MSI fil og etter gjeldende format etter foretakets standarder.	H
7.1.24	Applikasjonen må kunne la seg distribueres med leveranseverktøy som SCCM og App-V for Windows 7 eller nyere og Windows Server 2003 eller nyere.	M/B
	Nettverk
7.1.25	All kommunikasjon skal være basert på IP protokoll (versjon 4 og 6). Dette gjelder både intern og ekstern kommunikasjon.	H
	Lagring, Backup og Restore
7.1.26	Det benyttes sentral SAN-løsning ved Helseforetaket og det er en forutsetning at tilbudt løsning tar i bruk denne fullt ut ved behov for lagring til SAN. Det er også etablert sentralisert backup løsning.	I
7.1.27	Backup av løsningen skal i sin helhet kunne foretas av en sentralisert backup løsning. Backup av system- og brukerdata som er lagret sentralt, skal ikke påvirke ytelsen, ved normal	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	belastning, slik at brukerens opplevde kvalitet av løsningen reduseres.
7.1.28	Applikasjonen skal kunne speiles mellom to datasenter. Leverandøren bes å beskrive anbefalt løsning for HA løsning.	H/B
7.1.29	Applikasjonen skal kunne konfigureres til å kunne arkivere data ut fra konfigurerbare policies til forskjellige lagringsnivåer i kundens lagringsløsninger. Dette må kunne gjøres både automatisk og manuelt. Eksempel: historikk er online i løsningen, men lagres på rimeligere medium enn nyere data.	H/B
7.1.30	Tilbyder skal dokumentere og redegjøre for backup og restore rutiner.	H/B
	Overvåking
7.1.31	Alle deler av løsningen skal kunne sende og motta data fra/til ett sentralt overvåkningssystem. Spesifiser hvilke slike som støttes uten modifikasjoner utover leveransen.	H/B
	Klientapplikasjon
7.1.32	Klientapplikasjon skal kunne installeres på Microsoft Windows 7 eller nyere etter helseforetakenes mal. Beskriv også hvilke operativsystem som støttes utover dette.	H/B
7.1.33	Klientapplikasjonen / eventuelle applets og oppdateringer må kunne distribueres ved bruk av pakkeverktøy. Redegjør for eventuelle forutsetninger og begrensninger.	H/B
7.1.34	Applikasjonen skal ikke påvirke kjøring av annen 0.xxxxx programvare på klienten.	H
7.1.35	Alle applikasjonsfeil skal rapporteres inn / logges i operativsystemets standard hendelses logg med en forståelig feilkode.	H/B
7.1.36	Applikasjonen skal kunne pakkes og streames ut til klient. Dette for blant annet å kunne kjøre flere versjoner i parallell. Dette for både applikasjonen som leveres og tilhørende 3.partskomponenter.	H/B
7.1.37	Klientapplikasjon skal kunne installeres på Citrix plattform basert på Microsoft Windows Server 2003 eller nyere i henhold til Sykehuspartner GPL. Beskriv også hvilke operativsystem som støttes	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	utover dette.
7.1.38	Applikasjonen med alle plugins skal kunne kjøres uten utvidede rettigheter på klienten. (Standard brukerrettigheter)	H
7.1.39	Applikasjonen må kunne til enhver tid kjøres med de siste patcher fra Microsoft.	H
7.1.40	Applikasjonen må kunne til enhver tid kjøres med de siste patcher fra de ledende arbeidsflateverktøy i markedet.	H
7.1.41	Klientprogramvaren må kunne kjøres på systemet med oppdatert antimalware av typen Trend Office Scan eller Microsoft Forefront Client Security i henhold til Sykehuspartner GPL. Der klientprogramvaren krever en antimalware policy eller exclude regelsett må dette redegjøres for.	H/B
	Terminalservere
7.1.42	Klientprogramvaren skal kunne kjøres på terminalserver basert på Windows server 2008 Citrix XenApp 5.0 og høyere i henhold til Sykehuspartner GPL.	H
7.1.43	Applikasjonen skal kunne pakkes og streames ut til terminalservere. Dette for blant annet å kunne kjøre flere versjoner i parallell. Dette for både applikasjonen som leveres og tilhørende 3.partskomponenter.	H
7.1.44	Klientprogramvaren må kunne kjøres på systemet med oppdatert antimalware av typen Trend Office Scan eller Microsoft Forefront Client Security i henhold til Sykehuspartner GPL. Der klientprogramvaren krever en antimalware policy eller exclude regelsett må dette redegjøres for.	H/B
7.1.45	Som overvåkningsverktøy vil det benyttes Microsoft System Center Operations Manager 2007 eller nyere i henhold til Sykehuspartner GPL.	I
7.1.46	Nødvendige printerdrivere som følger med løsningen må være Citrix sertifiserte.	H/B
7.1.47	Applikasjonen må kunne til enhver tid kjøres med de siste patcher fra Citrix.	H/B
7.1.48	Applikasjonen med alle plugins skal kunne kjøres uten utvidede rettigheter. (Standard brukerrettigheter)	H
	VPN og fjerndriftsløsninger
7.1.49	Dersom Leverandøren ønsker tilgang til	H

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	Kundens system skal dette kun kunne gjøres etter særskilt avtale med Kunden.
7.1.50	På forhånd skal det gjennomføres en risikovurdering av de løsninger som skal etableres i forbindelse med fjernoppkobling. Leverandøren er ansvarlig for å gjennomføre vurderingen i tett samarbeid med Kunden og Sykehuspartner.	H/B
7.1.51	Leverandøren skal benytte Kundens standard sikkerhetsløsning for fjernoppkopling.	H
7.1.52	Fjerndrift utføres via en sikker portalløsning hvor leverandøren vil logge inn med personlige brukerkontoer. Fra denne portalen vil det være mulig å logge inn på aktuelle servere via RDP eller lignende teknologi. Leverandøren vil få delegert nødvendige rettigheter til å utføre sine drifts-/forvaltningsoppgaver til sine personlige brukerkontoer.	I
7.1.53	F5 Firepass og F5 Big-IP løsning med SMS for 2 faktorautentifisering hvor AD passord ikke blir eksponert på klienten. Smartkort vil etter hvert kunne bli et krav.	H
7.1.54	SMS kode er personlig og brukeren av systemet må være personlig. Fellesbrukere er ikke tillatt. Brukeren/firmaet må gi en del opplysninger for å få tilgang til fjerndriftløsninger. Dette vil være mobiltelefon nummer og personalia inkludert person nummer.	H
7.1.55	For å få tilgang må bruker/firma akseptere gjeldende dokumenter som sluttbruker policy, taushetserklæring, databehandleravtale osv.	H
7.1.56	Applikasjonen må kunne la seg publiseres og supporteres via F5 Firepass og F5 BigIp. Det må beskrives innstillinger som er nødvendig for å få dette til.	H/B
7.1.57	Løsningen støtter kun pålogging fra Windows operativsystem.	H
	Generelle printløsninger
7.1.58	Tjenesten må benytte sentral Windows print tjeneste, ikke egen løsning for utskrifter.	H/B
7.1.59	Der det er behov for andre printere enn definert i Sykehuspartner GPL må dette spesifiseres i tilbudet.	H

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
7.1.60	Drivere skal ikke påvirke printsystemet.	H
7.1.61	Drivere må være Citrix sertifiserte.	H
7.1.62	Nødvendige printere og dens spesialfunksjoner som stift, hulling, brett osv må støttes av Unidrivere.	H/B
7.1.63	Tjenesten må støtte Follow me print løsninger.	H/B
	Integrasjon systemer /Utvikling
7.1.64	Sikkerhet: Pasientnavn som er hentet ut fra PAS/EPJ skal ikke endres i systemet.	H/B

7.1 Nytt sykehus, Kalnes

Løsningen bør gi frihet til å organisere systemforvaltning og drift slik det er mest hensiktsmessig for kunden. Samtidig er det ønskelig at systemet skal passe inn i eksisterende driftsmodell før flytting til nytt sykehus.

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	Systemforvaltning
7.1.1	Beskrive eventuelle tekniske forhold som tilsier en spesiell organisering av systemforvaltning og drift. Dette kan f.eks. være ved fordeling av systemdrift og applikasjonsdrift.	M/B
7.1.2	Beskriv preferert driftsplattform for løsningen, og anbefalt design for HA løsning (high availability).	H/B
7.1.3	Leverandøren skal også gjøre rede for hvilke alternative plattformer løsningen kan kjøres på. Leverandøren skal beskrive sine planer for å støtte nye versjoner av OS og database plattformer.	H/B
7.1.4	Leverandøren bør beskrive sine planer for flytting av applikasjonen til nye teknologiplattformer.	M/B
7.1.5	Leverandøren skal beskrive særskilte krav løsningen stiller til Kundens it- infrastruktur. Dette kan f.eks. være krav til hastighet på lagring osv.	H/B
7.1.6	Leverandøren skal beskrive eventuelle forbehold eller betingelser knyttet til hastighet på datalinjer og evt. øvre grenser for forsinkelse i nettet ved en sentralisert driftsmodell skal dette	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	beskrives.
7.1.7	Alle porter og protokoller som applikasjonen bruker skal spesifiseres / beskrives.	H/B
7.1.8	Beskriv anbefalinger med hensyn til forskjellige scenarier for reetablering av tjenesten når brudd eller tap av data inntreffer (skyggesystem, restore, rollback, med mer), herunder hvordan løsningens database løser problematikk knyttet til korrupte og logiske feil i databasen	H/B
	Distribusjon Det legges opp til en fleksibel distribusjon av applikasjonen ut til alle klienter i henhold til eksisterende driftsmodell. Det bes derfor om at leverandøren beskriver følgende:
7.1.9	Hvor alle klient-, print- og andre sluttbrukerutstyrs-innstillinger konfigureres/lagres.	H/B
7.1.10	Systemets bruk av tilleggsprogramvare (applets), andre applikasjoner, samt versjonskrav til disse skal beskrives. Eksempler på dette er .NET Framework, Java, Java Runtime, Flash.	H/B
7.1.11	Minstekrav til klientens maskinvare, herunder prosessor, minne, skjermkort, skjermoppløsning, skjermstørrelse, harddiskstørrelse og nettverkshastighet.	H/B
7.1.12	Hvilken programvare og plugins som må installeres på den enkelte klient, samt versjoner av disse. Bruk av Java- applets, ActiveX, .NET, Flash og tilsvarende skal dokumenteres.	H/B
7.1.13	Hvor innstillinger for sluttbrukerutstyr konfigureres/lagres, samt angi hvorvidt dette skjer i ini-filer/databasen eller Windows systemoppsett.	H/B
7.1.14	Alle av applikasjonens brukerspesifikke innstillinger, hvorvidt dette ligger i Ini- filer/databasen eller Windows systemoppsett etc, må kunne virtualiseres med ledende arbeidsflateverktøy i markedet.	H/B
7.1.15	All nødvendig konfigurasjons innstillinger og veiledninger for å kunne ferdigstille en fungerende MSI-pakke for	H/B

Beskrivelse av krav

Krav kategori H/M/L/

(B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

distribusjon av applikasjonen.

7.1.16

Angi minimum og anbefalt krav til CPU og minne for hver brukerprosess i en terminalserverløsning for applikasjonen.

H/B

8 Sikkerhet

Generelt:

• Fysisk sikkerhet – definerer hvilke sikringstiltak som skal etableres i de områder hvor IKT-utstyr er fysisk plassert og IKT-Infrastruktur er etablert

• Nettverkssikkerhet – definerer sikringstiltak som skal etableres på nettverksnivå (tilsvarer lag 1-3 i OSI-modellen) infrastrukturen

• Servere og sesjons sikkerhet – definerer sikringstiltak som skal etableres i forbindelse med servere og lagring av data, og hvordan data overføres mellom ulike servere og mellom servere og brukere (dvs. lag 4-5 i OSI-modellen)

• Applikasjonssikkerhet – definerer sikringstiltak knyttet til tilgang til applikasjoner og data som disse bruker. (dvs. lag 7 i OSI-modellen)

Videre ivaretar arkitekturen retningslinjer for:

• Administrasjon av tilgangskontroll til systemer, funksjoner og informasjon

• Administrasjon og overvåking av sikkerhetsfunksjonene som implementeres.

I neste avsnitt er ulike krav innenfor disse områdene sammenfattet som den enkelte entreprise må forholde seg til. Det er skilt mellom:

• Generelle krav som gjelder alle løsninger som skal tilknyttes den felles IKT infrastrukturen

• Spesifikke krav for løsninger som håndterer foretakssensitive opplysninger og/eller tekniske styrings/overvåkingssystemer

• Spesifikke krav til løsninger og utstyr som håndterer personsensitive opplysninger iht. personopplysningsloven. (dvs. hvor i utstyret det lagres informasjonen)

I forbindelse med IKT-systemer som håndterer sensitive personopplysninger, vil det bli gjennomført en risiko og sårbarhetsanalyse i forhold til informasjonssikkerhet for å vurdere forhold rundt konfidensialitet, integritet og tilgjengelighet.

8.1 Krav til informasjonssikkerhet

Følgende lover med forskrifter gir føringer og krav til informasjonssikkerhet:

Følgende lover/forskrifter har relevans for denne anskaffelsen og leverandøren skal beskrive hvordan han ivaretar disse gjennom sin løsning:

▪ Lov om helseregistre og behandling av helseopplysninger (Helseregisterloven)

▪ Lov om helsepersonell m.v. (Helsepersonelloven)

▪ Lov om behandling av personopplysninger (Personopplysningsloven)

Følgende spesifikke krav gjelder:

Område

Generelt

Foretakssensitive opplysninger og

styrings-/overvåkingssystemer

Sensitive personopplysninger (Lokal

lagring på utstyrsenhet)

Fysisk sikkerhet

• I områder uten fysisk sikring (adgangskontroll, låsbare rom) skal alt utstyr som tilkoples nettet autentiseres før tilkopling til nettverket, alternativt vil utstyret bli å betrakte som tilknyttet i åpen sone. (usikret sone).

• Utstyr som plasseres i kommunikasjonsrom vil bli plassert i låsbare skap adskilt pr. driftsområde.

• Tilgang til kommunikasjonsrom vil kunne gis i følge med autorisert personell, eller etter nærmere avtale.

• Enkelte rom / områder / kabelgater etc vil kunne ha spesielle krav til sikring (brannsoner, brannslukking,

branndeteksjon, ikke vannrør i tak, EMP-sikring, mv).

• Tilgang til utstyret og tilhørende nettverkspunkter skal fysisk sikres, dvs. beskyttes av adgangskontroll eller annen fysisk sikring (låsbare rom/skap).

• Utstyr skal autentiseres.

• Utstyret må fysisk sikres og autentiseres (ie. fysisk adgangskontroll for tilgang til utstyret eller plassering i låsbare rom/skap), og brukere må logge på med sterk autentisering.

Nytt logistikksystem sterilsentralene K Bilag 1 Kundens kravspesifikasjon

Område

Generelt

Foretakssensitive opplysninger og

styrings-/overvåkingssystemer

Sensitive personopplysninger (Lokal

lagring på utstyrsenhet)

Nettverks- sikkerhet

• Etablering av ulike sikkerhetssegmenter innenfor sykehusområdet.

• Innenfor hver sone skilles det mellom bruker soner (brukerutstyr/klientutstyr) og tjeneste soner (Servere).

• Alt brukerutstyr som tilkoples skal autentiseres før bruk (802.1x).

• I trådløse nett etableres kun standardiserte sikkerhetsløsninger (802.1x).

• All tilgang til Internett skal skje via Sykehuspartner sin Internettløsning.

• Fjernaksess via Internett for leverandører tillates kun mot spesifikke logiske nett.

• Definerte aktiviteter skal loggføres til en skrivebeskyttet logg.

• Servere plasseres i Interne tjeneste soner.

• Avhengig av brukerutstyrets egenskaper og funksjoner vil utstyret bli lokalisert til ulike interne bruker soner.

• Generelt brukerutstyr skal kunne benyttes mot ulike tekniske anlegg og systemer.

• Stasjonært utstyr som lagrer sensitive personopplysninger må enten plasseres i Sikre tjenestesoner eller ”lagringsenheten” på enheten må krypteres i henhold til gitte krav.

• Mobilt utstyr som lagrer sensitive personopplysninger skal ”lagringsenheten” på enheten alltid krypteres i henhold til gitte krav.

• Det må benyttes sterk autentisering i forbindelse med pålogging.

• Dedikert utstyr tilkoples funksjonsorienterte logiske nett (sikre soner).

• For dedikert utstyr i trådløse løsninger skal det etableres særskilte sikringstiltak som ivaretar

sikkerhetsprinsippene i helsesektoren.

Område	Generelt	Foretakssensitive opplysninger og styrings-/overvåkingssystemer	Sensitive personopplysninger (Lokal lagring på utstyrsenhet)
Klient, server og sesjons- sikkerhet	• Utstyr med virksomhetskritisk funksjonalitet skal ha redundant tilknytning til nettverket/infrastrukturen. • Alle standard PC’er/brukerutstyr skal konfigureres sentralt, og konfigurasjon skal overvåkes sentralt. • PC’er/brukerutstyr hvor konfigurasjon er endret uautorisert skal automatisk ”retankes”. • Det skal ikke være mulig for lokal bruker å legge inn ny programvare som ikke er forhåndsgodkjent. • Kryptering skal baseres på internasjonale standarder. • Kontroll av ondsinnet programvare skal gjennomføres på alt generelt brukerutstyr før pålogging til nettverket. • Definerte aktiviteter skal loggføres til en skrivebeskyttet logg.	• Fjerndrift skal være mulig. • Tilgang iht. brukeravtale med Leverandør.	• Kun eksplisitt definert trafikk vil bli tillatt mellom ulike tjenestesoner og til/fra systemer i sikre tjenestesoner. • Det skal være mulig å slette informasjon på utstyrsenhet som kan lagre sensitive personopplysninger. • Fjerndrift tillates kun med bruk av sterk autentisering mot spesielle logiske nett (ie. utstyrsenhet må fysisk flyttes/koples til et ”servicenett”). • Alle funksjoner og tjenester som ikke er i bruk på en server/klient skal være avslått/fjernet. Dette gjelder både OS funksjoner og basis-applikasjoner. • Bruker/klientutstyr hvor konfigurasjon er endret vil ikke få tilgang til nettet før konfigurasjon er oppdatert.
Applikasjons- sikkerhet	• Definerte aktiviteter skal loggføres til en skrivebeskyttet logg.	• Pålogging kan tillates fra navngitte brukere (brukerid/passord). • I forbindelse med fjerndrift skal leverandørens bruker logges på med brukerid/passord, alt. Benytte sterk autentisering.	• Pålogging skal kun tillates fra navngitte brukere med bruk av sterk autentisering (token).
Administrasjon av tilgangskontroll	• Opprettelse, endring og sletting av brukere i tilknytning til en applikasjon skal loggføres. • Tilgang til funksjoner i en applikasjon skal kunne være rollebasert. • Definerte aktiviteter skal loggføres til en skrivebeskyttet logg.		• Tilgangskontroll skal integreres med katalogtjenesten.

Beskrivelse av krav

Krav kategori O/H/M/

L/ (B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

8.1.1

Leverandør skal beskrive sin løsning basert på kravene over.

Hvis en eller flere av kravene ikke er relevante for denne leveransen så må leverandør kommentere dette.

H/B

9 Krav til integrasjoner

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	Felles krav for alle integrasjoner
9.1.1	Brukerinformasjon og pålogging skjer gjennom integrering mot Microsoft Active Directory versjon 2003 og nyere. I tillegg mulighet for lokalt definerte brukere i applikasjonen.	H/B
9.1.2	Tilbyder skal redegjøre for bruk av nasjonale standarder – for eksempel definert av KITH eller Brønnøysundregistrene, eksempelvis HL7 v3, GS1 og HR-XML, mot de forskjellige opsjoner.	H/B
9.1.3	Løsningens integrasjonsrammeverk skal ha åpne (SOA) og vel definerte grensesnitt for datautveksling med andre moduler og systemer.	H/B
9.1.4	Alle Løsningens systemgrensesnitt bør ha standard funksjoner for import og eksport av data med konfigurerbar validering av importerte / eksporterte data.	H/B
9.1.5	Alt av informasjon/statuser skal vises i skjermbilde / arbeidsflate for brukere av fagsystemet.	H/B
9.1.6	Leverandør har totalansvar for oppfølging og tilpasninger av integrasjoner opp mot andre leverandører.	H/B

10 Opsjoner

Opsjoner beskriver funksjoner som SØ pr dags dato ikke har konkrete planer om. Det vil si at det er usikkert hvorvidt de vil bli benyttet.

10.1 Generelt

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
10.1.1	Tilbyder skal redegjøre for type grensesnitt for integrasjon med de enkelte systemene nedenfor.	H/B
10.1.2	Leverandør skal legge frem et forslag som omfatter system opsjonene der det beskrives type funksjonalitet og grensesnitt som kan leveres.	H/B
10.1.3	Leverandør skal i samarbeid med kunde utarbeide hvilke funksjonalitet som skal innføres på en eller flere opsjoner som	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
	velges.
10.1.4	Hver opsjon skal prissettes uavhengig av de andre opsjonene.	H
10.1.5	Ønsker leverandør å tilby andre tilleggsmoduler som kan være av interesse, vennligst beskriv de. Prises inn i prisskjemaet.	M/B

10.2 GAT Turnus

GAT turnus brukes til styring av personalressurser ved sykehuset. Det er ønskelig med en integrasjon mot det nye systemet for å kunne ressurs planlegge.

Beskrivelse av krav

Krav kategori H/M/L/

(B)/I

Møter krav Ja/Nei

Leverandørens svar/kommentarer

10.2.1

Tilbyder skal legge frem hvilke muligheter/løsninger som finnes for utveksling/behandling av data mellom

GAT og systemet.

H/B

10.3 Operasjonsplanlegging

Leverandør må skissere en løsning for integrasjon mot eksisterende operasjonsplanleggingsmodul. Dette er nødvendig for å sikre at alle nødvendige instrumenter, implantater og forbruksvarer til tilgjengelig i forbindelse med gjennomføring av det operative inngrep.

Dips operasjonsplanleggingsmodul benyttes ved sykehuset, og det er ønskelig at det nye systemet skal kunne integreres og tilpasses denne, eller annen aktuell modell.

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
10.3.1	Det er ønskelig at leverandør kommer med innspill på hvilke type løsninger som kan tilbys for å få til en god integrasjon mot operasjonsmodulen til Pas/Epj.	H/B
10.3.2	Data skal oppdateres begge veier.	H/B
10.3.3	Oppdateringer mot PAS/EPJ skal kunne gjøres kontinuerlig for at pasientinformasjon til enhver tid skal være riktig.	H/B
Punktene under viser eksempler på hva en slik tjeneste bør inneholde:
10.3.4	En eller flere brikker vil bli reservert opp mot hver operasjon som legges inn i Pas/Epj.	H/B
10.3.5	Det er ønskelig at man skal kunne bestille brikker iht. til de operasjonene som skal utføre via grensesnitt i Pas/Epj.	H/B
10.3.6	Man skal kunne se hvilke brikker som er tilgjengelig til enhver via Pas/Epj grensesnitt.	H/B

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
10.3.7	Flytting av operasjoner vil kun aksepteres hvis det er tilgjengelige brikker, kan overstyres hvis andre parametere er satt.	H/B
10.3.8	Sletting av operasjoner frigjører brikker som er reservert.	H/B
10.3.9	En oversikt over alle brikker som skal benyttes bør kunne vises i Pas/Epj.	H/B
10.3.1	En oversikt over hvilke brikker som er reservert og til hvilken operasjon de skal benyttes.	H/B
10.3.1	Backup brikker/instrumenter bør også kunne vises på en slik måte at de kan hentes ut når behovet er tilstede.	M/B
10.3.1	Basert på type operasjon bør løsningen kunne vise anbefalte brikker/instrumenter som er tilgjengelig.	M/B
10.3.1	Systemet skal vise oversikt over elektive og øyeblikkelig hjelps operasjoner.	H/B
10.3.1	Alle punktene over vises i sanntid via grensesnitt i Pas/Epj.	H/B

10.4 Løsning for sporing

Sykehuset ønsker at leverandøren kommer med forslag på forskjellige sporingsløsninger for eksempel RFID/ultralyd løsninger for å lette sporingen av brikker og eventuelt instrumenter ved sykehuset.

Nr	Beskrivelse av krav	Krav kategori H/M/L/ (B)/I	Møter krav Ja/Nei	Leverandørens svar/kommentarer
10.4.1	Beskriv hvordan denne type teknologi kan benyttes sammen med Systemet	H/B
10.4.2	Beskriv hvordan en slik løsning kan automatisere forskjellige oppgaver.	H/B
10.4.3	RFID løsningen skal til enhver tid oppdatere systemet slik at status på brikker vises.	H/B
10.4.4	Systemet bør, basert på RFID, kunne gi nøyaktig posisjon på hvor den enkelte brikke er og dette bør kunne vises/benyttes i systemet.	M/B
10.4.5	Leverandøren må beskrive hvordan man ved hjelp av denne type teknologi kan begrense hvis brikken beveger seg utenfor ett område som er fastsatt.	H/B
10.4.6	Når en brikke blir flyttet på så er det ønskelig at systemet blir oppdatert slik at brikken lett kan spores.	H/B
10.4.7	Leverandør må beskriv type teknologi som må være tilstede for å kunne innføre RFID.	H/B

Document Metadata

Table of Contents

Innholdsfortegnelse

Document Metadata