KRAVSPESIFIKASJON Standard for pasientvarsling, trygghetsalarm og velferdsteknologi (Trygghetssystem) Fredrikstad kommune IT-avdelingen 1
Innhold 1. Innledning... 4 2. Anskaffelsens formål... 4 2.1.1. Resultatmål... 4 2.2. Omfang og volum i anskaffelsen... 5 2.2.1. Pilotmiljø... 5 2.2.2. Avrop på rammeavtalen... 5 2.2.3. Opsjoner... 6 2.3. Forbehold om økonomiske ressurser, årlige budsjetter... 6 2.4. Pilotprosjekt og utviklingsarena... 7 2.4.1. Teknologi, standardisering og brukerdrevet utvikling... 8 2.4.2. Organisasjon, tjenester og aktører... 9 2.5. Utviklingsavtale... 10 3. Funksjonsbeskrivelse for leveransen... 11 3.1. Generell funksjonalitet trygghetssignal (leveranse og pilotering)... 11 3.2. Generell funksjonalitet overvåkingsalarmer (pilotering og opsjon)... 12 3.3. Generell funksjonalitet kommunikasjon (leveranse og pilotering)... 13 3.4. Monitorering og oppfølging av helseverdier (pilotering og opsjon)... 13 3.5. Generell funksjonalitet - omgivelseskontroll og smarthus (pilotering og opsjon)... 13 3.6. Generell funksjonalitet velferdsteknologi (pilotering og opsjon)... 14 3.6.1. Kategorier velferdsteknologi... 14 3.7. Mottak og oppfølging (leveranse og pilotering)... 15 3.8. Administrasjon... 16 4. Tekniske rammebetingelser... 17 4.1. Eksisterende IKT plattform... 17 4.2. Sikkerhetsarkitektur... 17 4.2.1. DMZ... 18 4.2.2. Åpen sone... 18 4.2.3. Lukket sone... 18 4.3. Overordnede arkitekturprinsipper... 18 4.4. Nettverk og infrastruktur... 19 4.4.1. Privat bolig... 19 4.4.2. Institusjon... 19 4.5. Merkesystem... 20 4.6. Integrasjoner... 20 4.6.1. EPJ system... 20 2
4.6.2. Telefoni LYNC SIP... 20 4.6.3. Porttelefon, alarmanlegg og SD anlegg... 21 4.6.4. Smarthusinstallasjon... 21 4.7. Redundans... 21 4.8. Sentralisert styring, drift og overvåking... 22 4.9. Synkronisering... 22 4.10. Prosjektgjennomføring... 22 4.11. Kompetanse og opplæring... 22 4.12. Dokumentasjon... 22 5. Kravtabell... 23 5.1. Veiledning til kravtabellen... 23 5.2. Fredrikstad kommunes krav - Standard for pasientvarsling, trygghetsalarm og velferdsteknologi (Trygghetssystem)... 24 VEDLEGG 1. Oversikt over mulige opsjoner... 29 VEDLEGG 2: Kilder... 32 3
1. Innledning Fredrikstad kommune ønsker en innovativ prosess for anskaffelse og utvikling av en helhetlig plattform for pasientsignal, trygghetsalarm og velferdsteknologi (Trygghetssystem). Ønsket er å etablere en rammeavtale med en hovedleverandør som kan være med å bygge en samlet plattform for trygghetssystem for bolig og institusjon og utvikle, pilotere og tilpasse trygghetspakker og velferdsteknologiske hjelpemidler på en åpen teknologisk plattform. Det er viktig å presisere at vi ønsker en trinnvis, kvalitetssikret utvikling med fokus på å få etablert en plattform med basis i trygghetssignal for bolig og institusjon og med en pilotering av øvrig velferdsteknologi for en framtidig driftssetting. 2. Anskaffelsens formål Anskaffelsens formål er: - Anskaffelse av førstegangs etablering av et standard trygghetssignalsystem og kommunikasjonsplattform (systemkjøp) - Anskaffelsen skal danne grunnlag for en felles åpen plattform for velferdsteknologi - Pilotere og utvikle trygghetspakker med velferdsteknologi i et samarbeid med hovedleverandør og underleverandører for både bolig og institusjon - Etablering/anskaffelse av fysiske nye anlegg Trygghetssystemet i Fredrikstad skal virkeliggjøre et trygghetssignal for både bolig og institusjon der første fysiske anlegg vil være sengeposter ved det nye helsehuset (høst 2013) og utskifting av dagens system for trygghetsalarmer i bolig. esenior prosjektet i Fredrikstad ønsker å pilotere og utvikle velferdsteknologiske løsninger i samarbeid med leverandør og andre samarbeidspartnere. Fredrikstad er deltaker i EU prosjektet esenior sammen med Oslo, Sarpsborg og Gøteborg, der org Innovasjon er prosjektleder. Prosjektet har som mål å pilotere trygghetspakker med velferdsteknologi for seniorer for at de kan bo lenger hjemme med god trygghet og livskvalitet. Fredrikstad kommune skal ha minimum 25 piloter i private boliger som skal prøves ut 2012-2014. Prosjektet er del av Interreg IVA-programmet og delfinansiert av EU, norske interregmidler, de fire deltakende kommunene og Østfold fylkeskommune. Trygghetssystemet som anskaffes skal ha åpen teknologisk plattform for velferdsteknologi med basis funksjonalitet for trygghetssignal for både bolig og institusjon. Velferdsteknologiske løsninger for å skape trygghet, velvære, egenmestring og aktivitet ønskes utviklet, pilotert og etablert på plattformen i et samarbeid med hovedleverandør og samarbeidspartnere. Anskaffelsen skal etablere et systemkjøp av nye anlegg i både nye bygg og renovering av eksisterende bygg. 2.1.1. Resultatmål 1. Felles rammeavtale for trygghetssignal og velferdsteknologi for bolig og institusjon 2. Pilotere velferdsteknologi for bolig og institusjon: esenior trygghetspakker for seniorer 2012-2014 Visningsleilighet for velferdsteknologi 2012 2014 Pilot trygghetssignal i institusjon og omsorgsbolig - 2013 3. Installere ny plattform med basisfunksjonalitet for trygghetssignal og kommunikasjon: Etablere sentral driftssentral 2013 4
Helsehus med sengeposter høsten 2013 Nytt sykehjem på Østsiden høsten 2014 4. Vurdere opsjoner 2014: Grunnfunksjonalitet trygghetssignal, kommunikasjon og velferdsteknologi for alle sykehjem og institusjoner etter vedtatt rehabiliteringsplan ytte ut dagens trygghetsalarmsystemer og ansattalarmer. Utbredelse av utvidet trygghetspakker og tiltak for seniorer, kronikere og andre brukergrupper i egen bolig 2.2. Omfang og volum i anskaffelsen Fredrikstad kommune legger til grunn at det skal inngås 2 års rammeavtale med leverandør med opsjon på 1+1 år, på leveranse av plattform og anlegg for trygghetssignal og velferdsteknologi med prosjektering, utstyrsleveranser og tilhørende tjenester for installasjon, integrasjon, drift, support, dokumentasjon, opplæring og service av plattformen. 2.2.1. Pilotmiljø Som første avrop på rammeavtalen skal det legges til rette for et pilotmiljø for pilotering og utvikling av Trygghetssystemet med et utvalg piloter hver enkelt installasjon som avrop på rammeavtalen: Forslag piloter for Trygghetssystem: Lokalisering esenior- Kråkerøy og Holmen Holmen oform/ Tjeneste Private boliger og omsorgsboliger Visningsleilighet velferdsteknologi Rom/ boliger Min 25 Max 40 Pilotering Trygghetspakker og øvrig velferdsteknologi 1 Visning og utprøving av teknologi, innredning og utstyr. Fjeldberg Omsorgsboliger 28 Trygghetssignal + overvåkingsalarm Solliheimen Sykehjem, 1 korttidsavdeling Smedbakken Sykehjem for brukere med demens 17 Trygghetssignal evt. inn mot erom 8 Trygghetspakker og øvrig velferdsteknologi Merknad Pilotprosjekt for tilpasning av trygghetspakker for hjemmeboende eldre 2013 til 2015 Samarbeid med Lions Fredrikstad og samspill med NAV hjelpemiddelsentralen. 2013-2015 Omsorgsboliger samlokalisert med Fjeldberg sykehjem. Pilotering og drift. Pilotering av pasientsignal og senere annen velferdsteknologi. Kan evt. erstattes av Helsehuset. Pilotere trygghetssignal og velferdsteknologi som en forberedelse av Østsiden sykehjem På grunn av tidspress i ferdigstillingen av Helsehuset 2013 må det vurderes om en eller flere av etasjene ved Helsehuset blir å betrakte som pilot. Dette kan gå på bekostning av gjennomføringen av flere av de andre pilotene. 2.2.2. Avrop på rammeavtalen Det er avklart at det skal gjøres følgende avrop på rammeavtalen i henhold til: ygging av sentral driftsplattform med infrastruktur Sengeposter ved nytt Helsehus, 39 senger med tilhørende fellesrom og sanitære rom Østsiden sykehjem, 64 senger og 12 dagplasser med tilhørende fellesrom og sanitære rom 5
500 trygghetsalarmer Detaljert oversikt for anskaffelsen avrop på rammeavtalen Lokalisering Helsehus oform/ Tjeneste Rom/ boliger 39 rom Teknologi Merknad - 1. etg. Legevakt, feltpleie og overgrepsmottak - 2. etg. Sengepost øyeblikkelig hjelp og behandlingssenger - 3. etg. Sengepost for rehabilitering - 4. etg. Kontorer og samtalerom 7 rom Trygghetssignal og kommunikasjon. Voldsalarm for ansatte. 20 rom Trygghetssignal og kommunikasjon 12 rom Trygghetssignal og kommunikasjon Voldsalarm for ansatte i rus og psykiatritjenesten Mulig pilotering av monitorering og samhandling sykehus Som over Nytt sykehjem Østsiden Sykehjem 65 rom + 12 dagplasser Trygghetssignal, kommunikasjon Primær brukergruppe: brukere med demens oliger Omsorgsboliger og private boliger Min 500 Trygghetssignal og kommunikasjon ytte ut dagens analoge alarm 2.2.3. Opsjoner Alle pilotene beskrevet i kapittel 2.3.1 er å betrakte som opsjoner/mulige avrop på rammeavtalen. Kommunens prosjekt for innovativ velferdsteknologi har som intensjon å bytte ut dagens plattform og utstyr for trygghetsalarm i boliger. Dessuten skal det lages en renoverings- og fornyelsesplan for kommunens institusjoner. Dagens trygghetsalarmer på ca. 500 enheter bør i kontraktsperioden øke til 2500 enheter. Trygghetsalarmen ønskes utvidet med flere standard trygghetspakker med velferdsteknologi basert på erfaringene fra piloteringen i esenior. Antall berørte institusjoner som kan berøres av rehabilitering og utskifting av pasientsignalanlegg er 10 sykehjem og 21 anlegg for omsorgsboliger med til sammen 720 rom/boliger ut over sengeposter ved Helsehuset 2.3. Forbehold om økonomiske ressurser, årlige budsjetter Realisering av det anslåtte volumet forutsetter at det bevilges midler over kommunens årlige budsjett som stilles til rådighet for prosjektet i avtaleperioden for rammeavtalen. Det legges opp til en politisk behandling av skifte av plattform for dagens trygghetsalarm og rehabilitering og plan for fornyelse av pasientsignalanleggene i kommunens institusjoner etter gjennomført pilotperiode. Kommunen vil avholde minimum halvårlige møter med leverandøren for å gjennomgå hvordan rammeavtalen fungerer. I disse møtene vil bl.a. status og gjennomgang av planer for budsjettperiodene være et fast tema. 6
2.4. Pilotprosjekt og utviklingsarena Det er viktig å få gjennomført pilotering av ny plattform for trygghetssignal før utrulling til sengeposter på nytt sykehjem på Østsiden og utskifting av dagens trygghetsalarmer. Helsehuset vil bli det første store anlegget som skal settes i drift en mulig pilotering her bør kunne skje i faser og med mulig større medisinsk fokus enn på de andre institusjonene. Men det er behov for flere løp med pilotering og utvikling. Grunnleggende pilotering av trygghetsalarm for brukere i egen bolig eller omsorgsbolig samt pasientsignal i institusjon vil være del av de første aktivitetene. Et av de største pilotprosjektene vil være esenior som skal tilpasse og prøve ut trygghetspakker med velferdsteknologi for seniorer slik at de kan bo lenger hjemme med god egenmestring og livskvalitet. Erfaringer fra esenior på bruk av velferdsteknologi kan overføres andre brukergrupper og miljøer. Avhengig av prioritering og utviklings- og prosjektmidler vil det her kunne bli flere pilot- og utviklingsprosjekter for andre brukergrupper som unge funksjonshemmede, brukere med demens og andre brukere med behov for trygghetsskapende tiltak og velferdsteknologi. En pilotering vil ha flere formål: - Avklare bruk av teknologi og tilpasning av utstyr i forhold til brukers situasjon - Utvikle og tilpasse teknologiske løsninger og integrasjoner - Kombinere teknologi, andre hjelpemidler og tjenester for å fylle brukers behov for trygghet og daglige behov for fysisk aktivitet, sosial aktivitet og egenmestring. - Tilpasse teknologi til tjenesteutvikling og organisatoriske forhold - Lage gode prosedyrer og rutiner for kartlegging, mottak og oppfølging av brukere og avklare organisering av tjenestene rundt bruk av velferdsteknologi - Kompetanseoppbygging og etisk refleksjon for ansatte og andre berørte parter Ved pilotering av velferdsteknologi ønsker vi å gjøre dette trinn for trinn, men gjerne med ulike bruksområder og brukergrupper. Men hver pilot må gjøres kontrollert og avgrenset med fokus på brukerfokus. Når det gjelder teknologi ser vi for oss tilpasning av trygghetssignal og et begrenset omfang av sensorteknologi for helse og omgivelser. Det vil være viktig å avklare mulige integrasjoner og samspill med Gerica kommunens pasientadministrative system. esenior prosjektet vil ha fokus på pilotering inn egenmestring i dagliglivet, men spesielt inn mot: Fall Kognitiv svikt Helse og ernæring Lokalisering og sporing Sosial kontakt Kommunikasjon Som metode for brukermedvirkning benyttes fokusgrupper og partnerskap. Her er det etablert et samarbeid med Høgskolen i Østfold. Leverandør gis mulighet for en utviklingsarena for utvikling og bruk av velferdsteknologi. Med etablering av et pilotmiljø vil vi både forberede egen organisasjon for et innføringsløp, men også legge til rette for utprøving av velferdsteknologi og innovasjon i samspill mellom system og organisasjon. Fredrikstad vil søke alle muligheter for utviklingsprosjekter i samarbeid med leverandør og andre samarbeidspartnere for en felles ønsket utvikling. 7
Det søkes samarbeid med eksisterende leverandører som Tieto (Gerica), NAV, Helse Sør Øst, Høgskolen i Østfold og andre forskningsinstitusjoner for både følgeforskning og OFU prosjekter. Konsept trygghet: Figur 1 - Konseptuell skisse av plattform for trygghetssignal og velferdsteknologi 2.4.1. Teknologi, standardisering og brukerdrevet utvikling ruk av velferdsteknologi er umoden på flere plan både på leverandørsiden og innen helseog omsorgssektoren. Det meste av teknologi er tilgjengelig i dag, men det er lang vei fram for å ta i bruk teknologi som er godt brukertilpasset og som har en god kost-nytte effekt. Det er også mange avklaringer før vi har den rette kombinasjonen av teknologi og standarder for signal- og informasjonsutveksling, mottak, håndtering og lagring på en strukturert standard i elektronisk pasientjournal og andre administrative system. Det er viktig for Fredrikstad at velferdsteknologi bygges på åpne teknologiske plattformer hvor en først skal etablere tjenester for trygghetssignal og kommunikasjonsløsninger for både bolig og institusjon. Det er et stort samspill mellom bruker, teknologi, tjenester og organisasjon som må modnes og utvikles. Her er det viktig med innovasjon og utvikling på flere plan og aktører. Dersom man snur hindringene til mulighetsrom og sier «Tenk om»: - Trygghetsalarmer og velferdsteknologi var tilpasset den enkelte brukers behov og funksjonsnivå - Det var gode brukergrensesnitt, funksjonelt utstyr med god universell utforming og god metode for å ta i bruk individuelt tilpassede hjelpemidler og velferdsteknologi - Alle sensorer, alarmer og annen velferdsteknologi som ble produsert kunne fungere på en felles plattform 8
- Trygghetsalarmer og velferdsteknologi var satt i system for en effektiv drift av omsorgstjenester samtidig som brukere og pårørende fikk en tryggere hverdag med god egenmestring og aktivitet - Det var et godt samspill på hjelpemidler og utstyr levert av NAV, kommunens bruk av velferdsteknologi både teknisk og organisatorisk - Det var mulig å motta og integrere brukers medisinske målinger inn i EPJ system med håndtering av strukturerte data for forsendelse, lagring og oppfølging samt videresende medisinske data mellom behandlingsnivåer - Det var mulig med sikker videokommunikasjon mellom bruker, kommunens omsorgstjeneste, pårørende og spesialisthelsetjenesten på tvers av tekniske løsninger - Man hadde valgt og etablert standard for intern og ekstern kommunikasjon på utstyr, system og infrastruktur mellom samhandlende parter - Det var en sømløs integrasjon mellom smarthus, velferdsteknologi og kommunikasjonsløsninger - Man hadde en organisering av mottak og oppfølging med etablert teknologi for håndtering av alle henvendelser og signaler fra trygghetssignal og velferdsteknologi for bolig og institusjon. 2.4.2. Organisasjon, tjenester og aktører For å lykkes med innføring av velferdsteknologi må teknologien og kommunale tjenester forenes i en prosess for tjenesteinnovasjon. Men man må også se på samspillet mellom virkemidler, aktører og aktiviteter. Et forsøk på en modell som visualiserer dette: Virkemidler: - Forebyggende og helsefremmende tiltak. - Egenmestring, sosialisering og aktivitet. - Velferdsteknologi - Tjenester Aktører: - Kommunale tjenester - NAV hjelpemiddelsentral - Spesialisthelsetjenesten - Private aktører, frivillige og pårørende Styrende aktiviteter: - Kartlegge behov - Prioritere tiltak - Koordinering og dialog Figur 2 - Velferdsteknologi må ha et tett bånd mot forebyggende og helsefremmende tiltak og tjenesteinnovasjon innen helse og omsorgssektoren En grunnleggende faktor i samspillet er god dialog og informasjon. Like viktig er brukerens mulighet og evne for sosial deltakelse. 9
Innføring av velferdsteknologi må ha en organisatorisk tilnærming inn mot forebyggende tjenester, med helhetlig kartlegging, tilrettelegging og oppfølgende tjenester der vi også ser på dagens ordning for trygghetsalarm. Skal det være legevakten som administrerer mottak og de ordinære hjemmetjenestene som følger opp brukerne eller skal man se på muligheten for en annen organisering av tjenestene som bl.a. ambulante team og mer fleksibelt mottaksapparat. Vi må også vurdere hvordan private aktørers tjenestetilbud skal samvirke med kommunen. En bedre involvering av pårørende og frivillige er ønskelig. Et sentralt mottaksapparat/førstelinje og koordinerende funksjon for håndtering av brukere, avvik og oppfølging må vurderes. Flere kommuner bl.a. Trondheim kommune vurderer en funksjon for «Helsevakt» som er en utvidet legevakt og døgnåpen vaktsentral for omsorgstjenester som også håndterer monitorering og oppfølging av kronikere og trygghetssignal for hjemmeboende brukere. Fredrikstad kommune deltar i et tilsvarende prosjekt for å etablere et Call senter/helsevakt for legevakt og mulig mottak for trygghetsalarm og oppfølging av brukere. 2.5. Utviklingsavtale Det er ønskelig å inngå en utviklingsavtale med leverandør og fast representasjon i leverandørens «brukerstyre» som sikrer Fredrikstad kommune en mulighet for å påvirke leverandørens utvikling av produkter. En avtale for etablering av et utviklingsmiljø for utvikling og utprøving av velferdsteknologi for bolig og institusjon i samarbeid med leverandør, Høgskolen i Østfold og Fredrikstad kommune er ønskelig. Avtalen som inngås vil forplikte både leverandør og kommunen på en aktiv bruk av pilotmiljøet og avsetting av ressurser til formålet. 10
3. Funksjonsbeskrivelse for leveransen Målbildet for trygghetssystemet er en løsning som er felles for kommunens omsorgsboliger og institusjoner samt hjemmeboende brukere i egen bolig. Plattformen skal ha sentral drift og skal kunne oppskaleres til bruk for alle kommunens institusjoner og hjemmeboende brukere. Det skal være fleksibilitet på signalhåndtering til flere mottak, respondenter, situasjon og tid på døgnet. Enkel administrasjon for endringshåndtering. Informasjon som skal journalføres i kommunens fagsystem og EPJ må kunne integreres. Utstyr og teknologiske løsninger søkes standardisert uavhengig av om bruker bor i bolig eller institusjon. Det skal være brukerens behov og funksjonsnivå som skal være førende. Alt utstyr skal ha en god universell utforming. Alt utstyr skal ha en robusthet tilpasset brukere og ansatte. Grunnfunksjonalitet på plattformen som etterspørres vil være trygghetssignal og kommunikasjon med lyd og bilde. Det skal legges til rette for utvikling, pilotering og bruk av velferdsteknologi med vekt på trygghetsskapende teknologi. Prinsippskisse på plattformens funksjonalitet og signalhåndtering: Figur 3 - Felles plattform for trygghetssignal og velferdsteknologi i bolig og institusjon med mulighet for samhandling med flere aktører 3.1. Generell funksjonalitet trygghetssignal (leveranse og pilotering) Selve trygghetssignalet er basis i løsningen. Trygghetssignal omfatter grunnfunksjonalitet i dagens pasientsignal for institusjon og trygghetsalarm i bolig. En bruker skal kunne direkte eller indirekte melde behov for bistand for praktisk assistanse i sitt sykerom eller i en nødssituasjon uavhengig om brukeren er i egen bolig, på badet, på 11
institusjonens aktivitetsrom eller har falt på kjøkkenet, en annen lokasjon eller utendørs. Ved øvrig bistand utenom nødsfall bør oppkall med tale være hovedregel, se kapittel 3.3 for kommunikasjon. rukere av trygghetssignal skal oppleve løsninger som gir god trygghet, og som kan stimulere til egenmestring. Ansatte skal oppleve en helhetlig og effektiv kommunikasjonsløsning med liten risiko for feil og feilkilder. Det kan være behov for både mobile enheter, faste display og sensorer eller andre teknikker for registrering og varsling av avvikende aktivitet både i institusjon og bolig. Det er ønskelig at utstyr har en god universell utforming og kan brukes uavhengig om man er i institusjon eller bolig. Alt utstyr som skal betjenes av bruker skal være enkelt og intuitivt i bruk tilpasset brukeren. Det må være brukerens funksjonsevne som er avgjørende for utstyrets utforming og bruk. Fredrikstad bygger et sykehjem for brukere med demens på Østsiden, har korttidsplasser for øyeblikkelig hjelp og rehabilitering på helsehus og mange hjemmeboende brukere med ulik funksjonsevne. Det er ønskelig å finne fram til en standardisering av pakker med trygghetsskapende tiltak og velferdsteknologi med individuell tilpasning som enkelt kan justeres ved endret livssituasjon og funksjonsnivå. Trygghetsalarmen bør ha mulighet for sporing og lokalisering både inne og utendørs. En integrasjon mot boligen og institusjonens adgangssystem er ønskelig. Ansatte har i mange tilfeller behov for en personalarm, både som mobil alarm både utendørs og inne og som fast display/knapp i for eksempel samtale/behandlingsrom for nødsfall og for påkalling av assistanse. Det må være mulighet for både «nødknapp» og toveis kommunikasjon. ehovet for ansatt alarm vil gjelde alt fra legevakt, rus og psykiatri tjenesten til institusjon og hjemmetjenester. 3.2. Generell funksjonalitet overvåkingsalarmer (pilotering og opsjon) Trygge omgivelser er viktig for en brukers hverdag. Det er viktig å sikre både de ytre og indre omgivelser. «Ei sikker adgangsdør» er viktig både for å hindre uvedkommende adgang, men også sikre at kommunens ansatte og beredskapspersonell enkelt får adgang til brukers bolig. En sikker adgang sammen med en porttelefonløsning med lyd og evt. bilde ved adkomst vil trygge brukeren. Se også elås under kapittel 3.5 Omgivelseskontroll Det er viktig med helhetlige brannsikringstiltak og sikker rømning med bruk av teknologi som kan integreres mot velferdsteknologiplattformen. rann- og innbruddsikring leveres av mange leverandører her vil det være viktig med et samarbeid og integrasjon av løsninger inn mot etablering av kommunale trygghetspakker der bruk av bl.a. bevegelsessensorer vil kunne få utvidet bruk og funksjon. Teknologiske løsninger må være åpne for avtale om mottak av signal for håndtering av brann, innbrudd og andre hendelser til både andre offentlige tjenester som brann og redningstjenester og private vektertjenester. Det kan være glidende overgang mellom overvåkingsalarmer og omgivelseskontroll? Se kapittel for omgivelseskontroll og smarthus kapittel 3.5. 12
3.3. Generell funksjonalitet kommunikasjon (leveranse og pilotering) Når trygghetssignal utløses eller bruker har behov for bistand er det viktig at bruker kan kommunisere til et mottaksapparat uavhengig om det er en kommunal tjeneste, pårørende/frivillige eller en annen offentlig eller privat tjeneste. Kommunikasjonen må være enkel, tilgjengelig og intuitiv i bruk. Første prioritet er lyd, men også video er ønskelig i de situasjoner det er mulig. Kommunikasjon er viktig for brukeren, pårørende og brukers relasjoner for sosial kontakt. Det er ønskelig å legge til rette for kommunikasjonsløsninger for tale, video og sosiale medier for brukere med ulik funksjonsnivå og teknisk forståelse. På samme måte som kommunikasjon er det viktig at brukere har god tilgang til informasjonskanaler for innhenting av nyheter, kommunal tjenesteinformasjon og underholdning. For brukere i egen bolig eller omsorgsbolig vil det ofte være behov for en porttelefon lett tilgjengelig for bruker med mulighet for lyd og bilde for identifisering av besøk samt en døråpner. På institusjon gjennomføres en pilotering av erom på bruk av Gerica på pasientrom i samarbeid med Tieto. Her piloteres dokumentasjon i Gerica av ansatte på pasientrommet på multitouch terminaler alternativt nettbrett. Terminalene ønsker på sikt også å være brukernes tilgang til internett, TV og kommunikasjon. En integrasjon mot trygghetssignal og velferdsteknologiplattform er naturlig. 3.4. Monitorering og oppfølging av helseverdier (pilotering og opsjon) Kontroll og oppfølging av helseverdier både av bruker og helsepersonell (monitorering) er ønskelig både på institusjon og i egen bolig. åde for egenkontroll av helse, men også oppfølging via helsepersonell som fastlege, spesialisthelsetjenesten og hjemmesykepleien. For eksempel måling av INR for å justere medisin, oppfølging av ulike kronikergrupper som kols, diabetes og hjerte- og karsykdommer. Helseverdier bør kunne sendes til et mottak for vurdering eller varsel dersom verdien er utenom det normale. En direkte integrasjon og registrering av helseverdier på brukernes «elektroniske helsekort» eller tilsvarende bør muliggjøres på kommunens EPJ system. 3.5. Generell funksjonalitet - omgivelseskontroll og smarthus (pilotering og opsjon) Det å kunne styre sine omgivelser i det daglige er viktig for egenmestring og trygghet. Det kan være styring av klima, lys og multimedia utstyr i egen bolig via en fjernkontroll eller nettbrett. I nye boliger kan det bedre legges til rette for bruk av smarthusteknologi som styring av lys, klima, åpne/lukke vinduer, dører, heve/senk innredning og solskjerming, men også mulighetsrommet i eksisterende bygg bør utforskes for bl.a. styring av lys, solskjerming og andre funksjoner. En nyttig funksjon vil være et panel for å kontrollere og slå av lys og andre funksjoner ved utgangsdør når en bruker skal ut. 13
Det optimale er få og enkle fjernkontroller og panel for styring av funksjoner i en bolig. Det skal enkelt kunne monteres/ bringes med på rullestoler ved behov. ruk av elektronisk lås på inngangsdør vil både gi brukere, pårørende og kommunalt ansatte enklere tilgang og mulighet for å låse opp inngangsdør som et supplement til tradisjonell nøkkel. ruker vil kunne låse opp før besøkende via fjernkontroll, nære familiemedlemmer kan ha en "App" på sin telefon for å kunne låse opp, ansatte i hjemmesykepleien får tildelt elektronisk nøkkel når de har fysiske oppdrag mot bruker som styres via det pasientadministrative systemet og samme tilgang kan gis til ambulanse, brann eller politi ved nødsfall som håndteres av mottaket til trygghetssystemet. Smarthusanlegget skal kunne integreres mot øvrige tekniske systemer i bygget. 3.6. Generell funksjonalitet velferdsteknologi (pilotering og opsjon) Trygghetssystemet skal ha en åpen plattform for velferdsteknologi som skal kunne utnytte dagens og morgendagens teknologiske løsninger. Det er ønskelig å utvikle og tilpasse individuelt tilpassede standardpakker der basis er trygghetssignal og elektronisk dørlås. Trygghetspakker med sensorer og mulighet for monitorering av helseverdier, kommunikasjon med lyd og bilde samt smarthusfunksjoner sammen med andre hjelpemidler og tjenester skal bidra til å håndtere: Fall Kognitiv svikt Helse og ernæring Lokalisering og sporing Sosial kontakt Kommunikasjon 3.6.1. Kategorier velferdsteknologi For både å avgrense og prioritere type kategori av velferdsteknologi som ønsker pilotert og mulig installert på kommunens plattform for velferdsteknologi har man tatt utgangspunkt i en kategorisering av velferdsteknologi publisert i NOU 2011:11 Innovasjon i omsorg, kapittel 7. Første prioritet er: (grønn) trygghets- og sikkerhetsteknologi Videokommunikasjon, teknologi for sosial kontakt Dernest prioriteres kategorier som: (rød) Omgivelseskontroll, kompensasjons og velværeteknologi Huskehjelp, kompensasjons- og velværeteknologi Teknologi for behandling og pleie 14
Figur 4 - Samlet kategorisering av velferdsteknologi, kilde NOU1:2011 Innovasjon i omsorg 3.7. Mottak og oppfølging (leveranse og pilotering) Plattformen skal ha sentral drift. Men all signalhåndtering og kommunikasjon skal være fleksibelt både med hensyn til behandling, organisering, mottakssteder, type utstyr og ulike behov på tider av døgnet. Systemet må enkelt kunne konfigureres av egne superbrukere. Lokal styring ved strøm- eller databrudd Ulike type anrop og signal må kunne gå til ulike steder avhengig av organisering og type signal. Et nød-anrop skal for eksempel kunne gå rett til legevakten, et signal om bistand kan gå rett til hjemmesykepleien eller sykehjemmets vaktrom, og en registrering av en helseverdi ved hjelp av en sensor sender signalene rett til brukerens journal i Gerica som er kommunens pasientjournalsystem. En vurdering av integrasjoner, organisering og prosedyrer mellom trygghetssystemet, kommunens eventuelle Callsenter/Helsevakt og kommunens EPJ system er et av de områdene som må avklares for å sikre funksjonelle krav og muligheter som for eksempel - behov og muligheter for tilgjengeliggjøring av journal og epikrise sammen med nød-anropet i mottaket for trygghetssystemet, og mulighet for å sende og lagre nødvendige medisinske opplysninger og logg informasjon i EPJ systemet. Det skal også være mulighet for eksternt mottak og oppfølging av signal av bl.a. pårørende, frivillige og mulige private tjenesteytere. 15
Administrasjon av mottak må kunne: Skille på type anrop med ulik prioritet Filtrere/prioritere Skje på flere kanaler og type enheter som: o PC o Smarttelefon o PDA o LYNC (kommunens telefoni og samhandlingsplattform) o Med mer. Vise informasjon om bruker og lokasjon Ha tilgang til loggfunksjon direkte i systemet med mulighet for videresending av logginformasjon Systemet må ha en god tilgangsstyring og rollebasert oppbygging på flere nivå med rettigheter og funksjoner tilpasset helse og omsorg. Kvitteringsfunksjon for tilstedeværelse, utført oppdrag og falsk alarm. 3.8. Administrasjon Trygghetssystemet og plattform for velferdsteknologi skal ha mulighet for sentral og desentral administrasjon både overordnet og for den enkelte virksomhet. Kommunen vil ha både sentral administratorer og superbrukere ute i virksomhetene som skal administrere og betjene systemet. Systemet skal være enkelt i bruk og håndterbart ved endringer av lokale superbrukere som: Terminalkonfigurasjoner, oppsett av varslesløyfer og grupper. Forandre romnummer ved hjelp av Software, slik at flytting av rom mellom avdelinger kan skje uten fysiske endring av installasjonen. Endring av tekster, prioritering av de forskjellige signaltyper, sammenkobling av avdelinger skal være programmerbart i Software. ruk av statistikk og loggfunksjonalitet. Loggingen skal muliggjøre uttak av historiske data til standard rapporteringsverktøy. Det er naturlig at systemet er integrert mot Gerica sitt system for plassadministrasjon for håndtering av identifisering av brukere, pasientrom og leiligheter i kommunens institusjoner og omsorgsboliger. 16
4. Tekniske rammebetingelser Oppdragsgiver har satt følgende tekniske rammebetingelser for leveransen. Figur 5 - Teknisk prinsippskisse velferdsteknologiplattform - Fredrikstad kommune For opplysninger om de eksisterende standardene, krav til system, programmer/ applikasjoner, databaser, telefoni og infrastruktur, se Kravspesifikasjonsdokument: «Standarder for informasjons-, kommunikasjon og telefonisystemer». 4.1. Eksisterende IKT plattform Fredrikstad kommune har etablert et felles nettverk for alle kommunens virksomheter. Dette nettverket, FK-LAN, er bærer av alle IT-tjenester, inklusive telefoni, fra sentralt driftsmiljø. FK-LAN består av et kjernenett, et distribusjonsnett med noder som dekker sentrale områder og et aksessnett som kobler det enkelte tjenestested til distribusjonsnettet. Alle sykehjem, omsorgssentra, helsebygg, osv. i Fredrikstad er tilkoblet FK-LAN via fiber og aksessnettnoder. Anskaffelsen skal omfatte nødvendige utstyrsleveranser, konfigurasjons- og integrasjonsarbeider, samt support og vedlikehold av slike. Samtidig er det viktig at leverandør av trygghetssystem og drifts leverandør av FK-LAN samarbeider godt. Pilotinstallasjonene vil bli brukt for å avklare detaljer i leveranser, grensesnitt og organisering av videre utskiftningsprogram. 4.2. Sikkerhetsarkitektur Fredrikstad kommunes sikkerhetsarkitektur er basert på følgende prinsipper: 17
Nettet er delt inn i 4 soner (DMZ {first- og second defence}, Åpent og Lukket) Det er et klart skille mellom tjenester og klienttyper inndelt i relevante sikkerhetspolicy Tilgangen til tjenester reguleres gjennom bruk av sikkerhetsbarrierer (brannmurer, VLAN, pakkefilter, autentiseringsløsninger, VPN/SSL-GW, krav til klienter og tjenere, osv.) En sone har i utgangspunktet ikke tilgang til en sone med høyere sikkerhetsnivå med mindre det er eksplisitt tillatt, og regelregulert i en brannmur En sone med høyere sikkerhetsnivå har ikke nødvendigvis tilgang til en sone med lavere sikkerhetsnivå Hver sone vil inneholde ett eller flere nettverkssegmenter DMZ: Åpen: Lukket: Internettrelaterte systemer Administrative og faglige nett Sensitive personopplysninger EPJ Driftsnett Tekniske tjenester Virksomhetskritiske systemer 4.2.1. DMZ Kommunen benytter en kompleks sammensatt Demilitarisert Sone(er) mellom LAN og Internett. Det er etablert soner i DMZ. Alle systemer som skal kommunisere fra internett til LAN eller omvendt har ikke lov til å passere to soner uten å snakke gjennom en Proxy server. rannmur benytter TMG. Ytterligere informasjon kan fås ved henvendelse til ITseksjonen. DMZ er for FK organisert med følgende tjenester: Eksterne websider, portal o.l. Inngående e-postmottak fra eksterne nett Webmail-tjener ekstern navnetjener (DNS; også kalt autoritativ eller publiserende navnetjener) VPN-tjeneste for ansatte Innbyggerportal 4.2.2. Åpen sone Fredrikstad kommune har følgende tjenester lagt til intern sone: systemadministrative, fagnett, tekniske tjenester, administrative systemer og driftsnett, adm. av fjerntilgang, samt klienter som kan aksessere tjenestene i sikker sone. 4.2.3. Lukket sone Alle tjenester og systemer som inneholder sensitive personopplysninger ref. personopplysningsloven 2-8 og alle virksomhetskritiske systemer plasseres i sikker sone. 4.3. Overordnede arkitekturprinsipper ærer i trygghetssystemet, fra klient, eventuelt node, (klient) til serverinstallasjonen, skal være TCP/IP. Løsningen skal benytte FK eksisterende nettverk(lan). Nettverksstandarder: 10/100 aset nettverk 18
Power over Ethernet (802.3af og 802.3at) WiFi (802.11 b/g) Støtte for UDP Reservert IP-adresse fra DHCP-server. Trygghetssystemets noder/klienter skal benytte DHCP. Kryptering av alle data, ved bruk av 128 bits algoritme 4.4. Nettverk og infrastruktur Anskaffelsen inneholder mange ulike elementer for anvendelse og forutsetter bruk av Fredrikstads kommunes LAN. Dette krever derfor nært samarbeid med IT avdelingen. 4.4.1. Privat bolig Alarmsender/GW for trygghetssystemet tilpasset bolig skal tilknyttes IP nettverk, men også ha mulighet for duplisert meldingstjenester for ekstra sikkerhet (eks GSM). Alarmsenderen kan gjerne fungere som kombinert switch/router og GW mot ulike former for trygghet- og helsesensorer og smarthusteknologi. Øvrige tekniske krav er: Trådløs kommunikasjon: Mulighet for en og toveis kommunikasjon mellom alarmsender og sensorer. Sentralen skal kunne tilknyttes alarmsendere som benytter 869.200-869.250 MHz og luetooth som bærefrekvens Opsjon: Det vil også være ønskelig å kunne kommunisere via WLAN (WiFi). Trådbundet. Mulighet for å koble sentral opp via sprede nett: UTP Cat. 5 eller Cat. 6/6A Prioriterte protokoller som skal støttes er EN50134 Trygghetssignal, KNX, X73 og HL-7 Mulighet for drivere mot andre leverandører av sensorer 4.4.2. Institusjon Felles kablingssystem. Alle sykehjem i FK er utstyrt med felles kablingssystem (strukturert kabling med UTP Cat5 og/eller Cat6/6A). I dag leveres telefoni- og datatjenester gjennom dette trådbundne nettverket. Alle sykehjem har/får ledige punkter i nærheten av hvor installasjoner og utstyr i sykesignalanlegget skal plasseres. I størst mulig grad, utnytte tilgjengelig kablingssystem og topologi for signalformidling og strømforsyning (via Power over Ethernet fra installerte switch). Kobling til felles kablingssystem gjøres i patch-panel i bygnings- og etasjefordelere, hvor også eventuelle undersentraler for sykesignalanlegget plasseres. Det er etablert WLAN (WiFi) på aktuelle sykehjem. Kunne driftes og overvåkes sentralt fra kommunen, men også opereres lokalt på den enkelte institusjon. Topologi er basert på VLAN med GW løsninger mellom systemene. Trygghet, sikkerhetsanleggene, bygg automatisering/smarthus. Prioriterte protokoller: DALI for lys, KNX for feltbuss, HL-7 for telemed, ACnet automasjon, LON for sikkerhet Grensesnittet mellom sentral og det lokale automasjonssystemet (undersentraler, buss-systemer, etc.) skal være basert på etablerte teknologistandarder og ikke være 19
avhengig av leverandørspesifikke produkter. Følgende standarder skal legges til grunn: o ACnet o OPC (UA) Proprietære kommunikasjonsprotokoller mellom sentral og automasjonsanleggene godtas primært ikke. I den grad modifikasjoner av felles kablingssystem er nødvendig, vil FKs etablerte driftspartnere på kabling utføre slikt arbeid. Det legges derfor til grunn at kabling ikke er del av anskaffelsen av sykesignalanlegg. 4.5. Merkesystem For at FK skal kunne administrere systemene er det viktig å ha en enhetlig merking og dokumentasjon. Merking og navngiving i skjermbilder (SD, APS, PDA, etc.) skal være sammenfallende med merking og navngiving ute i anlegget og i all annen dokumentasjon som beskriver tiltakshavers merkestruktur/merkesystem. Serveren må kunne programmeres med tilstrekkelig antall karakterer i flg. prosjektets merkestruktur. 4.6. Integrasjoner For å oppnå en helhetlig løsning for trygghetssignal og velferdsteknologi må de ulike systemene kunne integreres gjennom bruk av felles teknisk plattform og/eller gateway'er for informasjonsutveksling. Sentralt for anskaffelsen er at leverandørene har løsninger for dette. 4.6.1. EPJ system Sosial- og helsedepartementets føringer for Standardisering og samordning av informasjonsog kommunikasjonsløsninger i helsevesenet legget til grunn. Informasjon som krever journalføring skal kunne gjøre dette. Krav til format inngår som del av piloteringen. Leverandøren forplikter å inngå et forpliktende samarbeid med kommunens EPJ leverandør. 4.6.2. Telefoni LYNC SIP Fredrikstad kommune bruker Microsoft Lync SIP som VoIP telefonisystem. Telefoniløsningen i institusjonene er knyttet sammen i nettverk, sammen med alle andre tjenestesteder i Fredrikstad kommune. Telefonsystemet driftes av Fredrikstads IT-avdeling. Personalet bruker i utstrakt grad håndholdte trådløse telefoner/terminaler. Trådløse terminaler er i dag hovedsakelig standardisert på trådløs IP-telefoni. Trygghetssignalanlegget skal integreres med Fredrikstads kommunes telefonisystem, slik at personalet kan benytte sine telefonterminaler for å motta, behandle og kvittere anrop fra sykesignalanlegget. Trygghetssystemet skal: 1. Integreres med kommunens eksisterende IP telefoniløsninger og/eller nye løsninger som etableres for telefoni. 20
2. Mobile enheter basert på GSM og/eller WiFi skal kunne brukes. 3. Kombinert med telefoniløsning skal det gi mulighet for toveis talekommunikasjonsmulighet mellom personale - beboer, og mellom personale - personale. 4. Gjøre det mulig for lokal og sentral administrator å foreta enklere brukerkonfigurasjoner for oppsett av sammenkobling av sykesignal og telefonisystem. 4.6.3. Porttelefon, alarmanlegg og SD anlegg Fredrikstad kommune ønsker gjennom rammeavtalen med leverandør av trygghetssystem, å utfordre potensialet som kan ligge i integrasjon med øvrige tekniske installasjoner, som eksempelvis porttelefon, adgangskontroll, innbrudd, brannalarm, kamera/itv, energioppfølging og sentralisert styring og forvaltning gjennom SD-anlegg. Trygghetssystemet skal kunne: 1. Utveksle driftsdata med tekniske installasjoner, typisk basert på KNX, LON eller andre anerkjente busstandarder, gjennom standardiserte åpne grensesnitt/gateway eller tilsvarende. OPC UA og åpen ACnet er prioriterte grensesnittløsninger for Fredrikstad kommune. 2. Integreres med øvrige tekniske installasjoner, som porttelefon, brannalarm, kamera/itv, energioppfølging og SD. For realisering av integrasjoner til/fra andre tekniske installasjoner, vil tilstand på - og hvorvidt de andre installasjonene i de aktuelle sykehjemmene er forberedt for integrasjon være avgjørende. Det forutsettes imidlertid at de nye sykesignalanleggene som her anskaffes ikke skal medføre uhensiktsmessige begrensninger for slike integrasjoner. Pilotinstallasjoner og installasjon på Helsehuset vil bli brukt for å avklare detaljer i integrasjonsløsninger, og for å finne optimalt kost/nytte-nivå i integrasjonsløsninger. 4.6.4. Smarthusinstallasjon Krav til smarthus installasjon: 1. Smarthusinstallasjonen skal kunne være en integrert del av trygghetssystemet 2. Smarthussystemet skal være basert på den åpne standarden KNX i henhold til EN13321 & ISO/IEC 14543 3. Som periferibusser kan/skal følgende protokoller integreres mot KNX a. DALI for lysstyring b. EnOcean sensorteknologi for trådløs kommunikasjon 4. Systemet bør kunne håndtere styring, regulering og overvåkning av lys, varme, kjøling, ventilasjon, solavskjerming, energimåling, signalering med ulike trygghetssensorer, osv. 5. Valg produkter skal være brukervennlige og enkle å betjene, samt ha god og tydelig merknadsfelt ref. UU. 6. Smarthusinstallasjonen skal legge opp slik at sensorer kan benyttes til flere funksjoner fler funksjonalitet utnyttes når det er mulig. 4.7. Redundans Trygghetssignal anlegget skal være sikker og autonom, dvs. at om nettverket feiler skal anlegget fortsatt fungere lokalt. Følgende funksjoner må være operative om nettet går ned: 21
Anrop, fra pasienter og helsepersonell må fortsatt aksepteres av systemet Tilbakemeldingsinformasjon gis fortsatt til anroper (pasient- og helsepersonell) Lokal romsignalering er fortsatt mulig Korridorlampe-signalering er fortsatt mulig, ved å benytte lokal tonesignalering Så fort nettet er oppe igjen, blir anrop håndtert sentralt. 4.8. Sentralisert styring, drift og overvåking Oppdragsgiver ønsker med rammeavtalen med leverandør av sykesignalanlegg, å utnytte potensialet som kan ligge i sentralisert styring, drift og overvåkning. Trygghetssystemet må kunne: 1. Tilby funksjonalitet for sentralisert styring, drift og overvåkning, fra kommunenes egne driftssenter. 2. Tilby funksjonalitet for Remote leverandøraksess, slik at leverandør konfigurerer anlegget. Leverandørtilgangen skjer etter et eget regelverk gitt av kommunens IT avdeling. Anskaffelsen skal omfatte nødvendige utstyrsleveranser, konfigurasjons- og integrasjonsarbeider av løsning for sentralisert driftsløsning og Remote leverandøraksess. 4.9. Synkronisering Alle prioriterte systemer kobles mot sentral drifts server for lik synkronisering av blant annet tid. 4.10. Prosjektgjennomføring Fredrikstad kommune skal pilotere systemet før det driftsettes. Det er viktig med god prosjektstyring og gode milepæler fra både leverandør og kommunen for både å sikre framdrift og kvalitet. Det er ønskelig at leverandør skisserer en leveranse med ulike løsninger på leverandørens prosjektledelse og assistanse der kommunen kan ta et helhetlig ansvar. Kommunen vil stille med en omsorgsfaglig prosjektleder for pilotering, prosjektkoordinator og ressurser fra både seksjon for helse og velferd samt IT avdelingen. Kommunen er ansvarlig for å trekke med andre samarbeidspartnere som Tieto, NAV, Spesialisthelsetjenesten og høgskoler. 4.11. Kompetanse og opplæring Henviser til IKT kravspekk kapittel 5: Krav til opplæring. 4.12. Dokumentasjon Henviser til IKT kravspekk kapittel 6 Krav til dokumentasjon. 22
5. Kravtabell Kravtabellen danner grunnlaget for tildelingskriteriene, se konkurransegrunnlaget kapittel 1.6. 5.1. Veiledning til kravtabellen Fredrikstad kommunes «Standarder for informasjons-, kommunikasjon og telefonisystemer» danner grunnlaget for løsningens tekniske infrastruktur, se krav nummer 29. Kravtabellen skal besvares i vedlegg 5. Alle krav skal besvares. Forklaring til kravtabellene under: Krav nummer: Kravnummer skal benyttes som referansenummer Tildelingskriterier: Henvisning til relevant tildelingskriterium Kravspesifikasjon: Henvisning til relevant kapittel i kravspesifikasjonen eskrivelse: Tekst som beskriver kravet Kravtype: Se kravtyper i tabellen nedenfor Tilbyders besvarelse: I hvilken grad leverandøren kan tilfredsstille kravet (Ja, Nei, Delvis). eskrivelse og dokumentasjon kan gis i kolonnen «utfyllende svar» eller i eget vedlegg med henvisning til kravnummer i kravspesifikasjonen. Eventuelle vedlegg må henvise til kravnummer, gjerne med lenke i kravtabellen. Kravtyper i tabell: Må-krav (M) Kravet er vesentlig og MÅ tilfredsstilles. Mangler i forhold til Må-krav kan føre til avvisning, jfr. 20-13. Hvis funksjonen/egenskapen krever ekstra produkter, (programvare, maskinvare og /eller tjenester), skal dette opplyses og pris skal spesifiseres i prisskjemaet. ør-krav () Kravet ØR tilfredsstilles, men det er ikke et absolutt krav. Svar vil legges til grunn ved evaluering av tilbudet. Info (I) Ikke et direkte krav til leveransen, men leverandøren skal i sin løsningsbeskrivelse gi utfyllende informasjon. 23
Krav nr. Tildelingskriterier Kravspesifikasjon Kravtype Ja Nei Delvis 5.2. Fredrikstad kommunes krav - Standard for pasientvarsling, trygghetsalarm og velferdsteknologi (Trygghetssystem) Tilbyders besvarelse eskrivelse Utfyllende svar (esvares i eget vedlegg) 1. 6.3 2.2 og 3 Løsningen skal kunne benyttes både for private hjem og institusjoner. M 2. 6.3 2.2 og 2.3 eskriv systemets fleksibilitet og eventuelle begrensninger i forhold til implementering i nybygg og eksisterende bygg. 3. 6.3 2.2, 2.3 og 4 Kommunen har som mål at systemet skal kunne håndtere alle kommunens omsorgsboliger, institusjoner samt hjemmeboende brukere i egen bolig. 4. 6.2 2.3 og 2.5 Leverandøren skal kort dokumentere løsningens skalerbarhet/begrensninger i forhold til oppgitt antall brukere (beboere, pasienter og ansatte) og innholdsvolum. Leverandør skal beskrive sin tilnærming og bidrag i forhold til: pilotering produktutvikling og brukertilpasning standardisering og bruk av åpne protokoller kompetansebygging og andre forhold som organisering av tjenester rundt for å etablere helhetlige løsninger for velferdsteknologi. 5. 6.2 2.2.1, 2.3 og 6 Leverandør skal presentere en prosjektplan med forslag til milepæler og framdrift fra pilotering, idriftsetting, videreutvikling og innfasing av nye løsninger i faser både for bolig og institusjon. 6. 6.2 2.5 Leverandør skal beskrive hvordan selskapets egen kompetanse og tilknyttet kompetanse skal benyttes inn mot leveransen og pilot- og utviklingsmiljøet som etableres. 7. 6.3 3 Leverandør skal levere en kortfattet oversikt over funksjonalitet i tilbudt løsning mot: - ruker - Ansatte - Administrator eskriv spesielt utstyrets brukervennlighet, universell utforming og robusthet. eskrive hvordan løsningen kan driftes, administreres og vedlikeholdes. 24
8. 6.3 3 og 4 Leverandør skal lage en teknisk prinsippskisse over løsningen og beskrive de komponentene løsningen består av åpen arkitektur skal berøres spesielt. 9. 6.3 3.2 og 4.4 10. 6.3 3.3 og 4.4 11. 6.3 3.3 og 4.4 12. 6.3 3.4 og 4.4 13. 6.3 3.5 og 4.4 Prinsippskisser og tilhørende beskrivelser skal som minimum forklare: - Hvordan basis trygghetssignal løses for bolig og institusjon - Hvordan kommunikasjon med lyd og bilde løses - Hvordan sensorteknologi og annen velferdsteknologi kan håndteres av løsningen - Hvordan ulike integrasjoner kan løses gjerne med referanse til konkrete eksisterende løsninger o EPJ o Telefoni o Adgangskontroll o Alarmanlegg o Smarthus og SD anlegg o Monitorering - Løsning for mottak og oppfølging kan løses - Driftsløsning med en felles datasentral og løsning for sikker drift av institusjon og bolig, Det er ønskelig at man både har en helhetlig tilnærming samt beskriver spesielle forhold for bolig, institusjon og sentral/desentral drift. Det skal angis hvilke overvåkningsalarmer (opsjon) som kan tilknyttes trygghetssystemet og leveres som opsjon. Hvilke standarder som ivaretas og om eventuelt krav stilt i FGs regelverk er ivaretatt. eskriv mulighet for bruk av multitouchterminal/ nettbrett (opsjon) som en sentral del av løsninger for både informasjons utveksling og SRO av velferdsteknologi funksjonene i boligen/institusjonenref. erom prosjektet. Mulighet for toveis-kommunikasjon mellom bruker, operatør, behandlende part og ekstern part: Toveis kommunikasjon gjennom språk Toveis kommunikasjon gjennom varsling i kombinasjon med display/bilde Avklar teknisk løsning. Monitorering av helseverdier (opsjon): Det skal oppgis sensor omfang/typer eller GW mot hvilket system/løsninger som støttes. Eventuelle begrensinger/forutsetninger skal oppgis. Omgivelseskontroll / Smarthus (Opsjon): Det skal oppgis eventuelle sensorer/aktuatorer eller GW mot hvilket smarthussystem som støttes. Hvor mange signaler som kan mottas skal opplyses. 25
14. 6.3 3.5 Elektronisk lås vurderes som del av standard trygghetspakke sammen med trygghetssignal opsjon. Lås skal integreres mot døråpner og kommunens EPJ system for administrasjon. eskriv løsning. 15. 6.3 3.7 Mottak og oppfølging: Leverandør skal levere en løsningsskisse for mottak, ruting og oppfølging av signaler og kommunikasjon. Spesielt: - Håndtering ved nettutfall og kommunikasjonssvikt - Filtrering og sortering av signal - Kategorisering og prioritering - Logghåndtering - Ruting mot interne og eksterne parter og system - Administrasjon 16. 6.3 4 Systemets ytelse og responstid skal, av brukeren, oppleves som god. Operasjoner som utføres ofte skal gå fort og uten unødvendige forsinkelser. eskriv og dokumenter løsning og eventuelle utfordringer. 17. 6.3 4.2 Leverandør skal beskrive hvordan løsningen tilfredsstiller Datatilsynets krav til informasjonssikkerhet i henhold til Personopplysningsloven og Norm for informasjonssikkerhet. 18. 6.3 4.3. Systemet skal kunne signalere over kommunens FK- LAN. TCP/IP protokoll skal benyttes som signalbærer. M M 19. 6.3 4.4 og 4.7 Driftssikkerhet gjennom redundans ved driftsstans av signaloverføring skal annen signaloverføring automatisk overta, og signalstans skal varsles. Alarmsentralen skal ha mulighet for dublert nettverksløsning (eks Analogt/GSM, RL og VPN over IP) for overføring av alarm / tale/bilde. eskriv løsning. 20. 6.3 4.4 Kommunikasjon sensor/mottaker. Leverandøren skal oppgi om sensor/mottaker, kan utveksle toveis kommunikasjon, og om denne kommunikasjonen er basert på åpne standarder som støttes av flere leverandører. 21. 6.3 4.4 Kan systemet tilknyttes sensorer fra andre systemleverandører? I så fall hvilke. 22. 6.3 4.4 ærekanal. Opplysning over hvilke signaler som alarmmottaker kan motta av trådbundet/trådløst: Eks KNX, RFID, luetooth, 869 MHz eller annet. 23. 6.3 4.4 Støtter den europeiske standarden for sikker alarmoverføring over mobilnettet: EN 50131/50135, med angivelse av kl. I 26