DIALOG OM INTEGRASJON ELEKTRONISKE LÅSSYSTEMER

Transkript

1 DIALOG O INTEGRASJON ELEKTRONISKE LÅSSYSTEER OSLO KOUNE HELSEETATEN Storgata 40, 0182 Oslo

2 i Oslo kommune inviterte før sommeren til en åpen markedsdialog omkring elektroniske låssystemer. Se invitasjon og materiale på Doffin (ref.nr ). Vi takker for den interesse som ble vist i forbindelse med markedsdialogen. Av markedsdialogen fremgikk det, at det finnes flere ulike løsninger av elektroniske låssystemer. Vi har vurdert alle løsningene i forhold til helse- og omsorgstjenestens arbeidsmønstre og brukernes behov, og vi ønsker i den videre dialogen å fokusere på løsninger som dekker følgende områder: Løsninger, hvor den adgangsgivende enhet er en smarttelefon. Løsninger, hvor eksisterende nøkkel fortsatt kan benyttes. Løsninger, hvor låseenheten monteres på innsiden av døren. Fire leverandører som deltok i tidligere markedsdialog og som oppfyller ovenstående områder, er invitert til videre markedsundersøkelse. Undersøkelsen vil ha fokus på integrasjonen mellom elektroniske låssystemer og kommunens EPJ-system innen helse og omsorg (elektronisk pasientjournal). Andre potensielle leverandører inviteres også med i markedsundersøkelsen. Dialogen med disse vil i første runde være skriftlig og foregå på nedenstående måte. Det kan senere bli aktuelt å gjennomføre markedsundersøkelsesmøter med flere leverandører. Skriftlig dialog På bakgrunn av kunnskap for allerede gjennomførte markedsdialog har utarbeidet et utkast til integrasjonsbeskrivelse, se bilag 1. Alle potensielle leverandører inviteres til å beskrive sine løsninger på integrasjon inklusiv prismodell for løsningene, og kommentere de utfordringer, som fremgår av integrasjonsbeskrivelsen i bilag 1. (maks. 5 sider) Leverandører som ønsker å delta i markedsundersøkelsen, bes sende den skriftlige beskrivelse på epostadressen under senest d kl Epost: ebbe.abildgaard.sorensen@uke.oslo.kommune.no Emnefelt: Integrasjonspresentasjon ottatte beskrivelser vil bli gjennomgått av, og danne grunnlag for videre bearbeidelse av bilag 1. Eventuelle spørsmål fra leverandører i denne fasen vil ikke bli besvart grunnet likebehandlingsprinsippet. Alle beskrivelser behandles som fortrolig materiale med hensyn til reglene for innsyn og offentlighet. Side 1 av 16

3 BILAG 1: INTEGRASJONSBESKRIVELSE Side 2 av 16

4 Innhold Innledning... 4 Overordnet beskrivelse... 5 Logisk/detaljert design... 7 Systemer... 6 Registrering av låseenhet (logisk design)... 7 Registrering av låseenhet (detaljert design)... 8 Tilknytning av lås med objekt (logisk design)... 9 Tilknytning av lås med objekt (detaljert design) Generering av digitale nøkler (logisk design) Generering av digitale nøkler (detaljert design) Opp- og igjen-låsing og logging (logisk design) Opp- og igjen-låsing og logging (detaljert design) Kravspesifikasjon Krav til låsleverandøren Krav til EPJ-leverandørene Side 3 av 16

5 Innledning Dette dokumentet beskriver hvordan Oslo kommune ser for seg hovedprinsippene i integrasjon mellom kommunens EPJ i helse- og omsorgstjenesten, og bruk og administrasjon av elektroniske låser, levert av en vilkårlig leverandør. Hovedprinsippene tar utgangspunkt i nedenstående absolutte krav, som ble introdusert i markedsdialogen. Åpen løsning Tilgangsstyring Kontroll på informasjon Skal kunne velge flere leverandører av elås Åpne grensesnitt mot EPJ for at «alle» skal kunne integrere sine løsninger og fungere samtidig Ansattes roller og tilknytninger i EPJ styrer hvilke låser de kan låse opp Skjerme sensitive data, ikke overføre disse til låssystem Informasjon om låser, status og logg, skal være tilgjengelig i EPJ Dokumentet består av følgende 3 avsnitt. 1) Overordnet beskrivelse 2) Logisk/detaljert design 3) Utkast til kravspesifikasjon Detaljeringsgraden i dokumentet er lagt på et nivå som gjør det mulig å gjøre ytterligere detaljspesifiseringer i forkant av implementasjonen. Som en del av dialogen ønsker vi spesielt å få en tilbakemelding på nedenstående spørsmål: - Hvilken informasjon trenger låseleverandøren i sitt system for at løsningen skal kunne fungere sammen med EPJ-systemet, jf. integrasjonsbeskrivelsen? - Vil kravene i integrasjonsbeskrivelsen innebære omfattende utvikling for låseleverandør? - Vil låsleverandørens system kunne fungere på Windows 10 mobile, og hva vil det det innebære og eventuelt bytte til annet operativsystem senere (f.eks Android)? - Hvordan bør et utviklingsløp/utviklingsavtale mellom leverandøren av EPJ-systemet og låsleverandøren formuleres, inkludert verifikasjon av løsning? - Har leverandøren utfordringer med å forholde seg til Å og BØR krav angitt i kapittel «kravspesifikasjon» i dette dokumentet? - Kan løsningen leveres som en skyløsning og/eller inhouse serverløsning, og vil valget påvirke prisen og skalerbarheten? - Kan leverandørene beskrive økonomimodellen for løsningen (lisens, vedlikehold mv.)? - Integrasjonen bør baseres på etablerte standarder. Hvilke kommunikasjonsstandarder anbefaler leverandørene å benytte? - FHIR/HL7 1 som i disse dager blir sterkt anbefalt av Direktoratet for ehelse, kan være en mulig kommunikasjonsmetode. Er dette noe leverandørene er kjent med og har benyttet tidligere? 1 FHIR Fast Healthcare Interoperability Resources (hl7.org/fhir) Side 4 av 16

6 Overordnet beskrivelse Formålet med modell under (fig. 1) er å beskrive våre tanker rundt oppgave- og ansvarsfordelingen mellom EPJ-systemet og låsleverandørens system. obil Server Oslo Kommune Server Låsleverandør App EPJ 8 EPJ-system (fig. 1) 9 Lock obile 1 Bruker OBJEKTER edisin -rom Lokasjon mv. Låssystem EPJ Lock Interface Låseenhet 1 Låseenhet 2 ID1 ID2 Låsleverandørens enheter kommu- Låsleverandørens nikasjonslinje EPJ-systemets kommunikasjonslinje Figur 1 viser i modell hvilke komponenter systemet består av samt oppgave- og ansvarsfordelingen mellom EPJ-systemet og låsleverandørens system. Side 5 av 16

7 Systemer Vi ser for oss at systemet vil bestå av følgende komponenter med nedenstående trinnbeskrivelser: Eksiterende komponenter i dag: EPJ-system (installert i Oslo kommunes datasenter) EPJ Gateway, kommunikasjon mellom EPJ og obile enheter (installert i Oslo kommunes datasenter) EPJ APP på mobil enhet (installert på mobil som er dedikert for bruk i hjemmetjenesten i Oslo kommune) Nye komponenter som følge av denne løsningen: Låseenhet (blir installert på innsiden av dør) EPJ-Lock Interface, kommunikasjon mellom Låsleverandør og EPJ (blir installert i Oslo kommunes datasenter) EPJ-Lock Interface, administrasjon av tilhørighet mellom lås og bruker (blir installert i Oslo kommunes datasenter) Låsleverandørens system (kan installeres i Oslo kommunes datasenter eller som en SAS/skyløsning) Lock obile, Låsleverandørens app/komponent på mobil enhet som kommuniserer med EPJ App på mobil enhet og som sørger for logging og annen kommunikasjon mellom lås og låsleverandørens system (batteristatus, teknisk log, oppdatering fra låsleverandør til lås, ol). (blir installert på mobil som er dedikert for bruk i hjemmetjenesten i Oslo kommune) TRINN BESKRIVELSE 1) EPJ-leverandøren etablerer et Lock Interface (som en del av EPJ installasjonen) på Oslo kommunes server/skyløsning. Låsleverandøren etablerer en Lock obile odul som installeres på kommunens mobilenheter. 2) Hjemmetjenesten eller kommunens låsmontører registrerer monterte låseenheter i EPJ Lock Interface på kommunens server. (Alternativt blir låsene registret i låsleverandørens system og importert til EPJ Lock Interface.) 3) EPJ Lock Interface sender informasjon om registrerte låseenheter til låsleverandørens system 4) EPJ-systemet henter informasjon om registrerte låseenheter i EPJ Lock Interface og knytter låseenhetene til objekter i EPJ-systemet. (Låsleverandøren får ingen informasjon om denne tilknytning) 5) EPJ-system anmoder EPJ Lock Interface om å genere en digital nøkkel til registrerte låseenheter. EPJ Lock Interface sender anmodningen videre til låsleverandørens system. 6) Låsleverandørens system sender de digitale nøkler til EPJ Lock Interface. 7) EPJ-systemet henter de digitale nøkler i EPJ Lock Interface, som knyttes til de objekter i EPJsystemet, hvor der er registrert låseenheter. (Låsleverandøren får ingen informasjon om denne tilknytning) 8) Ansatte i hjemmetjenesten, som har tilgang til objektene i EPJ-systemet, får adgang til låseenhetene og nøklene igjennom EPJ-applikasjonen på mobilenhetene. (Låsleverandøren får ikke styre adgangsrettighetene) 9) EPJ-applikasjonen sender informasjon videre til låsleverandørens Lock obile odul på mobilenhetene, når en ansatt ønsker opp- og igjen-låsing av låseenheten. 10) Låsleverandørens Lock obile odul på mobilenhetene sender informasjonen videre om opp- og igjen-låsing til låseenhetene, og logger hendelsene. Side 6 av 16

8 Logisk/detaljert design Kapitelet beskriver hvilke funksjoner som skal være tilgjengelige og hvordan disse funksjonene henger sammen med arbeidsprosessene. Vi har beskrevet de ulike funksjonsområdene, delsystemene med ansvarsområder og de logiske dataelementene som utveksles mellom EPJ-systemet og leverandørens låssystem. Følgende definisjoner anvendes i avsnittet: User: Ansatt som har ansvar for å hente og koble lås Gerica: Kommunens EPJ-system (Fagsystemet for Helse og omsorg), eksempelvis Gerica eller tilsvarende EDN: Låsleverandørs system inimums-krav (): Bør krav (B) inimumskrav er krav som må oppfylles av tilbudt løsning. -krav som ikke er oppfylt, vil føre til avvisning med mindre Kunden etter en skjønnsmessig vurdering oppfatter avviket som uvesentlig. Summen av flere uvesentlige avvik knyttet til -krav vil likevel kunne anses som vesentlige, og dermed føre til avvisning. Børkrav er krav som kan oppfylles av tilbudt løsning. Vi anser det som et fortrinn om leverandøren kan levere på B-krav og vil vurdere om noen av disse skal inngå som et evalueringspunkt. Dette vil bli tydeliggjort i en utlysning. Registrering av låseenhet (logisk design) Hjemmetjenesten eller kommunens låsmontører registrerer som utgangspunkt en låseenhet i EPJsystemets Lock Interface med følgende opplysninger: 2 - Lock name o Valgt navn på lås - Lock communication address o Kommunikasjonsadressen til låsen (blåtanns-id) - Lock serial number o Låsens serienummer - Lock type o Knytter låsen til aktuell låsleverandør (muliggjør at låser kan leveres av flere leverandører) - Lock description o Valgfri beskrivelse av låsen Der er ønskelig at all kommunikasjon mellom EPJ-system og låssystem kan skje med bakgrunn i «Lock serial number». 2 Om låsleverandør har løsninger omkring installasjon og registering av låser kan «registering av låseenhet» endres, som f.eks: «Hjemmetjenesten eller kommunens låsmontører registrerer informasjon i låsleverandørens system og informasjon overføres til EPJ-systemets Lock Interface med følgende opplysninger:» Side 7 av 16

9 Figur 2 viser hvordan en låseenhet logisk registreres i EPJ-systemets Lock Interface. Det gjøres et valg som knytter låseenheten til riktig låsleverandør (om der finnes flere enn en leverandør). Registrering av låseenhet (detaljert design) PUT url/locks.json Beskrivelse: Returtype: Oppretter en lås fra fagsystemet. JSON å krav: LockSerialNumber String Serienummer til lås LockCommunicationAdress String Kommunikasjonsadresse til lås (Bluetooth, RFid, etc) Side 8 av 16

10 Bør krav: LockName String Navn på lås LockDescription String Beskrivelse til lås, f.eks. «Dør må løftes for å låse opp» Tilknytning av lås med objekt (logisk design) Et objekt kan f.eks. være en bruker (fru Jensen), en geografisk lokasjon, en hoveddør eller et medisinskap. Det er utelukkende EPJ-systemet, som styrer koblingen mellom en låseenhet og et objekt. Ingen informasjon deles med låsleverandøren på dette trinn. Formålet er å kunne tilgangsstyre og administrere låseenhetene gjennom den ansattes tilknytning til objektene i EPJ-systemet. EPJ-leverandøren har av den grunn ansvaret for korrekt tilknytning mellom låseenhetene og de ansatte. Figur 3 viser hvordan koblingen logisk vil skje. Først søkes alle tilgjengelige låser opp i EPJ-systemets Lock Interface og deretter gjøres en kobling mellom et valgt objekt og en eller flere valgte låser Side 9 av 16

11 Tilknytning av lås med objekt (detaljert design) GET url/locks.json (findlocks) Beskrivelse: Returner en liste med tilgjengelige låser Returtype: JSON å krav: {none} Hent alle lås Id Guid/string Hent spesifikk lås Bør krav: List<Id> Liste med Guid/string Hent alle lås med id i liste Returmodell: å krav Lock String Id til lås LockId GuID/string Id på lås Returmodell: Bør krav LockName String Navn på lås LockDescription String Beskrivelse til lås, f.eks. «Dør må løftes for å låse opp» LockExtraInfo Object.json Evt. ekstra informasjon, som type eller plassering. LockType Enum Side 10 av 16

12 Generering av digitale nøkler (logisk design) En digital nøkkel er en samling av informasjon, som gjør opp- og igjen-låsing av låseenhetene mulig. En digital nøkkel skal genereres av låsleverandørens system når EPJ-systemets Lock Interface ber om dette. Anmodningen vil inneholde opplysninger om Låseenhetenes «Lock serial number» og informasjon om nøkkelens gyldighet (tidsrommet for når nøkkelen kan anvendes). En anmodning om generering av nøkkel kan være basert på ulike hendelser i EPJ-systemet. Eksempel: EPJ-systemet finner hvilke objekter et oppdrag skal inneholde, når oppdraget skal utføres og hvor lang tid oppdraget skal ta (estimert). Et objekt kan ofte være en bruker eller flere brukere (geografisk lokasjon), som skal ha hjemmebesøk. Det kan også være et medisinrom, en vaskekjeller, etnøkkelskap eller likende, som en ansatt skal ha adgang til. Hvis et objekt er koblet til en låseenhet, vil EPJ-systemet anmode leverandørens låssystem om å få generert en digital nøkkel. Varigheten på nøkkelen vil være basert på oppsett i EPJ-systemet. Når den digitale nøkkel er generert legges den tilknyttet objektet som er tilknyttet oppdraget slik at den vil være tilgjengelig på mobilenheten til den ansatte, som har oppdraget. Dersom et oppdrag blir overtatt av en annen ansatt må den genererte nøkkelen følge med. Figur 4 viser hvordan en nøkkel logisk genereres ved opprettelse av vanlige oppdrag i EPJ systemet. Nøkkelen knyttes da til oppdraget i EPJ-systemet. Side 11 av 16

13 Figur 5 viser hvordan en nøkkel logisk genereres ved akutte oppdrag. Nøkkelen knyttes til en bruker, som søkes opp i EPJsystemet. Ansatte med direkte tilknytning til brukeren vil kunne anvende nøkkelen. Generering av digitale nøkler (detaljert design) GET url/keys.json Beskrivelse: Returtype: Returner en/en liste med generert(e) digitale nøkler JSON å krav: Ids List<guid/string> Liste over id er på låser man vil generere for Side 12 av 16

14 Bør krav: ValidFrom DateTime Tidspunkt man vil nøkkel skal være gyldig fra ValidTo DateTime Tidspunkt man vil nøkkel skal være gyldig til Returmodell - å krav: Key Object.json Nøkkel Opp- og igjen-låsing og logging (logisk design) På helse- og omsorgstjenestens mobilenheter, vil den ansatte ha adgang til å anvende de digitale nøkler, som er tildelt den ansatte igjennom EPJ-systemet. Ved anvendelse sendes den digitale nøkkel videre til leverandørens applikasjon på mobilenheten, som håndterer den videre kommunikasjon med låseenheten. Låsleverandørens applikasjon skal logge alle hendelser i forbindelse med opp- og igjen-låsing samt teknisk informasjon (batterikapasitet, o.l.). Det må være mulig å lese låsleverandørenes logginformasjon fra EPJ. Logger i EPJ og logger hos låsleverandøren, må inneholde tilstrekkelig informasjon slik at disse kan kobles mot hverandre. Figur 6 beskriver hvordan EPJ skal kunne hente logg fra forskjellige låsleverandører. Side 13 av 16

15 Opp- og igjen-låsing og logging (detaljert design) GET url/log.json Beskrivelse: Returner logghendelse(r) Returtype: JSON å Parametere: {} Henter alle logghendelser LockId Guid/string Hent alle logghendelser for en lås Bør Parametere: From DateTime Tidspunkt man vil hente logger fra To DateTime Tidspunkt man vil hente logger til Returmodell: å Parametere Date DateTime Når hendelsen oppstod Type String? Type logghendelse Log Object.json Logg Side 14 av 16

16 Utkast til kravspesifikasjon I dette avsnitt har vi oppsummert de vesentligste krav til integrasjonsløsningen. Kravene er delt opp i henholdsvis krav til låsleverandøren og krav til EPJ-leverandøren. Krav til låsleverandøren Pkt. Beskrivelse Integrasjonsløsningen må kunne utnytte gjeldene tilgangsstyring i EPJ. ed tilgangsstyring menes at den ansatte får tilgang til nøkkelen ut fra at man har tilgang til brukeren og skal utføre et oppdrag hjemme hos bruker. Leverandøren må levere et åpent API, som kan fungere mot ulike EPJ-systemer Det vektes positivt, hvis leverandøren også kan levere et låssystem, som kan fungere som en stand-alone uten integrasjon til EPJ-system. Dette låssystem skal eksempelvis kunne anvendes av brukeren selv og dennes pårørende, andre tjenester innen for helse og omsorg og evt. privattjenester Integrasjonsløsningen må understøtte knytting av uendelige antall låser (eks. 56 låser knyttet til Solvang helsehus, 15 låser knyttet til bruker) Integrasjonsløsningen må ikke lagre sensitive opplysninger i låsleverandørens systemer Nødvendig informasjon/kommunikasjon mellom fagsystem/mobil enhet og låsleverandørs systemer bør holdes til et minimum. Jo mindre informasjonsutvekslingen desto bedre. Nødvendig kommunikasjon mellom låsleverandørs systemer og EPJ-system/EPJsystemets mobilapplikasjon må etableres fra EPJ-systemet/EPJ-systemets mobilapplikasjon. Integrasjonsløsningen må kunne benyttes på samme type utstyr/operativsystem/versjon av operativsystem som fagsystemets mobile applikasjoner støtter. Løsningen skal ikke kreve egen installasjon på den mobile enheten. Nødvendige komponenter skal installeres sammen med fagsystemets mobile applikasjon. Løsningen må kunne være uavhengig av om låsleverandørers back-end-systemer kjøres i Oslo kommunes datahaller eller som en skyløsning. Integrasjonsløsningen skal logge opp- og igjen-låsing og på anmodning levere informasjonen til EPJ-systemet samt teknisk informasjon (batterikapasitet, o.l.). Ansatte må kunne nå låsleverandørens administrasjonssystem fra sin arbeidsflate inne i EPJ-systemet. Leverandøren skal til en hver tid kunne leve opp til sikkerhetskravene i Oslo kommune i forhold til hvilken informasjon som kan utveksles imellom systemene. Oslo kommune er forpliktet til å holde leverandøren orientert om eventuelle endringer i sikkerhetskravene. All kommunikasjon mellom de ulike delsystemene (mobil applikasjon, fagapplikasjon, låssystem) må sikres. I dette ligger både autentisering, autorisasjon og evt. kryptering av data. Type B B /B? /B? /B? /B? Side 15 av 16

17 Krav til EPJ-leverandørene Pkt. Digitale nøkler i hjemmetjenesten Integrasjonen må ikke forhindre andre leverandører av elektroniske låssystemer i å kunne bli integrert med EPJ Løsningen må være bygget slik at den kan integreres mot låsleverandører basert på definerte/faste grensesnitt Løsningen må kunne knytte nøkkel til oppdrag i EPJ. (tilgang til å låse opp en dør bør gis til et oppdrag eks. hjemmebesøk) Løsningen må kunne knytte nøkkel til bruker i fagsystemet. (tilgang til å låse opp en dør må gis pr. bruker, eks. opplåsning fra brukerkort når ansatt har tilgang til bruker) Løsningen bør kunne knytte nøkkel til ansatt i fagsystemet. (tilgang til å låse opp en dør bør gis pr. ansatt, eks. vaktrom, medisinrom) Løsningen bør kunne knytte nøkkel til et geografisk sted/nivå i fagsystemet. (tilgang til å låse opp en dør bør gis pr. lokasjon, eks. Solvang helsehus) Løsningen skal levere informasjon om hvem som har låst opp, igjen låsen i EPJ Type B B Side 16 av 16