Forprosjekt SIKT. Sikker IKT for hjemmemonitorering. 27. januar 2014

Transkript

1 Forprosjekt SIKT Sikker IKT for hjemmemonitorering 27. januar 2014.

2 Prosjekttittel: SIKT Sikker IKT for hjemmemonitorering Behovsområde: Sykehus, konseptutvikling Prosjekteier i HS: Oslo universitetssykehus IKT Prosjektansvarlig i HS: Stig Ronny Kristiansen Prosjektleder i InnoMed: Per Michaelsen Prosjektansvarlig i InnoMed: Per Michaelsen Utarbeidet av: Stig Ronny Kristiansen Velg dato: 27. januar

3 Innholdsfortegnelse 1 Sammendrag Bakgrunn for prosjektet Målsetting med prosjektet Avgrensninger Gjennomføring med resultater og anbefalinger Dagens situasjon Delmål 1 Arkitektur: Foreslå en overordnet norsk standardisert ende-til-ende arkitektur for sensorkommunikasjon i Norsk Helsenett Ansvarlige og videre behandling av pasient Etablering av et tilknytningspunkt for NHN NHN og oppkobling av sensorer Nett sentrert løsning (sky løsning) eller en meldingsbasert arkitektur? Arkitektur skisse Sending av data fra sensor Lagring av sensor data Delmål 2: Helsefaglig nytte Stille diagnose Pasient oppfølging Det å være hjemme pasient Delmål 3: Beskrive hvordan den foreslåtte norske standarden ivaretar myndighetenes krav til personvern, konfidensialitet og sikkerhet for denne type kommunikasjon Delmål 4: Hard- og software krav Delmål 5: Nødvendig infrastruktur i helseinstitusjon for mottak, prosessering, administrering og lagring av sensor data Resultater fra prosjektet Kartlegging og vurdering av eksisterende løsning Finne bedrifter for videreføring Konseptutvikling av ny løsning Konklusjon Etablering av et utviklingsprosjekt Forslag til skisseløsning Sentral koordinering

4 7.4 Rapportering av prosjekter En avklaring av hva som tilhører helsenett Felles tjenester En mobilløsning forutsetter videre utvikling av et avansert alarmsystem Referanseliste

5 1 Sammendrag Prosjektet har utredet og foreslått en sikker IKT arkitektur for medisinske sensorer i Norsk Helsenett. (NHN). Samhandlingsreformen legger opp til at flere pasienter skal behandles og følges opp utenfor sykehusene, for eksempel hjemme. Dette har ført til en økt satsing på velferdsteknologi. Velferdsteknologi er brukerrettede teknologier, som har til hensikt å understøtte og forsterke brukernes trygghet, sikkerhet, muliggjøre økt selvhjulpenhet, medbestemmelse og livskvalitet. I enkelte sammenhenger blir slik teknologi også omtalt som omsorgsteknologi. En viktig del av velferdsteknologien er utviklingen av nye medisinske sensorer som kan måle viktige medisinske parametere utenfor sykehuset. Medisinske parametere kan være: puls, kroppstemperatur, insulinnivå eller blodtrykk. Sensorene kan være montert på eller ved pasienten eller de kan være montert i boligen (på vegg, i gulv, ved dører, osv). Eksempler på sensorer som kan være montert kan være bevegelsessensorer (IR, Video, RFID) eller andre typer sensorer. Det forskers også på fastmonterte sensorer som måler biologiske variabler. Ultralyd og radarer er eksempler på slike løsninger. Utviklingen av sensorer innen velferdsteknologi har kommet mye lenger en anvendelse av hjemme sensorer i spesialisthelsetjenesten. En viktig grunn til det, er at det ikke finnes noen etablert standard for sending av sensorsignaler fra en mobil pasient og til det sykehus eller helseinstitusjon med ansvar for pasienten. Det betyr at sensorleverandørene må tilby komplette løsninger fra pasienten, via et eller annet nett til sykehus eller helseinstitusjon. Det fører til forskjellige proprietære løsninger med varierende kvalitet. Dette er uheldig både for sykehusene og sensorleverandørene. Dette forprosjektet drøfter flere løsningsmuligheter og setter fokus på områder som vil være utfordrende for videre utvikling av mobile helsetjenester. Forprosjektet er å anse som vellykket da det er blitt etablert et prosjektsamarbeid sammen med Sykehuspartner HF, Oslo Universitetssykehus HF, HotSwap AS, Transisto AS og Inven2 AS. Det er innvilget et tilleggstilskudd fra Helsedirektoratet for en prosjektskisse for skybasert test- og distribusjonstjeneste for mhelse. I dette prosjektet ønsker man å pilotere en første tjeneste for måling av vekt og blodtrykk via en skyløsning. Skytjenesten skal tilgjengeliggjøres for intern og ekstern tjenesteutvikling via et API. Prosjektleder for SIKT forprosjekt har vært Ronny Kristiansen ved Oslo universitetssykehus sammen med Bjørn Unneland i Norsk Helsenett og Karl Øyri fra Intervensjonssenteret ved Ous. Per Michaelsen fra InnoMed har ledet fremdriften i prosjektet og vært delaktig i det koordinerende arbeidet. 2 Bakgrunn for prosjektet Oslo Universitetssykehus har blant annet et prosjekt for Avansert HjemmeSykehus for barn (AHS) og opplever at de mangler en standardisert ende-til-ende arkitektur for sensorkommunikasjon for å kunne utnytte hjemme-sykehuset optimalt. De opplever behovet og ønsker å bidra til å utarbeide en norsk standard for sensor-kommunikasjon. 5

6 På denne bakgrunn er prosjektet administrativt forankret i Norsk Helsenett, mens den faglige forankringen ligger hos IT avdelingen og Intervensjonssenteret (IVS) ved OUS. Forprosjektet gjennomføres i regi av Oslo Universitetssykehus og NHN. 3 Målsetting med prosjektet Det er et ønske å beskrive en arkitektur primært for sykehusene, men som også kan brukes av andre aktører som kommuner og andre helseinstitusjoner. Man skal kunne benytte seg av flere typer sensorer fra flere leverandører og få disse til og samspille seg imellom. Sensorene skal levere data til standard sykehus systemer og ikke applikasjoner laget spesielt for sensorer. Forprosjektet skal definere en arkitektur som kan brukes for alle typer medisinske sensorer. Det vil ikke være noen forsøk på å lage nye standarder, men påpeke hvilke som finnes og hvordan de kan brukes i NHN. Påpeke hvilke tjenester som det er nødvendig for å bygge en infrastruktur i NHN slik at man enkelt skal kunne koble opp medisinske sensorer. 4 Avgrensninger Primær fokuset har vært sykehusenes behov. Sykehusene og kommunene har mange av de samme utfordringene, men i dette prosjektet var hovedfokus på sykehussiden. 5 Gjennomføring med resultater og anbefalinger Hovedmålet til forprosjektet er å foreslå en IT løsning som tilfredsstiller en overordnet norsk standardisert ende-til-ende arkitektur for sensorkommunikasjon tilknyttet Norsk Helsenett. NHN skal benyttes, og tjenestene som utvikles skal tilbys via NHN. Forslaget til skisse skal legge et grunnlag for et senere hovedprosjekt. Det kan være mange aktuelle løsninger, men de fleste som er testet ut bygger på en form for med kommunikasjonsenhet tilhørende programmeringsgrensesnitt. Kommunikasjonsenhet skal kunne utplasseres i hjemmet med en eller flere sensorer. Løsningen må også håndtere mobile sensorer som pasienten bærer med seg. Sensorene skal kommunisere med kommunikasjonsenheten. Kommunikasjonsenheten ivaretar all kommunikasjon med sykehuset eller helseinstitusjonen via NHN. Kommunikasjonsenheten sikrer at informasjonen blir kryptert og at kontinuerlige målinger blir akkumulert over en gitt periode og overført i informasjonspakker med en predefinert hyppighet. I denne sammenheng er det ikke ønskelig med realtime kommunikasjon (direkte kommunikasjon). Det er flere årsaker til dette. For det første for man en enklere sikkerhetspolicy. I tillegg er det vanskeligere å overføre ansvaret for en sensor mellom foretak med direkte løsninger. 5.1 Dagens situasjon I dag brukes sensorer normalt på intensivavdelingen og operasjonsstuene. Noen sensorer brukes også av poliklinikker og hos fastleger. Eksempler er Holtermålinger, 24 timers 6

7 blodtrykk og blodsukker målinger. De fungerer som enkeltstående løsninger uten teknologisk infrastruktur og integrasjoner. Det er få muligheter til å oversende data fra fastlege til sykehus, uten å gjøre dette analogt, for eksempel ved å skanne inn dataene. Resultatene fra sensormålingene behandles forskjellig. Ved intensiv avdelingen bruker man papirkurve og plotter inn et utvalg av data. Det betyr liten dataoppløsning og tilgjengeligheten er begrenset. For eksempel en hjertesensor sampler flere ganger i sekundet, mens man i kurven registrerer en sampling i minuttet. Noen av kurveskjemaene blir skannet inni journalen for å øke tilgjengeligheten for brukerne. Løsningene som brukes av poliklinikker og fastleger har ofte en utskriftsfunksjon. Utskriften skannes inn i journalen og som sendes som papir til spesialistene. 7

8 Figur 1 Papirbasert kurve fra Rikshospitalet Ved OUS er man i ferd med å implementere en elektronisk kurveløsning. Løsningen er i drift på utvalgte operasjonsstuer og intensivavdelinger. En sengepostversjon er i ferd med og ferdigstilles. Sykehuset Østfold er sterkt involvert dette arbeidet i forbindelse med etablering av nytt sykehus. 8

9 Figur 2 Eksempel på elektronisk kurve fra imdsoft Det vil være naturlig at sykehusene samler alle måledata i en løsning også fra eksterne sensorer og det vil for de fleste sykehus være naturlig å bruke den elektroniske kurven. De fleste HF har i dag papir løsninger, men regionene jobber med å få på plass innkjøpsavtaler for elektronisk kurve. Status for kurveløsninger i de forskjellige helseregionene er varierende. 9

10 Helse Sørøst har valgt IMD Soft fra Evry Helse Midt har en Siemens løsning Helse Nord er ute med anbud Helse Vest har ennå ikke gjort noe valg. Selv om flere regioner har valg en løsning har de færreste HF startet implementering av kurvesystemer, dette kan være til hinder for å starte et mobilt sensor prosjekt. Det må være et minimumskrav at avdelingen bruker elektronisk kurve. Tenkt implementering av elektronisk kurve er ikke den samme i alle helseregionene. Flere regioner ser på en felles installasjon for regionen. Nåværende praksis er en installasjon pr HF. 5.2 Delmål 1 Arkitektur: Foreslå en overordnet norsk standardisert ende-tilende arkitektur for sensorkommunikasjon i Norsk Helsenett Historikken til helsevesenet tilsier at man bør etterstrebe og få på plass en god kommunikasjonsarkitektur. I dag har helsevesenet store utfordringer på grunn av at IT arkitektur kom alt for sent og har flere mangler. Spesielt er det viktig å se helheten i behandlingskjeden. Mange av dagens løsninger ser snevert på en lokal problemstilling og ikke ser helheten i pasientens behandlingskjede. Man bør imidlertid være forsiktig med å være for ambisiøs slik at man får så kompliserte modeller at de blir umulig å implementere. En balanse gang mellom helhet og enkelhet er viktig. Det pushes løsninger for å komme i gang i kommunene, spesielt samhandlingsreformen har satt nye krav til kommunene og sykehusene. Uten en overordnet strategi kan det gi store utfordringer på sikt. Som eksempel kan man bruke Oslo Universitetssykehus som må investere million beløp for å rydde opp i gamle løsninger. Man bør ta lærdom av dette og sette arkitektur på kartet tidlig når det gjelder velferds -og sensorteknologi før alt for mange løsninger er i drift. Man bør ikke stoppe eksisterende initiativ for det er utrolig viktig å hente erfaringer slik at løsningen ikke blir basert på skrivebordstenkning, men det bør være et krav at man deltar i et arkitektforum. Skal man klare å effektivisere dagen behandlingslinjer med teknologi må det være samspill med eksisterende løsninger på sykehusene og nye mobile løsninger. Dette samspillet må ikke undervurderes. Ny teknologi vil også utfordre dagens organisering av helsetjenestene. En skisse til pasientforløp er beskrevet i figuren til Anders Grimsmo selv om den er noe forenklet. Pasienter vil kunne være kunne være innom flere sykehus og de vil kunne gå til fram og tilbake i pasientlinjen. Det er viktig at arkitekturen tar høyde for alle typer pasient flyt. I dag er det slik at det er et 1:1 forhold mellom helseinstitusjon og sensor. I fremtiden vil det nødvendigvis ikke være tilfelle. Sensorene vil større grad følge pasienten som kan behandles ved flere institusjoner. Det kan være at avdelinger med landsfunksjoner vil benyttet seg av denne teknologien på tvers av helseregioner, så det er viktig at hele landet går får en arkitektur. Å gå for en felles arkitektur er noe annet enn å gå for felles leverandør. En god arkitektur gir åpning for flere leverandører og en sund konkurranse. 10

11 Skal man lykkes med innføring av mobile tjenester på sykehusene er det viktig at sensor og velferdsteknologi er en naturlig del av den daglige driften og ikke er noe som drives av en frittstående enhet. Løsninger som ikke forankres i den daglige driften har man dårlig erfaring med, spesielt på større sykehus. For eksempel ble ikke videoløsninger tatt i bruk før avdelingene fikk egne studioer og videomøter ble en del av klinikken. Ved mindre sykehus har felles løsninger hatt en vis suksess. Figur 3 Pasientforløpet (Anders Grimsmo 2011) Det er viktig at en arkitektur beskriver helheten slik at den kan brukes av alle nivåer i pasientkjeden. Mottakere av informasjon/data fra sensorene vil være pasienten, fastleger, kommunehelsetjenesten og spesialisthelsetjenesten. I rapporten Nasjonal elektronisk samhandling i helsetjenesten fra nasjonalt fag- og arkitekturutvalg påpeker at det er virksomhetsdata og ikke pasientforløp som har fokus i dagens helse IKT løsninger. Skal man satse på mobil/hjemme helse er det nødvendig at pasientforløpet er definert. Man må også huske på at pasientforløpene er definert før mobile tjenester var aktuelt så det kan være at pasientforløp må redefineres. Så lenge finansieringsmodellene for mobil helse ikke er på plass er det komplisert å integrere med eksisterende applikasjonsportofølge. De store sykehus systemene som pasientjournal og radiologiløsninger er i tillegg til fagsystem også faktureringssystem. Det betyr at integrering ikke bare må tenke på teknologi, men også logistikk for fakturering. Det kan være komplisert og flere sykehus har feilet på dette området. Det medfører mistet inntekter eller tilbakebetaling av tidligere inntekter. Flere sykehus har erfart det ved å legge til avdelinger i sine administrative system for å følge opp pasientforløpene på en bedre måte. Fordi disse ikke er DRG finansierende har det skapt store problemer i innrapporteringen og har i flere tilfeller ført til feil inntekts grunnlag. Så det er viktig å fokusere på helhet. I en mobil modell er det mange applikasjoner som vil bli påvirket. I kommunene er en egen velferdsteknologi/hjemme-sykepleier portofølge på full fart inn. Spesielt mobile enheter for å registrere besøk og bestille tjenester har mange kommuner begynt å innføre. 11

12 Figur 4 Applikasjoner brukt av de forskjellige helsenivåene Å ferdigstille en komplett mobil sensor arkitektur for hele helsetjenesten vil ta lang tid, men det bør ikke være til hinder for å starte med utprøving av teknologi i hjemmetjenesten. Det enkleste måten å angripe problemet på er å etablere funksjoner over tid i en felles arkitektur. Å etablere en komplet arkitektur som dekker alle behov vil ta tid og helse Norge er i dag ikke teknologisk modent for det. Verken kommunene eller HF har nødvendig infrastruktur på plass. Derfor vil en enkel modell med følgende enkle funksjoner være en god start. Etablere en enkel infrastruktur for å sende data fra sensorer inn til eksisterende applikasjoner på sykehusene. Etablere tjenester for å håndtere sensorer i store volum. Flytting av pasienter mellom sensorer Integrasjon med pasient planlegging Administrasjon av sensorer Administrasjon av lokalnett og body area network Integrasjon mot kommune løsninger som er i ferd med å tas i bruk Parallelt. Standardisering Spesielt vil det være kritisk å få på plass en tjeneste i NHN som kan sende data videre fra sensorer til institusjonene. 5.3 Ansvarlige og videre behandling av pasient Til nå har det vært normalt at en institusjon er ansvarlig for pasienten i en omsorgsperiode, normalt den som har henvisningen. Dette utfordres av et mer spesialisert helsevesen. I dag merkes dette blant annet i kreftbehandling hvor deler av behandlingen utføres lokalt mens behandlingsplanen legges av spesialist i sykehuset. Dagens systemer følger ikke opp 12

13 logistikken for dette og med et mobilt helsevesen vil disse utfordringene øke. I et moderne helsevesen må det være mulig å flytte ansvaret for en pasient sømløst mellom institusjonene. Som eksempel kan en diabetespasient brukes. Pasienten blir diagnostisert ved sykehuset hvor de utreder insulinnivået. Sykehuset monitorer pasienten i en periode før ansvaret overføres til pasient og fastlege. Etter som tiden går kan det være at fastlegen ønsker å vurdere om pasienten skal endre dose og sender data fra sensorene tilbake sykehuset for at de skal gjøre en ny analyse. Det er ikke uvanlig at pasienter er på flere sykehus og i fremtiden vil mobile sensorer være knyttet til pasienten og ikke institusjon. Det vil også gi juridiske utfordringer til eierskap. En full arkitektur vil inneholde både henvisning og rekvirering av sensorer. Arkitektur skissene vil ikke fokusere på integrasjon med meldingsutveksling. 5.4 Etablering av et tilknytningspunkt for NHN Et meget sentralt punkt vil bli hvor tilknytningen til NHN skal være. Det vil ikke være mulig å knytte alle sensorer direkte opp i NHN. For noen vil tilknytningen være i selve sensoren, mens for andre vil tilknytningspunktet være en ny type device, mens andre vil sende inn til et punkt i NHN. Det vil også være behov for å etablere nettverk som fungerer som en sensor for eksempel Body Area Network (BAN). Avanserte multimodale alarmsystem vil også kreve lokale nettverk tilknyttet sensorene. Figur 5 I fremtiden vil man etablere kroppsnære nett, såkalte Body Area Network. Sensorene kan være festet på kroppen, men også operert inn i kroppen 13

14 Figur 6 Det vil være mange tilknytningspunkt for sensorer. Forskjellige sensorer vil kreve forskjellige tilknytningspunkt. Det første skrittet for å få en arkitektur på plass er å definere hvordan man konverterer mellom standardene i NHN og data formatet til sensorene. Mappingen kan foregå i sensoren, mellom en sensor og NHN, i en multimodal løsning eller i en skytjeneste i NHN. For de fleste eksisterende medisinske sensorer vil dette være ny utviklet device som foretar konverteringen. Devicet må være enkelt og det må være et programmeringsgrensesnitt slik at ny sensorer løpende kan kobles inn i løsningen. Det finnes flere norske firmaer som har et utgangspunkt for en slik løsning blant annet Hospital IT og Imatis. 5.5 NHN og oppkobling av sensorer NHN har bygget opp en sikkerarkitektur for å koble opp sensorer. I dag er det mulig å koble opp de fleste typer mobile enheter i NHN. Det er meget viktig arbeid, men det er like viktig at sikkerhetsmekanismene i lagene over kommer på plass. Dette er en teknisk løsning for hvordan man kobler opp enheter i NHN, men sier lite om hvordan man kommuniserer ende til ende kommunikasjon. 14

15 Figur 7 Teknisk løsning for oppkobling av enheter i NHN Løsningen er blant annet tatt i bruk mot AMK sentralene og ambulansetjenesten. Nettet gjør det mulig for kunden å bruke NHN og Telenor Mobil data aksess. Sikkerhets løsninger kan legges både lokalt og sentralt. Det jobbes også mot andre leverandører enn Telenor. NHN er også i ferd med å etablere et testnett som kan benyttes under en pilot fase. NHN forutsetter følgende Applikasjons kryptering fra ende utstyr til applikasjon. Nasjonal IP plan må følges NHN har ikke laget noen kommunikasjonsmodell. 5.6 Nett sentrert løsning (sky løsning) eller en meldingsbasert arkitektur? En diskusjon som ofte kommer opp er om man skal ha en tjeneste løsning eller et nett sentrert løsning. I en nettsentret løsning vil en leverandør stå for hele leveransen. Vedlikehold og oppdatering vil skje et sted. Oppdatering av tjenestekataloger er helt avgjørende for å lykkes med en mobil sensorløsning og mange føler at dette er enklere i en nettsentrisk løsning. Selv om KITH har beskrevet en tjenestebasert løsning for meldinger i forbindelse med meldingsløftet, har Helse Sør-Øst allikevel valgt en nettsentrisk løsning, «Interaktiv Henvisning og Rekvisisjon» fra Evry. En av grunnene til dette var at flere HF så det som umulig og vedlikeholde en distribuert tjenestekatalog. Mange ser det som uheldig at det er sprik mellom foreslåtte sentrale standarder og hva regionene velger. 15

16 Det bør være fult mulig å ha hybride løsninger. Den samme utfordringen vil komme med sensorteknologien. Her vil nok også skyløsninger være mye mer sentrale. En skyløsning har den fordelen at en leverandør kan konsentrere seg om integrasjoner inn mot RHFene, mens spesialister på mobil programmering trenger ikke å opparbeide kompetanse på HL7 tjenester som brukes som integrasjon i de sentrale systemene på sykehusene. Det må finnes HL7 kompetanse hos eieren av skytjenesten. Figur 8 Skisse for en for en sky løsning hvor man skiller klart mellom mobile tjenester og HL7 tjenester 5.7 Arkitektur skisse For at man skal kunne komme i gang raskt kan det være lurt å starte med enkle tjenester som allerede tilbys i NHN. FTP tjenesten i NHN er velbrukt og kan gjenbrukes. Skissen tar utgangspunkt i en enkel løsning som man kan komme i gang med og som kan utvides løpende. 16

17 Figur 9 Flere aktører som kan være tilkoblet flere typer nett. Her NHN og internett I skissen er FTP valgt fordi den finnes allerede i som en tjeneste i NHN, men NHN er åpne for å bygge om denne til en mer moderne SOA arkitektur. Figur 10 Det vil være ønskelig med en standard hodemelding, og at sensordataene er vedlegg til denne. Avanserte tjenester vil komme, men det er ikke galt å starte med enkle tjenester som finnes For at man skal kunne gjenbruke en løsning er det viktig at man sender data på en felles måte. I denne skissen er det foreslått en hodemelding basert på HL7 og at sensor dataene sendes som vedlegg til denne. På den måten kan man sende data fra alle typer sensorer 17

18 over samme løsning. Man må imidlertid gjøre en jobb for å tilpasse sensor dataene til ende systemet i de fleste tilfeller elektronisk kurve. I en fase 2 vil det være aktuelt å innføre integrasjoner mot andre systemer enn medisinsk kurve Planleggings systemer og timebøker Min journal Journalsystemer Helsenorge.no Det må videre utvikles En robust arkitektur Arkitektur for samarbeid mellom HF og kommuner Nye sensorer må bestilles etter en valgt standard Standarder vi komme til og vil bli videre utviklet Løsninger for gamle sensorer som fortsatt vil være i bruk Figur 11 Et utvidet tjenestetilbud 5.8 Sending av data fra sensor I dag jobbes det med mange standarder for sending av sensor data. Continua er en allianse som har kommet et stykke på vei, men løsningen er nok best brukt fra et tilknytningspunkt og til sensor og ikke som bæretjeneste i NHN. Continua benytter seg av ISO/IEEE Personal Health Data (PHD) Standards. 18

19 Dette prosjektet fokuserer på sending av data fra tilknytningspunkt i NHN til mottaker. Skal man komme raskt i gang med en smidig løsning er nok den raskeste veien en HL7 versjon 3 løsning med et filvedlegg. I første omgang trenger man brukerens demografiske data i HL7 filen, mens sensor data blir sent som vedlegg. Det gjør at man må tilpasse en enhver sensor ved mottak. Det er allikevel fullt mulig å etterstrebe at vedlegg i størst mulig grad støtter IEEE 11073, men det vil gå lang tid før den er komplett for alle sensorer. Her er viktig at det gode ikke blir det godes fiende. Selv om ikke alle standarder er på plass må man starte implementeringen, men den må skje etter en sentral plan. 5.9 Lagring av sensor data OUS deltar i EU prosjektet Parlante. Prosjektet har deltagere for en rekke land og ser på hjemme tjenester og tilbud til pasienter. En av oppgavene i prosjektet er å se på sensor teknologi og sensorer for diabetes er valgt. En av de store diskusjonene i prosjektet er om man skal lagre all informasjon fra sensorene i sykehussystemene eller om man bare skal lagre interessante uttrekk ved unormale hendelser. Flere mener at teknologien er moden nok til at all informasjon lagres i sykehussystemene og at man kan bruke filtre, men man har ikke kommet til enighet. Juridiske og overvåkningshensyn kan gjøre at man ikke vil lagre alle data sentralt. Volven fra direktoratet foreslår at data sendes kun når spesielle hendelser inntreffer. Hendelser kan være for høyt blodtrykk eller økt hjerte rytme. Når en hendelse inntreffer kan det være at man ønsker data fra tiden før selve hendelsen inntreffer for eksempel timen før. Det gjør at man må vurdere lagringssystemer i NHN. Om man skal velger skyløsninger eller mer tradisjonelle lagringsløsninger må diskuteres. En annen diskusjon er om dette skal være felles løsninger for denne type lagring eller om man kan tilpasse denne type lagring til hver enkelt løsning. En modell som baserer seg på hendelser forutsetter en videre utvikling av alarm funksjoner. Elektroniske kurveløsninger har en tendens for å ha alarmsystemer som utløses for tidlig. Målinger ved enkelte sykehus har vist at over 80% av alle alarmer ved intensiv avdelingene er falske positive. Ved i igangsettelse ved et nytt sykehjem i Trøndelag melte NRK at en beboer utløste over 40 alarmer i løpet av en time, og de måte gå tilbake på gamle løsninger. Skal man begynne med mobile løsninger i stort volum må man utvikle alarmsystemene og det kan være at man må utvikle avanserte algoritmer og det kan være at man trenger egne nett for sensorer som leverer data til alarmalgoritmene Delmål 2: Helsefaglig nytte Det veldig lite som er satt i drift og det er heller ikke publisert mye om vellferdsteknologi så mye av dette kapittelet er basert på OUS erfaringer fra hjemme behandling, samtaler med helsepersonell og andre prosjekt som jobber med problemstillingen. Det er 2 hovedgrupper av brukere som har blitt beskrevet. 19

20 Pasienter som utgjør et stort volum. Denne gruppen vil kunne gi store besparelser for kommunene og HFene. Den andre gruppen er pasienter som med spesielle sykdommer som har store utfordringer i hverdagen. Denne gruppen vil nødvendigvis ikke gi økonomiske besparelser, men vil kunne forenkle hverdagen for pasienten. Her kommer man inn på den samme prioriteringsdebatten som nå foregår med hensyn til medisinering. Her bare påpeker vi denne problemstillingen Stille diagnose Det er mange som har store ambisjoner med sensorer som stiller diagnoser, men det er få som har lykkes. Under diagnostisering ønsker alle klinikere som vi har vært i kontakt med å se og føle pasienten. Sensorer kan vær til hjelp under diagnoseringen, ett eksempel på det er Holter-monitorering, men da som et hjelpemiddel Pasient oppfølging Det er her de fleste forventer at sensorer først blir tatt i bruk og de store pasient volumene kommer. Dette er pasienter som i dag må komme til kontroll eller som må ligge lenger på sykehus enn nødvendig fordi man ønsker å følge opp pasienten. I dag er det bare mulig å gjøre det mens pasienten er på sykehus, mens med sensorteknologi kombinert med video vil det være mulig å gjøre denne type oppfølging mens pasienten er hjemme Det å være hjemme pasient Det og være hjemme pasient byr på utfordringer for sykehuspersonalet. I hjemmet er det pasienten som bestemmer og andre hensyn må tas. Blant annet finnes det andre personer i hjemmet som det må tas hensyn til. Det er viktig å sikre at personvern hensyn blir tatt også for personellet og ikke bare for teknologien. AHS for barn har hatt ganske stor erfaring med dette og har klare rutiner for hvordan man opptrer hjemme oss pasienter. Ønsker man å implementere hjemme tjenester bør man tenke mer på de teknologiske rutinene Delmål 3: Beskrive hvordan den foreslåtte norske standarden ivaretar myndighetenes krav til personvern, konfidensialitet og sikkerhet for denne type kommunikasjon. Sikkerhet er svært viktig når helsetjenestene blir mobile. I Norge er dette godt beskrevet i Normen (normen.no). Informasjonssikkerhet er på flere nivåer. 1. Grunnsikkerhet i NHN og trafikken fra oppkoblingspunkt i NHN og mottaker 2. Sikkerhet fra oppkoblingspunkt til sensor 3. Fysisk sikkerhet, for eksempel at vinduer ikke bør være oppe under en videokonferanse 5.15 Delmål 4: Hard- og software krav OUS har i samarbeid med Sunnaas sykehus sett på teknologi løsninger for helsepersonell i en ambulerende tjeneste. 20

21 Det er forskjellige krav til teknologien ut i fra situasjonen. For pasienter som skal benytte seg av sensorer over en lengere periode så kan man forsvare å bruke teknikere til å koble opp utstyr og man kan knytte seg opp til utstyr i hjemmet eller på institusjonen. Her kan man benytte seg av teknikere. Ved Sunnaas er denne pasient typen vanligst. Ved AHS så var det vanlig med pasienter med korte opphold, og da er det ikke særlig rasjonelt å koble seg opp mot eksisterende infrastruktur. Derfor krever en løsning for denne gruppen mye enklere teknologisk løsninger da det som oftest er sykepleiere uten teknologisk kompetanse som installerer sensorene. En av de største utfordringene man møter er tilgang til sikkert nettverk. Både ved OUS og Sunnaas har man valgt løsninger basert på mobilnett. Både 3G og 4G er testet. Når det gjelder behov kan de fleste løsninger klare seg med båndbredde tilsvarende 3G. Ved Sunnaas kjører man videokonferanser over 3G selv om det er en båndbredde som er i minste laget. 3G har også den begrensning at det er mindre båndbredde tilgengelig for opplastning enn nedlastning. For nesten alle helseapplikasjoner har større behov båndbredde til opplastning enn nedlastning. Det er testet ut løsninger hvor man baserer seg på nett hos pasienten. Det er en løsning som tilbyr et mer robust nett, men erfaringen er at det er vanskelig å koble seg opp i dette nettet for ikke teknisk kyndig personell. Det er mye fokus på hardware og software, men eksisterende prosjekter har erfart at tilgang til teknisk personell er en større kritisk ressurs. Erfaringen er dagens organisering er komplisert. En tjeneste kan benytte seg av flere tjenesteleverandører. En løsning kan NHN, sykehuspartner, leverandøren og sykehuset være partnere, og det kan være komplisert for helsearbeideren å forholde seg til dette ved feilmeldinger. Dette er en større utfordring enn selve teknologi valget. Integrasjonskompetanse er også en knapphetsressurs i regionene og de som finnes blir prioritert til interne prosjekter. Tilgang til IKT ressurser i regionene er en sentral knapphetsfaktor som ikke må undervurderes når man starter slike prosjekter Delmål 5: Nødvendig infrastruktur i helseinstitusjon for mottak, prosessering, administrering og lagring av sensor data Det naturlige målet for sensor data er institusjonens kurveløsning. I dag er den ved de fleste institusjoner papir basert. Integrasjonskompetanse er også en knapphetsressurs i regionene og de blir prioritert på interne prosjekt. Tilgang til IKT ressurser i regionene er en sentral knapphetsfaktor som ikke må undervurderes. 21