Referencearkitektur for Sporbarhed og Emneidentifikation i Region Midtjylland

Transkript

1 Referencearkitektur for Sporbarhed og Emneidentifikation i Region Midtjylland Version Region Midtjylland It -arkitektur 02/2013

2 Revisioner og godkendelser Dato Revision Kommentar Initialer Dokumentstruktur godkendt. Afsnit udfyldt og løbende godkendt Dokumentet færdigt. Efterfølgende godkendt af Region Midtjyllands Programstyregruppe for Itunderstøttelse af Logistik gennem Sporbarhed og Emneidentifikation Dokumentet flyttet fra at være tilknyttet DNU til at være regionalt dækkende. Vedligeholdelsen ligger hos It-arkitektur. Layout og branding afspejler dette. Konteksten for referencearkitekturens mål er udvidet til at omfatte hele Region Midtjylland. Der optræder stadig eksempler hvor DNU anvendes som logisk afgrænsning. Disse eksempler bibeholdes, med en målsætning om gennemarbejdning senere. Det er forsøgt tydeliggjort med redaktionelle kommentarer, hvor DNU er valgt som logisk kontekst Dokumentet er omstruktureret således at det lettere kan benyttes i andre organisationer end Region Midtjylland. Beskrivelse og forklaringer er gjort klarere en række steder baseret på modtagne kommentarer. Følgende egentlige ændringer af krav/arkitektur er foretaget: Muligheden for håndtering af geografiske koordinater er uddybet i afsnit og De ensartede krav til snitfladen mellem Lag 3/4 (afsnit 5.3.3), hhv. Lag 4/5 (afsnit 5.3.2) er nu formuleret ens. Skaleringskravene for DNU er opdateret med nyeste kendte tal (Appendiks A.1.2) DP DP HS HS Spørgsmål til dokumentet kan stilles til It-arkitekt Henrik Stilling, [email protected] Side 2

3 Indholdsfortegnelse 1 Introduktion Formål Definition af referencearkitektur Proces for udarbejdelse Læsevejledning Vedligehold af dokumentet Ordliste Referencer Vision og mål Vision Kontekst Afgrænsning Rammer og krav Funktionelle krav Lovgivning og regler Interoperabilitet Eksisterende systemer Sikkerhed Oppetid Svartider Drift Snitflader Sporingsteknologier Typer af sporingsteknologier Konkrete teknologier Standardiseringsområder Arkitekturprincipper En lagdelt arkitektur Generelle principper Standarder Identitet Ansvarsfordeling Administration Lokaliteter Filtrering Fejlhåndtering Svartider Sikkerhed Arkitekturbeskrivelse Funktionalitet Information Miljø Sikkerhed Svartider Skalering Fleksibilitet Konklusion Side 3

4 Appendiks A. Implementering i Region Midtjylland A.1 Regionsspecifikke krav A.2 Regionsspecifikke arkitekturvalg Appendiks B. Sporingsteknologier og standarder B.1 Stregkoder B.2 RFID B.3 Wi-Fi B.4 UWB B.5 GPS B.6 Sensornetværk B.7 DECT B.8 GSM B.9 Bluetooth B.10 Infrarød B.11 Ultralyd B.12 Billedgenkendelse B.13 Biometri B.14 Bevægelsesfølere B.15 Stemmegenkendelse Appendiks C. Administrationsprocesser C.1 Generelle anbefalinger C.2 Udrulning af integrationssystemet C.3 Udrulning af nyt sporingsprojekt C.4 Overvågning C.5 Løbende driftsopgaver C.6 Afslutning af sporingsprojekt Appendiks D. Arkitekturvalidering D.1 Kravopfyldelse D.2 Scenarieopfyldelse D.3 Teknologiunderstøttelse Side 4

5 Resumé Teknologier som RFID og Wi-Fi giver mulighed for at identificere og positionsbestemme personer og fysiske genstande automatisk. Dette åbner op for en række produktivitetsforbedrende og tilfredshedsskabende tiltag i sundhedsvæsenet, eksempelvis automatisk optælling af varelagre, eller søgning efter udstyr og personer. I dette dokument beskrives en referencearkitektur, som er gældende for alle itsystemer, relateret til sporbarhed og emneidentifikation i Region Midtjylland. Arkitekturen vil også kunne anvendes i andre lignende organisationer. Formålet med Referencearkitekturen er at opstille mål og rammer for sådanne systemer, således at ressourcer udnyttes mere effektivt og der tages passende hensyn til de langsigtede og helhedsorienterede interesser. Det centrale element i Referencearkitekturen er et integrationssystem, som opsamler og udstiller sporingsdata ved hjælp af etablerede standarder. Herved afkobles de systemer, som producerer sporingsdata, fra de systemer, som anvender sporingsdata. Resultatet er mere genbrug og færre integrationsproblemer. Som en del af kravene til Referencearkitekturen beskrives en række potentielle fremtidige projekter, der anvender automatisk identificering eller positionsbestemmelse. Ligeledes beskrives de teknologier og standarder, som findes, eller er på vej, til automatisk identificering eller positionsbestemmelse. Et andet vigtigt element af Referencearkitekturen er en kortlægning af de aktiviteter, som er nødvendige for at sikre en sund udvikling af sporbarhedsløsninger på lang sigt. Referencearkitekturen bidrager således til at gøre det mere effektivt og langtidsholdbart at indføre sporingssystemer, sådan at hospitalerne kan få del i det store potentiale, som findes i moderne sporbarhedsløsninger. Side 5

6 Side 6

7 1 Introduktion Automatisk identifikation og positionsbestemmelse af personer og fysiske genstande åbner op for en række tidsbesparende og produktivitetsforbedrende muligheder i sundhedsvæsenet. I dette dokument beskrives en referencearkitektur, som er gældende for alle itsystemer, der relaterer sig til sporbarhed og emneidentifikation i Region Midtjylland. Formålet er at afstikke mål og rammer for sådanne systemer, således at ressourcer udnyttes mere effektivt og integrationsproblemer minimeres. 1.1 Formål De teknologiske muligheder for at følge personers og fysiske genstandes position, udendørs såvel som indendørs, er efterhånden ved at være modne og bliver stadigt bedre. Dette åbner op for et bredt spektrum af effektiviseringsmuligheder overalt i samfundet - også i sundhedssektoren. Dette dokument beskriver en referencearkitektur for sporbarhed og emneidentifikation, der skal fungere som pejlemærke og fælles ramme for projekter relateret til positionering, sporbarhed og automatisk identifikation. Målet er at lette udveksling af sporingsrelaterede informationer og udnytte investeringer i sporingsrelaterede systemer mere effektivt. Referencearkitekturen består af to dele: Dels en generisk arkitektur målrettet hospitaler og dels en specifik anvendelse af denne arkitektur til Region Midtjylland beskrevet i Appendiks A. Den generiske arkitektur er designet med hospitaler for øje, enten enkelte hospitaler eller organisationer der omfatter flere hospitaler. Arkitekturen vil dog også kunne finde anvendelse i andre typer organisationer som ønsker at indføre sporing. Nogle eksempler på projekter som hører indenfor rammerne af Referencearkitekturen er: Opsætning af Wi-Fi-netværk, som kan anvendes til positionering Mærkning af apparatur med RFID-brikker, således at deres position registreres Indkøb af brugersystem, som giver en alarm, hvis udstyr forlader et hospital Implementering af system til søgning efter ledigt udstyr Anvendelse af en referencearkitektur for sporbarhed og emneidentifikation (i det følgende kaldet Referencearkitekturen ) vil have en række fordele, herunder: Medvirke til at fremtidige systemer, der anvender Referencearkitekturen, kan tale sammen Lette adgangen til og dermed værdien af sporingsdata Medvirke til genbrug og mindre suboptimering på tværs af systemerne Simplificere integrationen mellem disse systemer Side 7

8 Levere en begrebsramme til at tale om sporbarhed og emneidentifikation Danne grundlag for valg af ambitionsniveau baseret på en omkostningsvurdering Give inspiration til nye systemer eller ændringer af eksisterende systemer, så de tilgængelige data udnyttes mest muligt Indgå i kravene ved indkøb af it-løsninger Danne basis for igangsættelse af pilotprojekter. I Afsnit 2, Vision og mål, beskrives mål og afgrænsning af Referencearkitekturen i større detalje. Her defineres også mere præcist, hvad der menes med sporbarhed og emneidentifikation. 1.2 Definition af referencearkitektur En referencearkitektur beskriver de nødvendige fælles rammer for et antal it-systemer indenfor et bestemt område, med udgangspunkt i velafprøvede løsninger. Problemerne med it-systemer, der beskæftiger sig med samme eller overlappende informationer, men udvikles uden at kunne udveksle disse informationer, er velkendte. Hovedproblemet ligger ofte i manglende kendskab til, hvilke andre systemer, der skal udveksles informationer med i fremtiden. Nogle gange er det ikke muligt at forudsige disse integrationer, for eksempel ved sammenlægninger af organisationer. Ved integration af it-systemer uden overordnet styring kompliceres opgaven væsentligt for hvert system der tilføjes. To systemer med hver deres definitioner og fortolkninger af virkeligheden kan være vanskelige at integrere - med fem eller ti systemer bliver det mange gange sværere. Løsningen på disse udfordringer ligger i standardisering, dvs. anvendelse af fælles, præcise definitioner af begreber, arbejdsgange og hændelser, anvendelse af fælles tekniske protokoller til sammenkobling af systemerne, og fælles eller koordinerede arbejdsgange omkring vedligeholdelse og drift af systemerne. Denne standardisering er det centrale element i en referencearkitektur. Et andet problem ved relaterede systemer, der udvikles uden overordnet koordinering, er funktionalitet som går igen i flere systemer. Denne redundans resulterer i spildte timer til udvikling og vedligehold af systemerne, giver unødvendigt komplicerede integrationer, og besværliggør forståelse, brug og administration af systemerne. En referencearkitektur udpeger de komponenter der bør genbruges på tværs af systemer. En referencearkitektur skal defineres bredt nok til at dække alle relevante fremtidige systemer. Derfor er det vigtigt at tage udgangspunkt i både de aktuelle brugsscenarier og de mere langsigtede visioner for løsningen. En referencearkitektur skal defineres tilstrækkeligt detaljeret til at opnå de ønskede integrationsmuligheder, men uden at begrænse systemerne unødigt. Derfor er fokus på de beslutninger om standarder, snitflader, driftsprocesser osv., som er nødvendige at træffe for at opnå målene med Referencearkitekturen, og overlade alle øvrige beslutninger til de konkrete systemer. Side 8

9 1.3 Proces for udarbejdelse Dette dokument er produceret i tæt og løbende dialog mellem Projektafdelingen på Det Nye Universitetshospital i Aarhus og dens rådgivere, med inddragelse af it-ledelse, relevant hospitalspersonale og it-arkitekturfunktionen i Region Midtjylland. Udarbejdelsen af Referencearkitekturen er foretaget på baggrund af beslutning i DNU it-forum d. 29. oktober Rapporten er oprindelig afleveret til DNU it-forum d. 9. juni Ejerskabet er overført til It-arkitektur marts Dokumentet er godkendt af Region Midtjyllands Programstyregruppe for It-understøttelse af Logistik gennem Sporbarhed og Emneidentifikation. 1.4 Læsevejledning Dokumentet er tiltænkt beslutningstagere og personer, der deltager i indkøb eller udvikling af systemer i relation til sporbarhed og emneidentifikation. Hoveddokumentet er holdt i generelle termer, mens Appendiks A beskriver forhold som forventes at være specifikke for Region Midtjylland. For at lette denne generelle anvendelse benyttes betegnelsen organisationen i det følgende om den organisation der vælger at indføre Referencearkitekturen. Hvis der ønskes et hurtigt overblik over hele dokumentets indhold, anbefales det at læse de grå bokse i starten af hvert hovedafsnit. Et spadestik dybere kommer man ved at læse de øvrige grå bokse i selve teksten. Her følger en beskrivelse af indholdet af hvert hovedafsnit: Afsnit 2, Vision og mål, beskriver målene med Referencearkitekturen og hvorledes arkitekturen er afgrænset i forhold til det samlede systemkompleks. Her beskrives også, i hvilke situationer Referencearkitekturen er relevant, og afsnittet er således vigtigt for alle, som skal implementere dele af Referencearkitekturen eller på anden måde træffe beslutninger, der kan være relevante i forhold til sporbarhed og emneidentifikation. Afsnit 3, Rammer og krav, beskriver de forventninger, der blev opstillet til Referencearkitekturen under dennes udarbejdelse, ikke mindst hvilke it-projekter arkitekturen skulle kunne understøtte. Afsnittet er derfor relevant for læsere, som er interesserede i at vide, hvad Referencearkitekturen kan bruges til, eller hvorfor den ser ud som den gør. Desuden er afsnittet relevant som grundlag for eller bilag til kravspecifikationer i forbindelse med indkøb af sporingsinfrastruktur og relaterede produkter. Afsnit 4, Sporingsteknologier, giver en introduktion til de teknologer, der findes til sporing og identifikation, herunder hvad deres fordele og ulemper er, samt hvilke standarder der findes på området. Afsnittet er hovedsageligt rettet mod personer som skal vælge blandt disse teknologier eller ønsker at forstå hvilke teknologier Referencearkitekturen skal kunne håndtere. Yderligere detaljer kan findes i Appendiks B. Afsnit 5, Arkitekturprincipper, indeholder den centrale beskrivelse af selve Referencearkitekturen, nemlig de vigtigste valg som er foretaget og baggrunden for disse valg. Side 9

10 Dette afsnit bør læses af alle, der er involveret i planlægning, implementation eller drift af aktiviteter, som falder indenfor rammerne af Referencearkitekturen, jfr. Afsnit 2. Afsnittet er relevant som grundlag for eller bilag til kravspecifikationer i forbindelse med indkøb af sporingsrelaterede produkter. Afsnit 6, Arkitekturbeskrivelse, er en mere beskrivende og teknisk præsentation af Referencearkitekturen. De første figurer i afsnittet giver et overblik over elementerne i arkitekturen, hvilket kan være et interessant supplement til Afsnit 4. Detaljerne senere i afsnittet er af teknisk karakter og mest relevant for arkitekter, udviklere og driftspersonale. Afsnit 7, Konklusion, opsummerer hovedresultaterne og beskriver hvorledes Referencearkitekturens målsætninger, som beskrevet i Afsnit 1.1, er opfyldt. Appendiks A, Implementering i Region Midtjylland, beskriver krav og valg som forventes at være specifikke for Region Midtjylland. Appendiks B, Sporingsteknologier og standarder, er en mere detaljeret beskrivelse af de mest kendte sporingsteknologier og relaterede standarder. Afsnittet er relevant hvis man ønsker uddybning af nogle af informationerne i Afsnit 4, Sporingsteknologier. Appendiks C, Administrationsprocesser, beskriver de administrationsopgaver som findes i relation til sporbarhed og emneidentifikation. Dette afsnit er relevant for alle som skal estimere, planlægge eller udføre dette arbejde. Appendiks D, Arkitekturvalidering, er en gennemgang af, hvordan Referencearkitekturen opfylder kravene med referencer til relevante tidligere afsnit. Afsnittet kan benyttes til at finde ud af i hvilken grad og hvordan et bestemt krav eller brugsscenarie er opfyldt. 1.5 Vedligehold af dokumentet Referencearkitekturens anbefalinger vurderes at have en holdbarhed frem til Senest på dette tidspunkt bør indholdet gennemgå en grundig revision for at validere at analyser og vurderinger ikke er blevet forældede af den teknologiske udvikling. Informationerne om dimensionering af løsningen i Appendiks A.1.2, er baseret på de informationer som er til rådighed i januar Efterhånden som arbejdsgange mv. fastlægges, bør dette afsnit opdateres, således at det afspejler virkeligheden bedst muligt. Ved større ændringer bør de relevante dele af Afsnit 5, Arkitekturprincipper, og Afsnit 6, Arkitekturbeskrivelse, genovervejes. Referencearkitekturens anbefalinger omkring standarder i Afsnit 5.3 og Afsnit 6.2 bør genovervejes mindst hvert andet år, samt i forbindelse med større beslutninger baseret på Referencearkitekturen, eksempelvis opstart af nye projekter eller nye versioner af relevante standarder. Alle ændringer og godkendelser af dokumentet skal registreres i afsnittet Revisioner og godkendelser. Side 10

11 1.6 Ordliste Begreb Anvendelsessystem Central sporingsinfrastruktur EPC GID Hændelse Id-brik Integrationssystem til Sporing og Identifikation Integrationssystemet ISSI Lokalitet Læser Mærkat Organisationen Definition Et softwaresystem som anvender sporingsdata. Et eksempel på et fremtidigt anvendelsessystem er EPJ. Et anvendelsessystem kan også tilhøre andre organisationer, f.eks. en leverandør. Integrationssystem til Sporing og Identifikation samt de centrale services, databaser, hardware mv., der skal til for at køre dette system. Electronic Product Code. En standard for globalt unikke id er defineret af EPCGlobal. Genuine id. Det reelle id på det objekt som spores, eksempelvis en persons personnummer, i modsætning til PID, som er den id, der opbevares på personens id-brik. Benyttes som synonym for Sporingshændelse. En elektronisk enhed eller et mærkat, hvorfra man kan aflæse et id, f.eks. ved hjælp af laser eller radiobølger. Eksempler på id-brikker er stregkoder, id-kort med magnetstribe, RFID-brikker, Wi-Fi-enheder som udsender id. Det softwaresystem som afkobler anvendelsessystemer og sporingssystemer. Samme som Integrationssystem til Sporing og Identifikation. Forkortelse for Integrationssystem til Sporing og Identifikation. Et sted som har relevans for sporing. Det kan være et sted på eller udenfor et hospital. Eksempler på lokaliteter er Afdeling Q, Indgangsdør 3, bygning 1, Operationslokale 512, Reol 31 i lagerrum 85, Hovedapoteket. Det stykke hardware som aflæser en id-brik. Eksempler på læsere er stregkodeskannere, RFID-antenner, Wi-Fiadgangspunkter. Andet ord for id-brik, især når denne kan klistres på et objekt. Den organisation som indfører Referencearkitekturen, eksempelvis Region Midtjylland. Side 11

12 PID Referencearkitekturen Sporing Sporingsdata Sporingshændelse Sporingsløsning Sporingsrelateret system Sporingssystem Tag Pseudo-id. Det id der opbevares på en id-brik i modsætning til GID, som er personens eller tingens reelle id, f.eks. personnummer. Samme som Referencearkitektur for Sporbarhed og Emneidentifikation. Benyttes som synonym for sporbarhed og emneidentifikation. Se også definitionen i Afsnit 2.3 Afgrænsning. Automatisk registrerede data af fysiske objekters identitet og eventuelt bevægelse. En samling af sporingshændelser. En enkelt registrering af et antal fysiske objekters identitet og position på et bestemt tidspunkt. Den hardware og software der tilsammen gør det muligt at opsamle sporingsdata. Eksempelvis en Wi-Fi-installation der kan positionere Wi-Fi-enheder og udstille disse positioner til andre systemer. Et anvendelsessystem eller et sporingssystem. Et softwaresystem som opsamler og videreformidler sporingsdata. Dvs. software-delen af en sporingsløsning. Engelsk betegnelse for elektronisk id-brik. Side 12

13 1.7 Referencer Navn Beskrivelse Reference [It-understøttelse af Rapport: It-understøttelse af patient-, Delprojekt F2-01, It Hovedaktiviteter, logistik, 2010] ressource- og transport logistik [Persondataloven] [Liu et al, 2009] Lov om behandling af personoplysninger Survey of Wireless Indoor Positioning Techniques and Systems [awarepoint-wifi, 2009] Real-time Location Systems (RTLS) in Healthcare [Fredslund et al, 2010] [Khaji et al, 2008] Positionering når vi ved hvor tingene er RFID in the Healthcare and Pharmaceutical Industry [makebarcode, 2011] Makebarcode.com - Barcode Basics [gs1, 2011] GS1.com - BarCodes & Identification [stg-comp, 2011] How does ZigBee compare with other wireless standards? [AIDC, 2010] AIDC Healthcare Implementation Guide [GS1 HCS, 2011] GS1 Standards at use in the Healthcare sector [GS1 HCR, 2011] GS1 Healthcare Reference Book [HIBCC, 2011] Health Industry Business Communications Consortium [BuyRFID, 2011] BuyRFID.com [EPCGlobal, 2011] EPCglobal Standards Overview [NFC-phones, 2011] A definitive list of NFC phones [Assetmgt, 2010] RFID Asset Management In Healthcare [Ekahau, 2009] Wi-Fi RTLS: The Myths vs. the Facts, Ekahau.com [ISO24730, 2011] ISO/IEC : [wusb, 2011] Wireless USB from the USB-IF [medical-uwb, 2008] Medical Applications of Ultra-WideBand Side 13

14 [Chóliz et al, 2010] [Kjærgaard et al, 2010] Architectures for Location Data Acquisition and Distribution in UWB Indoor Tracking System Indoor Positioning Using GPS Revisited [ESA, 2011] European Space Agency, Galileo News [GPS Accuracy, 2011] GPS Accuracy - How Accurate is it? [ZBHC, 2011] ZigBee HealthCare [InfraCom, 2011] InfraCom: DECT Systems [Ekahau-DECT, 2010] [RTX-DECT, 2011] Ekahau Brings Location Tracking Technology to NEC's DECT Handsets RTX improves DECT technology from 9Kbit/s to 56Kbit/s [ETSI, 2011] ETSI DECT [BT, 2011] [Versel, 2010] The Official Bluetooth Technology Website Microsoft's Xbox Kinect might have some interesting healthcare uses [Woodman, 2007] An introduction to inertial navigation [Falavigna, 2011] Speaker Identification and Verification [Globalsecurity, 2011] Automatic Voice Identification Side 14

15 2 Vision og mål Referencearkitekturen skal bidrage til øget effektivitet og forbedret tilfredshed blandt patienter og personale gennem automatisk identifikation og positionsbestemmelse af personer og genstande. Arkitekturen skal gøre det effektivt og langtidsholdbart at indføre systemer, som anvender identifikation og positionsbestemmelse, gennem en afkobling fra de teknologier, der leverer disse services. 2.1 Vision At automatisk identificering og positionering af personer og genstande har store perspektiver for effektivisering af hospitalsdriften bekræftes af hospitaler som allerede har indført dette (se [It-understøttelse af logistik]). Perspektiverne inkluderer overordnede målsætninger som højere produktivitet, lavere omkostninger, kortere behandlingsforløb og øget patienttilfredshed. Indførelse af automatisk identificering og positionering kan bidrage til at opnå følgende målsætninger: Reduktion af tid brugt på at lede efter personer og genstande Øget patientsikkerhed ved automatisk alarmering i risikosituationer og validering af beslutninger Mindre spildtid gennem mere præcis koordinering af arbejdsgange og øget situationsbevidsthed Kontinuerlig optimering af arbejdsgange ved analyse af de faktiske arbejdsgange Hurtigere identificering af personer og genstande overfor it-systemer Mindre omkostninger til udstyr gennem mere effektiv udnyttelse og mindre spild Oplevelse af øget serviceniveau blandt patienter og besøgende som følge af mere smidige processer og hjælp til at finde personer og steder Reduktion af decentral lagerkapacitet på grund at øget indsigt i aktuel lagerbeholdning Fuldautomatisering af visse arbejdsopgaver som for eksempel overvågning af lagerbeholdninger. Udover disse punkter forventes indførelse af automatisk identifikation og positionsbestemmelse i det daglige arbejde at lede til en række nye ideer til andre anvendelser, som vil bidrage yderligere til at skabe mere sundhed for pengene og mere tilfredse patienter. 2.2 Kontekst Referencearkitekturen indgår i et komplekst system af mennesker, arbejdsgange, itsystemer og infrastruktur, som alle er under konstant udvikling. Side 15

16 De væsentligste hensyn er skitseret i Figur 1. Eksisterende anvendelsessystemer Mulige fremtidige anvendelsessystemer Brugere og processer Sundhedspersonale, patienter, it-drift, administrativt personale, etc. Infrastruktur Bygninger, hardware, netværksinfrastruktur, andre hospitaler, eksterne samarbejdspartnere, etc. Kliniske systemer, administrative systemer, økonomisystemer, etc. Eksisterende teknologier Stregkoder, Wi-Fi, etc. Referencearkitektur for sporbarhed og emneidentifikation Lokaliseringssystem, portørsystem, GIS, kommunikationssystem, etc. Mulige fremtidige teknologier RFID, GPS, GSM, UWB, Bluetooth, DECT, Ultralyd, etc. Andre referencearkitekturer og it-politikker Netværksinfrastruktur, autentificering, telefoni, etc. Regler og lovgivning Persondataloven, datapolitikker, etc. Figur 1: Systemer og andre faktorer der påvirker Referencearkitekturen. Referencearkitekturen skal hjælpe brugerne til at opnå de ovenfor beskrevne mål om effektivisering ved at stille nye services til rådighed for nuværende og fremtidige anvendelsessystemer. Disse services baseres på en sammenkobling og generalisering af den tilgængelige teknologiske infrastruktur til automatisk identificering og positionering, således at anvendelsessystemerne afkobles fra denne infrastruktur. Referencearkitekturen skal således sikre at anvendelsessystemer og underliggende teknologier kan udvikle sig uafhængigt af hinanden uden for store gensidige påvirkninger. Sporbarhed og emneidentifikation er blot et aspekt af it-landskabet. Anvendelsessystemerne trækker på en lang række andre services, ligesom de anvendte teknologier vil have andre formål end blot identificering og positionering. Den omkringliggende infrastruktur, såsom bygninger, hardware og andre genstande, er af afgørende betydning for, hvor præcist genstande kan positioneres og hvilke processer, der skal etableres i relation til disse. Eksisterende love, regler, standarder, politikker og procedurer for behandling af data, kommunikation, sikkerhed osv. er ligeledes aspekter, som har betydning for Referencearkitekturen. 2.3 Afgrænsning En klar definition af formålet med et it-system er forudsætningen for et overskueligt og langtidsholdbart system. Uklare grænser for systemet giver uklare snitflader og ansvar. Det er derfor vigtigt at præcisere, hvad Referencearkitekturen skal dække og hvad den ikke skal dække. Nøgleordene for Referencearkitekturen er sporbarhed og emneidentifikation, dvs. dels det at kunne identificere personer eller genstande og dels det at kunne positionsbe- Side 16

17 stemme disse. I det følgende benyttes begrebet sporing som en fællesbetegnelse for sporbarhed og emneidentifikation. Grunden til at disse to begreber behandles under et, er at positionsbestemmelse hører uløseligt sammen med identifikation. En persons position har væsentlig mindre interesse, hvis man ikke ved hvem personen er. Mange af teknologierne til positionsbestemmelse kan i stigende grad også opsamle andre former for informationer. For eksempel findes der RFID-brikker, som kan måle temperatur, bevægelse og fugtighed eller foretage egentlige biokemiske analyser. Der findes også id-brikker, der tilbyder simple brugerflader med knapper, feedback, osv. Problemet ved at lave en referencearkitektur, som dækker alt dette i detalje, er at det ikke er muligt at forudsige, hvilke typer data, der kan opsamles om blot få år. På den anden side er det også vigtigt, at opsamling af disse fremtidige data kan lade sig gøre uden at Referencearkitekturen skal ændres. Referencearkitekturen har derfor følgende overordnede ansvar: Automatisk registrering af mobile objekters identitet og position på et givent tidspunkt. Desuden registrering af evt. samtidigt opsamlede informationer uden fortolkning af disse. Aspekter, der ikke er dækket af denne definition, er for eksempel radiokommunikation mellem personer, fortolkning af opsamlede kliniske data, traditionelle bygningssensorer og manuel indtastning af informationer. I mange tilfælde vil Referencearkitekturen godt kunne understøtte situationer, som er udenfor ovennævnte definition, men arkitekturens understøttelse af disse er ikke valideret. Referencearkitekturen definerer ikke hvilke brugerrettede it-systemer, der skal eksistere eller hvordan disse generelt set kommunikerer med hinanden. Men den definerer de snitflader som disse systemer skal bruge, hvis der anvendes eller produceres informationer, som falder indenfor ovenstående definition. Referencearkitekturen skal kunne rumme alle tænkelige sporingsteknologier. For at illustrere betydningen af ovenstående definition, gives i det følgende en række eksempler på konkrete systemer, som ligger indenfor henholdsvis udenfor Referencearkitekturens ansvarsområde Eksempler som er dækket af Referencearkitekturen Sporing af senge: Alle senge overvåges ved hjælp af Wi-Fi-brikker for at optimere processerne med transport, rengøring, opredning osv. Dette eksempel er dækket af Referencearkitekturen da sengens identitet og position opsamles automatisk. Modtagelse af varer: Varer er fra leverandørens side påhæftet RFID-brikker for at kunne følge varernes bevægelse. Referencearkitekturen dækker dette eksempel da varernes identitet og position opsamles automatisk. Side 17

18 Adgangskort til bygninger: En person kører sit id-kort igennem en kortlæser ved indgangsdøren. Dette eksempel er dækket af Referencearkitekturen, da både personens identitet og dennes position registreres, sidstnævnte eventuelt implicit ved at kortlæserens position er kendt. Skanning af patient og medicin: I forbindelse med udlevering af medicin skannes både patienten og medicinbeholderen for at sikre, at den korrekte medicin udleveres. Selvom registrering af positionen ikke er det primære, registreres også implicit en position, eventuelt med en meget lav præcision. For eksempel registreres det at udleveringen er foretaget på et bestemt hospital. Derfor er eksemplet indenfor rammerne af Referencearkitekturen. Stress-sensor i patientens armbånd: En stress-sensor er monteret på patientens armbånd, således at dennes velbefindende kan overvåges. Patientens identitet registreres og det gør vedkommendes position også, direkte eller indirekte. Stressniveauet opsamles og videresendes ufortolket til et system, som kan fortolke informationen. Temperatur-sensor på medicinbeholder: En temperatur-måler er sat fast på en medicinbeholder for at sikre at denne opbevares korrekt. Beholderens identitet registreres sammen med dennes position. Temperaturen opsamles og videresendes ufortolket til et system, som kan fortolke informationen Eksempler som ikke er dækket af Referencearkitekturen Bevægelsesfølere i lokaler: En infrarød sensor registrerer personers bevægelse i et lokale. Disse sensorer registrerer ikke identiteten på den der bevæger sig og er derfor ikke dækket af Referencearkitekturen. Manuel indtastning af målinger: Personalet indtaster manuelt personens identitet samt målinger såsom temperatur eller stress-niveau. Det kunne også være oplysninger om vedkommendes position. Dette er udenfor Referencearkitekturens ansvar, da oplysningerne ikke registreres automatisk. Temperatur-sensor i lokale: En temperatursensor registrerer temperaturen i et lokale. Der registreres ikke informationer om et mobilt objekt, og eksemplet er derfor udenfor Referencearkitekturens ansvarsområde Geografisk afgrænsning Hovedfokus for Referencearkitekturen er de anvendelsesscenarier som foregår på og omkring hospitaler, men dækker dog også de mest centrale behov for sporing af personer og genstande uden for disse, eksempelvis ved transport mellem hospitaler og i patientens hjem. Side 18

19 3 Rammer og krav Referencearkitekturen forventes at indgå i en række kliniske arbejdsgange og patientaktiviteter. Disse arbejdsgange og aktiviteter er dokumenteret i form af ca. 40 brugsscenarier. Udover brugsscenarierne er en række ikke-funktionelle krav og forventninger identificeret, ligesom de lovmæssige rammer er beskrevet. Dette afsnit beskriver de rammer som Referencearkitekturen skal operere indenfor og de krav og forventninger, der er til Referencearkitekturen. Afsnittet fortæller hvad arkitekturen skal kunne, mens Afsnit 5 og frem beskriver hvordan dette realiseres. Det er målet at alle væsentlige krav og forventninger til Referencearkitekturen er beskrevet. For at sikre bredden i kravene har kvalitetsmodellen ISO 9126 været anvendt som inspirationskilde. ISO 9126 beskriver 33 forskellige aspekter af softwarekvalitet, eksempelvis sikkerhed, brugervenlighed og ressourceforbrug. De følgende afsnit beskriver de aspekter, der er relevante for Referencearkitekturen. Kravene i dette afsnit er generelle krav som forventes at være relevante på alle hospitaler og lignende organisationer. Krav som er specifikke for Region Midtjylland er beskrevet i Appendiks A. Alle krav er navngivet på formen [K:kravoverskrift]. De krav, hvor der er behov for det, har en begrundelse eller eksempler nedenunder selve kravet. Disse eksempler skal ikke betragtes som en udtømmende liste. Nogle krav har karakter af ønskværdige situationer som i praksis ikke vil kunne opfyldes 100%. Her er målet er at finde den rette balance mellem værdi og omkostning. 3.1 Funktionelle krav Her beskrives krav som relaterer til Referencearkitekturens overordnede funktion. Mere specifikke funktionelle krav fremgår af brugsscenarierne i næste afsnit. K:afkobling Referencearkitekturen skal afkoble systemer som anvender sporingsdata og systemer som producerer sporingsdata. Dette er det væsentligste formål med Referencearkitekturen; at undgå en fremtidig situation, hvor et antal anvendelsessystemer har implementeret egne integrationer til hvert sporingssystem Om brugsscenarier Med et brugsscenarie menes en anvendelsessituation som Referencearkitekturen med en vis sandsynlighed kan komme til at indgå i. Disse brugsscenarier skal bruges til at undersøge, hvorvidt Referencearkitekturen understøtter dem, og hvis ikke det er tilfældet, enten korrigere arkitekturen eller eksplicit Side 19

20 fravælge brugsscenariet. Desuden kan brugsscenarierne bruges i den efterfølgende proces omkring prioritering og implementering af sporingsprojekter. Brugsscenarierne er en blanding af konkrete scenarier, som for eksempel Cytostatikabehandling, og mere generelle scenarier, der dækker over en række konkrete scenarier med omtrent samme tekniske løsning, for eksempel Patienters tilkald af personale Vigtigste brugsscenarier I dette afsnit beskrives brugsscenarier som er vurderet som værende meget relevante at understøtte i Referencearkitekturen. Overskrift Situation Løsning med automatisk sporing/identifikation Adgangskontrol Cytostatikabebehandling Finde vej i bygninger med egen mobiltelefon Et område med begrænset adgang, f.eks. medicinrum eller lager ønskes sikret mod uvedkommende. Adgang foregår gennem en dør, port eller lignende. Cytostatika produceres til den enkelte patient. Det tager tid at producere og har ofte kun få timers holdbarhed. Behandlingsforløb for dagpatienter i cytostatikabehandling skal derfor koordineres nøje. Desuden er det afgørende at medikamentet ikke forsinkes i leverancen. En besøgende ønsker at finde frem til et bestemt sted eller finde frem til en bestemt person på hospitalet. F.eks.: - Pårørende der skal besøge patient. - Pårørende der skal finde cafeteriet og tilbage igen. Der placeres kortlæsere ved relevante døre. Personen identificeres på baggrund af dennes id-brik, og døren låses op. Dermed bliver det lettere at komme rundt i bygningen selv om der er en del låste døre man skal igennem. Desuden er det lettere at administrere digitale nøgler frem for fysiske nøgler. Når medikamentet er produceret påmonteres en id-brik som angiver dets position. Modtageren kan derfor følge med i leverancen, indkalde patienten på det rette tidspunkt og hurtigt agere hvis medikamentet ikke ankommer som forventet. Den besøgende installerer en app på sin telefon. Telefonen registreres over for systemet som herefter kan spore telefonen og give præcise individuelle vejledninger til hvordan man finder rundt. Finde vej i bygninger med udleveret tablet En patient eller personale ønsker at finde frem til et bestemt sted eller finde frem til en bestemt person på hospitalet. F.eks.: - Patient der skal finde cafeteriet og tilbage igen. - Patient der selv skal gå til røntgen og tilbage igen. - En ambulant patient skal til en undersøgelse. Personen låner en tablet eller smartphone der er sporet og som samtidigt kan give oplysninger omkring hvor man skal gå hen. Vejledningen kan løbende opdateres hvis der sker ændringer i planer el.lign. Side 20

21 Overskrift Situation Løsning med automatisk sporing/identifikation Identifikation af genstand Identifikation af patient ved stuegang Kontrol af sterile varer Kontrol over sengeflow på hele hospitalet Lokalisering af senge Lokalisering af udstyr En fysisk genstand skal identificeres overfor et it-system. F.eks.: - Finde ud af hvor udstyr hører til. - Finde ud af hvornår seng skal rengøres. - Finde beskrivelse af medikament. - Finde brugervejledning til apparat. Patienten skal identificeres ved stuegang, hvor EPJ skal vise den patient man er kommet frem til. Sterilcentral pakker og autoklaverer sterile genbehandlingsvarer. Derudover sker typisk en cross-docking med sterile engangsvarer. Varerne køres derefter til f.eks. OP hvor de pakkes ud og kontrolleres inden brug. Kontrol og servicering af hospitalet med senge under hensyntagen til pladsforbruget og det samlede behov for senge. Portører har til opgave at transportere senge med patienter eller tomme senge til central rengøring. Sengene, og relateret udstyr, skal derfor lokaliseres som en del af denne proces. Personalet skal finde noget udstyr. F.eks.: - EKG-apparat - Patientens seng. - Medicinbakke. - Rengøringsvogn Personalet skanner stregkode, RFID-tag eller lignende som overføres til systemet. Systemet slår genstanden op og viser den relevante information. Patienten udstyres med en stregkode, RFID brik eller Wi-Fi-brik. Personalet skanner stregkode, RFID-brik eller lignende direkte eller som følge af at være i samme rum som patienten. Informationen overføres til systemet (f.eks. EPJ) som slår personen op og viser den relevante information om patienten. Det er både tidsbesparende og en mere sikker måde at identificere patienten på. Sterile varer identificeres automatisk og det sikres derved at der er de rette elementer i den rette mængde. Dette sker ved at skanne varerne således at pakken verificeres af it-systemet. Denne kontrol kan foregå når varerne pakkes på procedurevogne, i forbindelse med ankomst til afdelingen, umiddelbart inden anvendelse af varerne og/eller ved returnering af varer. På sigt kan arbejdsgange i sterilcentral automatiseres (robot-pakker). Alle senge kan positionsbestemmes og deres status registreres automatisk eller manuelt. Et it-system viser fordelingen af senge efter geografi og status således at servicepersonale kan følge med i afdelingernes behov og koordinere arbejdet på en effektiv måde. Alle senge udstyres med Wi-Fi brikker som anvendes til positionering. Personalet angiver, at et emne er klar til afhentning, enten i et it-system eller direkte på emnet. Alle emner kan derefter lokaliseres på baggrund af deres udsendte positioner. Portøren kan se på en liste hvilke opgaver der skal løses i hans nærhed. Personalet slår emnetypen, eller det specifikke emne, op i et it-system som viser på et kort hvilke emner, der findes af den pågældende type i nærheden. Dermed spares tid på at gå rundt og lede og man forstyrre ikke andre med at spørge. Side 21

22 Overskrift Situation Løsning med automatisk sporing/identifikation Opfyldning af lokalt lager Overfaldsalarm Overvågning af udløbsdatoer Patienters tilkald af personale Personale-login En bestemt forbrugsvare skal løbende opfyldes. Personalet ønsker at vide, hvornår der skal fyldes op inden man løber helt tør. F.eks.: - Medicin - Blodprodukter - Sterilt udstyr - Sengetøj Personale der omgås patienter, som kan være voldelige, har brug for at kunne tilkalde hjælp. Der er flere formål: - Dem der bliver tilkaldt har brug for hurtigt at kunne se hvor de skal hjælpe. - Dem der er så langt væk at de ikke kan nå at hjælpe har interesse i ikke at blive tilkaldt. - Man kan have brug for at blive advaret om at nærmeste hjælp er meget langt væk inden man indleder en potentiel risikofyldt handling. Forbrugsvarer med begrænset holdbarhed skal løbende fjernes fra lageret og genbestilles. En patient ønsker hjælp fra personalet. Personale skal logge ind i itsystem, og evt. logge ud eller låse maskinen, når denne forlades. En id-brik på hver enkelt vare sender automatisk information om, hvilke varer der er tilbage. I praksis kan der være tale om at man mærker enkelte dyre eller kritiske varer eller at man mærker "kasser" af varer hvis der er tale om små varer. Et it-system giver en alarm, når der kun er et bestemt antal tilbage på det pågældende sted. Eventuelt kan beskeden om opfyldning sendes automatisk til den der skal fylde lageret op igen. En person vil på den måde kunne overvåge flere lagre fra en central arbejdsplads. Personalet bærer en sender på sig, der kan sende en alarm til systemet samtidigt med at senderen kan positionsbestemmes af systemet. Når varer modtages sættes en id-brik på og holdbarheden registreres. Dette kan evt. være gjort fra leverandørens side. Varerne opbevares herefter i et skab/rum der selv kan aflæse varens idbrik. Dermed registrerer skabet hvilke varer der sættes ind og tages ud samt hvilke varer der snart udløber. Man udtrækker periodisk en liste med varer der skal fjernes. Patienten trykker på knap på dennes armbånd. Alarmen indikeres overfor personalet sammen med patientens position. Det giver sikkerhed for at patienten altid kan kalde på hjælp selv om patienten ikke lige er i/ved sin seng. Brugeren kører kort igennem kortlæser, skanner RFID-tag eller lignende og logger derved ind uden at skulle indtaste noget. Når det detekteres at brugeren befinder sig et andet sted, kan denne blive logget ud igen. Side 22

23 Overskrift Situation Løsning med automatisk sporing/identifikation Positionering af andet personale Processer på operationsstuen Reducere spild pga. udløbsdato Skift batterier Sporing af patientforløb Personale skal finde en bestemt person. - En bestemt læge. - Den sygeplejerske der var inde hos en bestemt patient sidst. - Nærmeste ledige portør. - En læge på afdelingen. - For-/bagvagt. - En bestemt patient. På en operationsstue er der behov for optælling af varer og instrumenter før og efter operation. Desuden er der behov for at vide hvilke personer der befinder sig på stuen. En afdeling mangler en vare og skal derfor til at genbestille den, samtidigt med at en anden afdeling har samme vare på lager hvor den er ved at nærme sig udløbsdato og derfor snart skal kasseres. Batteridrevne enheder skal oplades/have skiftet batteri jævnligt. NB. Flere af scenarierne vedr. sporbarhed vil gøre dette endnu mere aktuelt. Når patienten gennemgår en behandling er der en del informationer vedr. patientens status og placering, der skrives i patients journal og/eller vises på bookingoversigtsskærme. Eksempelvis patientforløb fra sengeafsnit, perioperation, operation, perioperation og tilbage til sengeafsnit. Personalet slår personen op i database. Systemet viser på et kort, hvor personen er. Kortet opdateres løbende med den aktuelle position. Som en del at et samlet system der understøtter processerne på op-stuen mærkes alle indgående varer med RFID-brikker. En læser på op-stuen vil løbende kunne lave en oversigt over personale og ressourcer der er til stede. I forbindelse med genbestilling informeres bestilleren om at der er andre lagre i nærheden hvor varen med fordel kan hentes. Alternativt vil en central varekoordinator kunne opdage denne type situationer inden de sker og redistribuere varer med udløbsdatoer så der er størst mulig sandsynlighed for at varerne bruges inden udløb. Enhederne rapporterer løbende deres batteri-levetid sammen med deres position. Man kan derfor udtrække en oversigt over hvilke enheder der skal have skiftet batteri og hvor de befinder sig. Man kan udtrække lister over emner i nærheden af hinanden der snart skal have skiftet batteri, så man kan klare en hel stak på en gang og ikke skal gå alt for langt omkring for at gøre det. Det spores i hvilke rum patienten befinder sig. Tidspunkter for hvornår patienten skifter rum kombineret til de enkelte rums anvendelse kan bruges til opdatering af journalen. Hvorvidt dette skal ske fuldautomatisk baseret på patients position eller patientens position blot skal vises, eksempelvis på storskærm, er uafklaret. Informationen anvendes også til nemt at finde patienten (eksempelvis portører). Side 23

24 Overskrift Situation Løsning med automatisk sporing/identifikation Søgning efter varer i andre afdelinger Tyverisikring af inventar Uddeling af medicin Udstyr signaleres klar til afhentning En vare er midlertidigt opbrugt på eget lager og man skal derfor skaffe en tilsvarende vare fra en anden afdeling. Der er store mængder inventar og dyrt udstyr på afdelingerne f.eks. PC'er og måleudstyr. Samtidigt er der er relativt fri afgang fra gaden, så der er en reel risiko for tyveri. Dagsdosis af medicin til en patient pakkes af en medicinrobot. Ved uddeling skannes stregkoder på medicin og patient, og det verificeres i EPJ at den aktuelle medicin er korrekt ordineret til den pågældende patient. Det er ret svært at scanne medicinen idet hver lille pose skal vende rigtigt ift. stregkodelæseren. Noget udstyr skal afhentes af en portør. Det kan være: - en seng til rengøring - en patient i en seng - en madvogn - varer der skal flyttes Når varer modtages placeres en id-brik på dem, hvis ikke det allerede er gjort af producenten. Varerne opbevares herefter i et skab/rum der selv kan aflæse varen. Dermed holder skabet styr på hvilke varer der findes samt hvilke varer der snart udløber. Hvis man ikke selv har varen kan systemet fortælle hvilke nærtliggende afdelinger der har varen. Man har adgang til alle lagre uden at skulle ringe og forstyrre nogen. Der placeres sensorer ved centrale steder som f.eks. Gange mellem afdelinger, receptioner og udgange. Hvis udstyret registreres i disse rum udløses en alarm. Der skal være nogen der tager sig af sådanne alarmer. Poserne mærkes med RFID-brikker i stedet for stregkoder og skannes uden at man behøver at stå og vende og dreje hver enkelt pose. Dermed sparer personalet tid. Personalet aktiverer en "alarm" på den id-brik der sidder på udstyret. Alarmen betyder at udstyret er klar til afhentning. Alternativt kan påhæftes en bestemt radiosender som angiver at emnet er klar til indsamling. Portørerne kan se i deres it-system hvad det er der skal hentes og hvor det befinder sig. Side 24

25 Overskrift Situation Løsning med automatisk sporing/identifikation Vejledning af patienter Tabel 1: Vigtigste brugsscenarier. Patienter skal guides hurtigt igennem behandlingsforløb. Eksempelvis ambulatoriepatienter Andre relevante brugsscenarier Det spores i hvilke rum patienten befinder sig. Patienten bevæger sig rundt med en digital enhed, eksempelvis patientens egen smartphone eller en udleveret tablet. Patienter modtager besked om indkaldelse, herunder hvor de skal ankomme (og måske parkere). Deres ankomst registreres og deres overordnede bevægelser spores, således at de kan guides til prøvemodtagelse, tilbage til venteområde, ambulatorium, billeddiagnostik, fysioterapi og lignende. Da patientens position kendes, kan der gives mere målrettet information, eksempelvis om hvor lang tid det tager at bevæge sig hen til det rette sted. Patienten modtager information om forventede ventetider. I dette afsnit beskrives brugsscenarier som er vurderet som værende relevante at understøtte, men i mindre grad eller på længere sigt end scenarierne ovenfor. Overskrift Situation Løsning med automatisk sporing/identifikation Advisere modtagere af rørpost Demente patienter forlader afdelingen Følsomme varer med rørpost Notifikation om forkert opbevaring Man vil gerne have en præcis besked til modtageren af rørpost om, at der er kommet noget til vedkommende. Patienter, der ikke er i stand til at tage vare på sig selv, skal overvåges for at sikre, at de ikke forlader afdelingen. Det kan f.eks. være demente eller børn. Personalet har til opgave at sørge for, at dette ikke sker. Følsomme varer skal sendes langsomt gennem rørposten og/eller prioriteres højt ved rutning. Et bestemt emne (udstyr, medicin, fødevarer eller lignende f.eks. en madvogn) skal opbevares eller behandles på en bestemt måde. Sker dette ikke ødelægges emnet. Hvis den vare der transporteres er mærket med RFID kan der sendes en besked til bestemte personer om at varen er ankommet. Personen udstyres med en id-brik som gør, at man kan detektere hvis de befinder sig på bestemte steder (udgange, medicinrummet osv.) Et it-system giver en alarm, hvis personen befinder sig et forkert sted, f.eks. via personalets mobiltelefon. Rørpostsystemet kan selv genkende følsomme varer ud fra deres ID som aflæses ved afsendelse. Systemet tilpasser hastigheden og forsendelsesstrategien. Sensorer på selve emnet sender besked om miljøet (f.eks. temperatur, fugt, placering, tidsrum). Et it-system giver en alarm, hvis de definerede kriterier ikke er opfyldt. Det bliver også muligt at lave kvalitetsmål på behandlingen af denne type varer. Side 25

26 Overskrift Situation Løsning med automatisk sporing/identifikation Optimering af arbejdsgange Personale-login med valg Efter login kan systemet selv se hvor brugeren befinder sig og vælge en passende standard for afdelingsvalg. Brugeren skal derfor normalt ikke vælge afdeling. Procesdokumentation rengøring Prøvetagningsrunde Sporing af blodpræparater Sporing af rørpostpatroner Sporing af varer i rørpost I forbindelse med optimering af arbejdsgange, ønskes viden om, hvordan personer eller udstyr bevæger sig. Dette bruges efterfølgende til at ændre opgavefordeling, rækkefølge, placering af lokaler/udstyr/patienter osv. så arbejdet lettes. F.eks.: - Optimering af arbejdsgange omkring operationsstuen. - Optimering af arbejdsgange omkring transport af senge. - Optimering af logistikprocesser. Personale skal vælge afdeling som en del af login. Nogle personalegrupper, især læger, har mange afdelinger af vælge imellem. Rengøringspersonale har behov for hjælp til at huske hvor de har været og hvor de mangler at komme. Resultatet kommunikeres løbende til andre, der venter på rengøring. Der skal tages blodprøver på en række patienter på et givet tidspunkt. Der er en række positionerings- og identifikationsopgaver i dette: - Personalet skal finde den korteste rute der bringer dem forbi alle de berørte patienter. - Man skal være sikker på hvor patienterne er - Man skal være sikker på at det er den rigtige patient der stikkes i. Der er manglende overblik over udleveret blod. Man vil gerne vide hvor rørpostpatronerne er for at kunne følge deres bevægelser og håndtere logistikken i at få tomme patroner tilbage. De scenarier hvor varer spores, når de flyttes mellem afdelinger bør virke uanset om varen sendes med portør eller rørpost. Personernes eller genstandenes faktiske bevægelser præsenteres på et kort. Personale vurderer arbejdsprocesserne baseret på det observerede bevægelsesmønster. Data om personer kan evt. anonymiseres. Når et sted er besøgt skannes en id-brik på stedet, f.eks. stregkode eller RFID. Dette opsamles og kan ses i et it-system, f.eks. på en liste eller et kort. Systemet kan planlægge en runde baseret på hvor patienterne skulle være (ifølge EPJ) og faktisk er (ifølge indendørs positionering). Hvis patienten ikke er på sin plads kan man se hvor patienten faktisk er. Patientens identitet kan sikres enten ved at personale og patient har samme position eller ved at personalet scanner patienten med RFID eller Stregkode læser. Med RFID er dette enkelt. Blodposer påføres en id-brik således at de kan følges og nemt kontrolleres igennem hele processen. Alle rørpostpatroner mærkes med eksempelvis RFID og der opstilles læsere en række steder. Herved opnås centralt overblik over hvor mange patroner der er i transit, hvor de er og hvor mange tomme patroner der er i de forskellige modtagestationer eller andre steder. Emner der i forvejen er mærket med RFID kan spores under transporten i rørpostsystemet. Der placeres læsere omkring rørpostsystemet ved alle indgange, udgange og fordelingscentraler. Eksisterende systemer anvendes til at følge emnernes bevægelser. Side 26

27 Overskrift Situation Løsning med automatisk sporing/identifikation Tyverisikring af hjælpemidler Sensorer ved udgange registrerer hjælpemidler der passerer. Hvis hjælpemidlet ikke er registreret som udlånt udløses en alarm. Dermed sikres at der er foretaget en registrering af brugeren og svind reduceres. Udlån/returnering Patienter skal have en del udstyr med ud af sygehuset, f.eks. kørestole. Der er et stort svind i den slags udstyr. Patienter skal have en del udstyr med ud af sygehuset. Det skal registreres hvem der låner hvad, og det skal registreres, når det modtages retur. Tabel 2: Andre relevante brugsscenarier. Sensorer ved hjælpemiddel udlevering og indlevering registrer enheder der passerer. Især returnering vil kunne laves med meget lidt personale. 3.2 Lovgivning og regler Mange relevante scenarier indeholder registrering af personlige data for patienter og/eller personale. De er derfor omfattet af persondatalovens [Persondataloven] regler for behandling af personoplysninger. Alene det at man registrerer identiteten af personen er nok til at være omfattet af loven. Det er den dataansvarlige der, for hver enkelt anvendelse, har ansvaret for at anvendelsen er i overensstemmelse med loven. Man kan altså ikke købe et it-system, der er godkendt til at overholde persondataloven eller basere sig på en arkitektur, der i sig selv sikrer at loven overholdes. Det er anvendelsen af systemet der skal vurderes, ikke systemet i sig selv. I forbindelse med gennemførelse af projekter, der vedrører personoplysninger, skal man være opmærksom på at: Formålet skal være sagligt og proportionelt. Proportionelt betyder at man skal vælge den mindst indgribende løsning, der opfylder formålet. Man må f.eks. ikke spore alle personalegrupper hvis man kun har brug for at spore portører. Man har pligt til at oplyse den registrerede om, at der indsamles oplysninger, hvilke oplysninger der er tale om, og hvad de bruges til. For personale kan det være enkelt, men for anvendelser der berører patienter og/eller pårørende kan det være mere kompliceret at gennemføre. Den registrerede skal samtykke. For personale kan det være enkelt, men for anvendelser der berører patienter og/eller pårørende kan det være mere kompliceret at gennemføre. Den registrerede skal kunne få indsigt i det registrerede. Den registrerede har krav på at kunne få fejlagtige personlige data rettet/slettet. Der er særlige regler, hvis der er video overvågning involveret, ikke mindst fortolkning af, hvad samtykke betyder. Der kan være anmeldelsespligt for behandlinger af oplysninger, hvis der behandles fortrolige informationer i systemet. I de fleste situationer vil dette ikke være tilfæl- Side 27

28 det for sporbarhedsanvendelser, men man bør vurdere hver situation individuelt, da sygdom generelt er en følsom personoplysning. 3.3 Interoperabilitet Her beskrives krav til digital kommunikation med andre organisationer. K:spor-ud Det skal være muligt at afsende information om id-brikkers bevægelser til eksterne parter. Varers bevægelse og status på hospitalet kan være relevant for leverandøren, eksempelvis for at leverandøren kan modtage information om at en vare er modtaget eller opbrugt. K:spor-ind Det skal være muligt at modtage information fra eksterne parter om id-brikkers bevægelser. Varevognes bevægelser hos eksterne parter vil sandsynligvis være relevant information, eksempelvis til at følge status eller forudsige ankomst. K:metadata-ud Det skal være muligt at sende information til eksterne parter om objekter som hospitalet har påhæftet id-brikker. Hvis blodprodukter opmærkes med id-brikker af hospitalet og sendes til eksterne parter, vil disse sandsynligvis have behov for information om det pågældende blodprodukt udover hvad id-brikken kan viderebringe. Varevogne som cirkulerer mellem hospitalet og eksterne service-leverandører vil sandsynligvis blive udstyret med id-brikker. Serviceleverandøren kan have behov for at aflæse disse brikker og identificere det aflæste id som værende en bestemt vogn. K:metadata-ind Det skal være muligt at modtage information om objekter, som er påhæftet idbrikker af eksterne parter. Når varer, som er mærket med stregkoder eller RFID-brikker, modtages, er der behov for en oversættelse fra disse id er til en beskrivelse af varen. Hvis eksempelvis hospitalet modtager et præparat skal det være muligt at oversætte fra stregkoden til præparatets navn, leverandør, osv. 3.4 Eksisterende systemer Her beskrives krav der relaterer sig til de systemer som allerede findes i organisationen. Side 28

29 K:id-systemer Eksisterende systemer som indeholder identiteten på personer og ting skal genbruges. Det vil sige at disse systemer stadig skal være den primære kilde til identificering af de pågældende objekter. Det drejer sig eksempelvis om EPJ som opbevarer identitet på patienter, medicin og lignende, tekniske databaser som opbevarer identitet på udstyr og brugerregistre som opbevarer identitet på personale. K:bygningsdata Informationer om lokationer som er relevante for sporing, skal være tilgængelige fra en central database, som alle involverede it-systemer kan trække på. Enighed om steders identitet, geografiske placering og betydning er centralt for at informationerne fra et sporingssystem kan tolkes korrekt. 3.5 Sikkerhed Her beskrives krav der relaterer sig til beskyttelse af informationer mod adgang fra uvedkommende personer og systemer. Sikkerhedskrav er et eksempel på krav som sjældent kan opfyldes fuldstændigt, og i stedet skal betragtes som målsætninger. K:uautoriseret-dataadgang Data om identificerbare objekter, personer eller grupper af disse må kun være tilgængelige for dertil autoriserede brugere. Personnummer kan misbruges og skal beskyttes mod at falde i uvedkommendes hænder. Måledata fra sensorer på patienter kan indeholde oplysninger som ikke må ikke ses af uvedkommende. Information om personers bevægelser må ikke ses af uvedkommende. Placeringen af medicin må ikke ses af uvedkommende. K:uautoriseret-tilslutning Det må ikke være muligt for uautoriserede personer at sende falske data ind i systemet. Det er afgørende for anvendelsen af og tilliden til systemet, at det rapporterede data er troværdigt, ikke mindst fordi en række sikkerhedssystemer kan være baseret på dette. For eksempel må det ikke være muligt at simulere id-brikker for personale ved elektronisk at aflytte kommunikationen mellem brik og læser. Det må heller ikke være muligt at afsende falske sensordata fra en patient, der er forsynet med en brik, som sender måledata til systemet. K:uautoriseret-funktionsstop Det må ikke være muligt for uautoriserede personer at forhindre at systemet fungerer. En person kommer til at lukke ned for systemet ved en fejl. En ondsindet person afbryder systemet. Side 29

30 En ondsindet person overbelaster systemet (denial-of-service attack). K:auditering Det skal være muligt at monitorere hvor data kommer fra og hvem der anvender data. Det skal være muligt at se, hvilke systemer der sender hvilke data ind i systemet, således at eventuelle fejl kan opdages. Det skal være muligt at se, hvilke typer data et anvendelsessystem benytter, således at der kan reageres, hvis data ikke var tiltænkt det pågældende system. 3.6 Oppetid Her beskrives krav der relaterer sig til stabiliteten af den løsning der baseret på Referencearkitekturen. Automatisk opsamling af data vil komme til at indgå i mange kritiske arbejdsprocesser på hospitalet. Det er derfor meget vigtigt at systemet har en høj tilgængelighed. K:oppetid Den centrale del af sporingsinfrastrukturen, som alle andre dele er afhængige af, skal have en oppetid svarende til de øvrige centrale systemer, eksempelvis EPJ. De konkrete oppetidskrav vil afhænge af de konkrete projekter som anvender infrastrukturen og vil således ændres over tid. K:tilkobling Nye sporingsrelaterede systemer skal kunne tilkobles uden nedetid for hele systemet. Tilkobling af en ny infrastruktur til opsamling af hændelser. Tilkobling af et nyt anvendelsessystem, der skal trække på data. K:leveringsgaranti Hændelser kan opdeles i to typer: med og uden leveringsgaranti. For hændelser med leveringsgaranti må en hændelse ikke kunne gå tabt fra den modtages af en hardwareenhed til den er overleveret til alle interesserede anvendelsessystemer, med mindre der er tale om en eksplicit filtrering. Hændelser uden leveringsgaranti leveres i det omfang det er muligt i den aktuelle situation (efter best-effort-princippet). Et signal som udsendes én gang og fremkalder et statusskifte i et it-system må ikke gå tabt. Eksempelvis alarmering når en id-brik passerer en bestemt læser. Hvis emner løbende positioneres, og systemet er nede eller hårdt belastet, må det ikke skabe en kø af forældede hændelser som ikke har nogen værdi. Eksempelvis rulleborde der udsender position hvert 5 minut. Side 30

31 3.7 Svartider Her beskrives krav der relaterer sig til svartider. Krav til skaleringsevne afhænger af den konkrete, forventede anvendelse af sporing og er beskrevet i Appendiks A. K:forsinkelse Hændelser kan opdeles i to typer: tidskritiske og ikke-tidskritiske. For tidskritiske hændelser må der gå op til 1 sekund (99%-fraktil) fra hændelsen registreres af hardware til den videresendes til de relevante brugsapplikationer. For ikke-tidskritiske hændelser er det acceptabelt med forsinkelser op til 30 sekunder (99%-fraktil). Eksempel på de to typer af hændelser: Hvis systemet bruges til at kontrollere indholdet af varer på en procedurevogn eller at den korrekte medicin udleveres til den korrekte patient, skal svaret komme umiddelbart efter at brugeren har skannet emnerne. Hvis ankomsten af varer til hospitalet registreres automatisk er det acceptabelt med en lidt længere forsinkelse. 3.8 Drift Her beskrives krav der relaterer sig til driften af systemet. K:monitorering Systemet skal tilbyde mulighed for at følge med i aktuelt dataflow og performance, samt at analysere disse over en periode. Oppetid, svartider og sikkerhed af et it-system afhænger i høj grad af muligheden for at overvåge systemet og reagere så tidligt som muligt, hvis noget ser forkert ud. K:fejlsituationer Systemet skal notificere ved fejlsituationer og tilbyde mulighed for diagnosticering. Eksempelvis ved at logge informationer, som gør det muligt at finde ud af hvad fejlen skyldes. K:centralt-vedligehold Det skal være muligt at vedligeholde tværgående koncepter som steder, identitet og hændelsestyper fra centralt hold. Når et lokale skifter navn skal det være muligt at ændre dette et begrænset antal steder, og ikke i alle systemer der beskæftiger sig med sporbarhed. 3.9 Snitflader Her beskrives krav der relaterer sig til de snitflader, som Referencearkitekturen definerer. Det drejer sig hovedsageligt om snitflader til at sende hændelser ind i systemet, at få hændelser ud af systemet og at tilgå andre systemer med eksempelvis geografiske data og id er på personer og udstyr. Side 31

32 K:snitflader Koblinger til alle systemer skal ske gennem veldefinerede snitflader, således at systemerne kan udskiftes, hvis behovet opstår. Eksempler: Systemer der leverer hændelser ind i systemet. Systemer med geografisk information. Systemer som oversætter mellem forskellige id er. K:parallelle-snitflader Systemet skal muliggøre at flere versioner af snitflader er i drift samtidigt, således at snitflader kan opgraderes uden at flytte alle systemer over på den nye snitflade samtidigt. Hvorvidt understøttelse af flere versioner af snitflader i forbindelse med opgradering er en god ide, afgøres i de enkelte tilfælde. Men det skal være teknisk muligt at versionere snitflader. Side 32

33 4 Sporingsteknologier Der findes en lang række teknologier til sporing og identifikation, dvs. teknologier som registrerer et objekts identitet på et givent sted og tidspunkt. Teknologierne adskiller sig ved deres pris, kommunikationsmedier (radio/lyd/lys), rækkevidde, standarder, afhængighed af strømkilder, mulighed for dataopsamling, osv. Referencearkitekturen skal opfylde en række brugsmæssige behov, som beskrevet i det foregående afsnit, ved anvendelse af en række teknologier til sporing og identifikation. Dette afsnit giver et overblik over de teknologier, som Referencearkitekturen skal kunne integrere, samt de tekniske standarder, der findes til at styre og ensarte anvendelsen af disse teknologier. Teknologibeskrivelsen kan også benyttes som en generel introduktion til de teknologiske muligheder i forbindelse med den fremadrettede proces. Afsnittets fokus er på de muligheder teknologierne tilbyder, samt eventuelle særlige udfordringer, som skal håndteres af arkitekturen. 4.1 Typer af sporingsteknologier Der findes flere typer af teknologier der hører indenfor rammerne af Referencearkitekturen, som defineret i afsnittet Afgrænsning: Automatic Identification and Data Capture (AIDC): Fokus for AIDC-systemer er automatisk identificering af objekter og registrering af oplysninger om disse. Dette dækker over teknologier som stregkoder, RFID, billedgenkendelse, biometri og talegenkendelse. Real-Time Locating System (RTLS): Fællesnævneren for denne type af systemer er sporing af objekters geografiske placering hvortil teknologier som f.eks. GPS og Wi-Fi kan anvendes. Wireless Sensor Network (WSN): WSN dækker over måleapparater som kan udveksle de målte data med hinanden via trådløse teknologier og lede disse data til centrale opsamlingspunkter. Der er en række forskelle på disse typer, som vil fremgå af det følgende. Fælles for dem er at der sker en registrering af identitet, tidspunkt og fysiske position. Opsamling af positionen kan være det primære formål, som med GPS, eller en sekundær og ofte mere upræcis positionsbestemmelse, som med aflæsning af en stregkode. Teknologierne kommer normalt som en del af en samlet løsning bestående af både hardware og software. Disse løsninger findes i en lang række varianter. I den ene ende af skalaen er der de simple løsninger, som består af nogle få hardwareenheder og de softwaredrivere der skal til for at kommunikere med hardwaren. Det er for eksempel stregkodelæsere, der kan kobles til en PC og bruges til at opsamle data på samme måde som et tastatur. Side 33

34 I den anden ende af skalaen findes de løsninger som dækker over et større antal hardwareenheder og et mere avanceret brugsmønster. En sådan løsning består ofte af følgende elementer: En elektronisk enhed som bæres af den person eller ting som skal identificeres. Disse kaldes ofte for mærkater, tags eller brikker. Id-brik benyttes som generel betegnelse i det følgende. En sensor, skanner, radiomodtager eller lignende som registrerer id-brikkerne. Disse betegnes læsere i det følgende. Software som registrerer og behandler læsernes aflæsninger af id-brikker. Denne software falder oftest indenfor disse kategorier: Edgeware, som har til formål at fejlkorrigere, filtrere og aggregere registreringer. Navnet henviser til at dette oftest foregår tæt på læserne for at undgå unødig kommunikation fra disse til de centrale systemer. Middleware, som har til opgave at opsamle, berige og videreformidle registreringer i form af hændelser på et højere abstraktionsniveau. Her kan også ske en oversættelse fra id-brikkernes identitet til de fysiske objekters eller personers identitet. Middleware er ofte et centraliseret system, men kan også være et decentralt, distribueret system sammenbygget med edgeware. Slutbrugerapplikationer, som anvendes til at udstille og bearbejde de hændelser som kommer fra middleware. Det kan være generelle applikationer til mange forskellige formål, f.eks. et kort der viser id-brikkers positioner, eller meget konkrete applikationer målrettet mod specifikke anvendelser i en konkret installation, f.eks. registrering af varebeholdning i et køleskab. Administrationsværktøjer, som anvendes til at konfigurere, overvåge og diagnosticere løsningen. Et centralt element er tildelingen af id er til de enkelte id-brikker og vedligehold af geografiske data. Der indgår også ofte værktøjer til konfiguration af den fysiske kommunikation mellem læsere og id-brikker, eksempelvis valg af frekvensområde. Dataudveksling med andre organisationer, som gør det muligt at fortolke de id er og andre data som aflæses fra id-brikkerne. 4.2 Konkrete teknologier Tabel 3 viser en oversigt over teknologier til identifikation og positionsbestemmelse. En mere udførlig beskrivelse kan findes i Appendiks B. Side 34

35 Teknologi Type Præcision af positionsbestemmelse Stregkoder AIDC Læsers placering + få meter Passiv RFID AIDC Læsers placering + fra få centimeter til flere hundrede meter Aktiv RFID AIDC Læsers placering + fra få centimeter til flere hundrede meter Wi-Fi RTLS Afhænger af antal synlige antenner og omfanget af kalibrering. Bedste præcision er få meter. Fordele Id-brikker og læsere er billige. Meget udbredt og moden teknologi. Intet batteri der skal skiftes. Id-brikker og læsere er billige. Intet batteri der skal skiftes. Kan kombineres med sensor. Mange id-brikker kan læses ad gangen. Kan kombineres med sensorer. Batterilevetid fra få måneder til flere år. Kan lagre informationer i begrænset mængde. Bruger eksisterende Wi-Fi-infrastruktur og denne kan benyttes til andre formål. Udover Wi-Fi-brikker kan Wi-Fi-enheder som mobiltelefoner og PC er også positioneres. Giver mulighed for tale og dataudveksling. Kan kombineres med sensor eller enhed til kommunikation. Ulemper Kræver infrastruktur til læsere. Kræver at stregkoden er synlig fra læseren. Kræver normalt en person til at betjene læseren. Kræver infrastruktur til læsere. Ved kortrækkende RFID kræves normalt en person til at betjene læseren. Kræver infrastruktur til læsere. Batteri skal skiftes/oplades. Pris på id-brikker. Ikke alle infrastrukturinstallationer er velegnede. Høj præcision kræver kalibrering i de fleste lokaler. Påvirkes af ændringer i miljøet. Relativ kort batterilevetid (uger til måneder). Pris på id-brikker. Side 35

36 Teknologi Type Præcision af positionsbestemmelse Fordele Ulemper UWB RTLS < 1 m Robust overfor signalforstyrrelser. Begrænset forstyrrelse af andre systemer. Kræver infrastruktur til læsere. Pris på id-brikker. Lavt batteriforbrug (flere år med få sekunders opdatering). GPS RTLS 1-10 m Kræver ikke opstilling af infrastruktur. Kun udendørs. Sensornetværk WSN Afhænger af antal synlige antenner/idbrikker. Bedste præcision er få meter. Kræver ikke kalibrering vha. footprints. Kan kombineres med sensor eller enhed til kommunikation. Kræver infrastruktur med stort antal læsere/routere. Batterilevetid på måneder til år. DECT RTLS Afhænger af antal synlige antenner og omfanget af kalibrering. Bedste præcision er få meter. Giver mulighed for tale og dataudveksling. Bedre batterilevetid end Wi-Fi pga. lavere sendestyrke. Kræver separat infrastruktur med modtagere/repeatere. GSM RTLS 200 m 15 km (DK) Tilgængelig globalt. Præcis positionering er ikke tilgængelig i Danmark. Bluetooth AIDC Læsers placering + få meter. Indenfor et rum. Bredt understøttet i mange forskellige typer af enheder. Overførsel af data op til 1 Mbit. Højere strømforbrug end f.eks. ZigBee. Infrarød AIDC/ RTLS <1 mm til få meter Ingen interferens med andet udstyr. Batterilevetid op til flere år. Kræver infrastruktur til læsere. Kræver ublokeret synslinje på maks. 6-7 meter mellem id-brik og læser. Påvirkes af stærkt lys. Side 36

37 Teknologi Type Præcision af positionsbestemmelse Fordele Ulemper Ultralyd AIDC/ RTLS Fra få centimeter til rumniveau. Kræver ikke ublokeret synslinje. Batterilevetid op til flere år. Kræver infrastruktur til læsere. Påvirkes af visse støjfyldte miljøer. Billedanalyse AIDC/ RTLS Få centimeter. Kan identificere og positionsbestemme personer uden at disse bærer id-brikker. Kan registrere kroppens bevægelser. Teknologi ikke moden til anvendelse i missionskritiske miljøer. Kræver ublokeret synslinje. Særlige regler for overvågning er gældende. Biometri AIDC Læsers placering + få meter Kan identificere personer uden at disse bærer id-brikker. Der kan være modstand mod registrering af biometriske data. Bevægelsesfølere RTLS Meget upræcist hvis anvendt alene. Ikke afhængig af udefrakommende signaler eller infrastruktur. Kan anvendes til at korrigere andre typer positionsbestemmelse. Anvendt alene vil positioneringsusikkerheden øges med den afstand man har bevæget sig. Stemmegenkendelse AIDC Som mikrofonens placering. Kan identificere personer uden at disse bærer id-brikker. Mangel på kommercielle produkter. Kan identificere personer via telefonen. Tabel 3: Oversigt over teknologier til automatisk identifikation og positionsbestemmelse. Generelle kilder: [Liu et al., 2009], [awarepoint-wifi, 2009], [Fredslund et al., 2010], [Khaji et al. 2008], [stg-comp, 2011]. Desuden wikipedia.org. Kilder til information om enkelte teknologier er beskrevet i Appendiks B. 4.3 Standardiseringsområder De standarder der har relevans for Referencearkitekturen kan opdeles i følgende kategorier: Udveksling af baggrundsdata om de objekter der spores. Aflæsning af data, for eksempel mellem id-brik og læser. Side 37

38 Administration Proces Hændelser/data Aflæsning Baggrundsdata Forretningshændelser og -data, for eksempel at en leverance er udført i henhold til et bestemt ordrenummer. Proces, for eksempel hvordan den samlede proces for sporing af varer bør tilrettelægges og koordineres. Teknisk administration af løsningen. I Tabel 4 opsummeres de standarder som er beskrevet i detaljer i det følgende. Standard Fokus EPCGlobal RFID X X X X X GS1 standards RFID, stregkoder X X X X HIBCC RFID, stregkoder X X X ISO/IEC ID-kort, passiv RFID X ISO/IEC ID-kort, passiv RFID X ISO/IEC RFID X ISO/IEC RTLS X X ECMA 340/352 RFID X ZigBee Mesh-netværk X X Dash7 Mesh-netværk X Tabel 4: De vigtigste standarder relateret til automatisk identifikation og positionsbestemmelse. Kilder: Websites for de respektive standarder, samt wikipedia.org. De vigtigste af disse standarder er beskrevet yderligere i Appendiks B. Side 38

39 5 Arkitekturprincipper Referencearkitekturen afkobler anvendelsessystemer og sporingssystemer ved at indskyde et integrationssystem imellem disse. Dette integrationssystem baseres på EPCIS-standarden fra EPCGlobal. Desuden anbefales det at nedsætte en permanent styregruppe, som har til opgave at sikre at Referencearkitekturen overholdes og videreudvikles på en hensigtsmæssig måde efterhånden som nye sporbarhedsprojekter kommer til. I dette afsnit præsenteres Referencearkitekturens vigtigste principper og valg, herunder argumenterne for disse valg. I det efterfølgende afsnit, Afsnit 6 Arkitekturbeskrivelse, beskrives hvorledes disse valg udmønter sig i en mere konkret teknisk løsning. Dette afsnit er således primært argumenterende og indeholder de centrale af Referencearkitekturens valg, mens Afsnit 6 er mere beskrivende og indeholder supplerende og mere detaljerede valg, som i højere grad kan fraviges, hvis situationen tilsiger det. Validering af Referencearkitekturen op imod de krav, brugsscenarier, målsætninger mv. som er opstillet ovenfor er samlet i Appendiks D. 5.1 En lagdelt arkitektur Den samlede arkitektur for sporbarhed og emneidentifikation kan opdeles i 5 lag som illustreret på Figur 2. Side 39

40 Lag 5: Anvendelsessystemer Anvendelse af sporingsdata Lag 4: Integrationssystem til Sporing og Identifikation Opsamling, berigelse og formidling af relevante sporingsdata Lag 3: Sporingssystemer Filtrering og udstilling af sporingsdata Lag 2: Læsere Fysisk registrering af bevægelser og hændelser Lag 1: Mobile objekter Fysiske objekter med id-brikker eller sensorer Figur 2: Referencearkitekturen er en lagdelt arkitektur, hvor det primære dataflow går nedefra og op. På nederste lag findes personer, mobilt inventar, varer osv. som typisk er udstyret med id-brikker. Disse objekter spores på Lag 2 af en række hardwareenheder af forskellige typer, typisk via trådløs kommunikation. De aflæste id er, positioner og andre data renses for fejl, duplikater og lignende på Lag 3. Dette sker ofte decentralt af den software der styrer læserne, men det kan også ske centralt i forbindelse med overlevering af data til Lag 4. På Lag 4 har Integrationssystem til Sporing og Identifikation, herefter kaldet Integrationssystemet, ansvar for at opsamle, berige og videreformidle de relevante data til Lag 5, hvor anvendelsessystemer typisk præsenterer data for slutbrugere, samhandelspartnere eller lignende. I det følgende beskrives en række principielle valg, som tilsammen former Referencearkitekturen. 5.2 Generelle principper Her beskrives en række valg af tværgående, generel karakter. Side 40

41 5.2.1 Styregruppe med ansvar for overholdelse af arkitekturen Hvis et større it-system skal forblive sundt på lang sigt, er det nødvendigt at indføre et sæt fælles spilleregler, der vægter højere end kortsigtede interesser. Forudsætningen for at Referencearkitekturen kan nå sine mål, er således at alle relevante interessenter er opmærksomme på Referencearkitekturen og overholder den. Nogle aspekter af arkitekturen er dynamiske og kræver tilpasning efterhånden som nye sporingsprojekter kommer til eller behovene ændrer sig. Det gælder eksempelvis fortolkningen af nye typer af sporingshændelser, som kræver tæt dialog mellem teknisk og klinisk personale. Der er således behov for, at en gruppe af personer med indsigt i Referencearkitekturen, dens underliggende teknologier og praktiske anvendelser kontrollerer arkitekturens overholdelse, samt koordinerer fremtidige tilpasninger. P:styregruppe Der findes en styregruppe, som har ansvar for at Referencearkitekturen overholdes og tilpasses. Denne styregruppe betegnes i det følgende som Styregruppen. Et oplæg til konkrete ansvarsområder er beskrevet i Appendiks C Separation af dataopsamling og anvendelsessystemer Et af de centrale krav til Referencearkitekturen er at der sker en afkobling af anvendelsessystemer og sporingssystemer, jfr. [K:afkobling], således at afhængighed mellem de enkelte systemer kan undgås eller mindskes. Dette sker ved at indskyde et integrationssystem som et afkoblende lag imellem disse. En modsatrettet interesse er behovet for nemt og hurtigt at kunne tilkoble et simpelt system til automatisk dataregistrering, eksempelvis tilslutte en stregkodelæser til en PC for på den måde at undgå triviel indtastning af data. Ligeledes bør det være tilladt for anvendelsessystemer at trække direkte på data fra andre organisationer, også selvom det er sporingsdata. Hvis flere systemer bruger de samme udefrakommende data, er det en god ide at udstille disse som en samlet service. Dette kan eventuelt ske ved at integrere disse data i Integrationssystemet. P:indirekte-adgang Alle anvendelsessystemer tilgår alene sporingsdata via Integrationssystemet. Dette gælder dog ikke nødvendigvis udefrakommende sporingsdata eller simple sporingssystemer, hvor data kun er anvendelige i én bestemt sammenhæng. Styregruppen skal altid inddrages i beslutningen Minimal løsning som kan udvides Et centralt spørgsmål ved etablering af it-systemer er, i hvor høj grad det fremtidige system skal skabes på en gang eller ved gradvis udvikling. I det ene ekstrem forsøger man at forudsige alle fremtidige behov og udvikle hele it-systemet på en gang, med risiko for unødig kompleksitet. I det andet ekstrem udvikler man kun den del af systemet som der aktuelt er behov for, hvilket kræver løbende justering af designet. Side 41

42 Referencearkitekturen er en balance mellem disse to yderpunkter: De overordnede rammer er designet og valideret i forhold til alle identificerede scenarier og typer af teknologier. Samtidigt inddrages kun de konkrete funktionaliteter og data, som der aktuelt er et sikkert behov for. Yderligere funktionalitet og data vil kunne tilføjes senere hvis behovet opstår. P:dynamisk Referencearkitekturen afstikker nogle overordnede rammer, mens detaljerne skal udvikles efterhånden som behovene opstår. Dette princip har bl.a. den konsekvens at visse funktionaliteter og snitflader defineres så minimalt som muligt, med mulighed for senere udvidelse. Det betyder også, at det skal være muligt at udvide Integrationssystemet med nye services. P:nye-services Integrationssystemet skal kunne udvides med nye services efterhånden som behovene udvikler sig. Nye services kan her være egentlig ny funktionalitet eller udstilling af eksisterende funktionalitet på nye måder Mennesker i alle kritiske beslutninger Mange processer kan drives af oplysninger om hvor de involverede enheder befinder sig. Der er dog en række grunde til at kritiske beslutninger stadig bør have en menneskelig vurdering med i beslutningsprocessen: Positionering vil være behæftet med en vis usikkerhed uanset teknologi Det er vigtigt at dokumentere hvem der tager kritiske beslutninger Et it-system kan ikke identificere undtagelsessituationer, som f.eks. patient der blot kigger ind i det forkerte lokale. Det er derfor et generelt princip, at det altid bør være mennesker, der træffer kritiske beslutninger: P:beslutninger Sporingsløsninger skal gøre det let at træffe og dokumentere beslutninger, men skal generelt ikke selv træffe kritiske beslutninger. Eksempelvis bør systemet ikke beslutte at en patient er til opvågning bare fordi hans seng eller armbånd er i opvågningsrummet. Systemet skal kun støtte, at det er meget let for personalet at beslutte og dokumentere dette. 5.3 Standarder Snitflader baseret på standarder kan reducere udgifterne ved integration mellem systemer betragteligt. Denne reduktion viser sig dog kun, hvis et eller flere af systemerne anvender standarden i forvejen. Hvis ingen af systemerne anvender standarden i forvejen, vil det ofte være dyrere at integrere via en standard end via en proprietær snitflade. Side 42

43 Selvom begge systemer anvender en standard vil der ofte være en væsentlig integrationsopgave; kun forholdsvis simple standarder kan betragtes som plug-and-play. Det skyldes at mange standarder tilbyder flere alternative muligheder for at udveksle de samme typer informationer og at de ofte undlader at specificere en række detaljer. Til kommunikation mellem forskellige organisationer kan det ofte være en fordel at benytte en standard fra en tredjepart frem for en proprietær snitflade. Nogle gange kan det endda være et krav for at kunne handle med bestemte organisationer. Værdien af at basere en snitflade på en standard bør derfor overvejes nøje i hvert enkelt tilfælde og sammenholdes med hvor udbredte og velegnede de relevante standarder er. P:standarder Standarder anvendes kun på de steder i Referencearkitekturen, hvor de forventes at give praktisk værdi Standarder fra EPCGlobal anvendes Som beskrevet i Appendiks B.2.1 tilbyder EPCGlobal en suite af standarder som er vidt udbredte i forbindelse med anvendelse af RFID, dvs. der er en god sandsynlighed for at fremtidige integrationspartnere eller anvendelsessystemer understøtter EPCGlobals standarder. Disse standarder er derfor nogle man er nødt til at forholde sig til i forbindelse med introduktion af RFID i organisationen, og det vil derfor være en fordel, hvis disse kunne anvendes i Referencearkitekturen. Standarderne fra EPCGlobal er godt nok rettet mod RFID-løsninger, men er designet til at kunne anvendes i forbindelse med lignende AIDC-teknologer som eksempelvis stregkoder. Referencearkitekturen skal dog også understøtte RTLS- og WSNteknologier, som adskiller sig fra AIDC på væsentlige punkter. (Se Afsnit 4.1) En analyse af EPCGlobals standarder viser at de understøtter de informationer der er nødvendige for dette, inklusive identitet, tid, sted og sensordata. Den største begrænsning er definitionen af sted: EPCGlobal arbejder med diskrete, navngivne lokaliteter, dvs. f.eks. Lokale 1 eller Gangareal 12 og ikke med numeriske koordinater som (x,y,z), der ofte anvendes i RTLS-systemer. I Afsnit beskrives hvorledes disse koordinater kan håndteres sammen med EPCGlobals standarder. P:EPCGlobal De snitflader som baseres på standarder skal benytte EPCGlobals standarder Anvendelse af standarder mellem Lag 4 og 5 Lag 5 vil bestå af almindelige anvendelsessystemer, som eksempelvis EPJ, og eksterne systemer der er afhængige af sporingsdata, eksempelvis hos leverandører af varer. Især til sidstnævnte kan det blive et krav at udstille data via en relevant standard. For at holde arkitekturen så enkel som muligt benyttes den samme snitflade til alle anvendelsessystemer på lag 5. Dette har også den fordel at Integrationssystemet lettere kan udskiftes hvis det ønskes. Side 43

44 Den relevante snitflade i EPCGlobal hedder EPCIS Query Interface. (Se afsnit 6.1.2) Bemærk at denne, på trods af navnet, både udstiller sporingsdata ved hjælp af pull og push. P:snitflade-lag4 Den snitflade som Lag 4 udstiller til Lag 5 baseres på EPCIS Query Interface. Hvis bestemte data anvendes i mange anvendelsessystemer kan det blive relevant at udvikle en simplere, proprietær snitflade som supplement til denne standardbaserede snitflade. Denne skal dog stadig implementeres oven på den standardiserede snitflade, således at Integrationssystemet fortsat kan udskiftes hvis det ønskes Anvendelse af standarder mellem Lag 3 og 4 Det forventes at antallet af sporingssystemer på sigt vil blive noget mindre end antallet af anvendelsessystemer. Dermed vil antallet af integrationer mellem Lag 3 og 4 være væsentligt mindre end mellem Lag 4 og 5. Samtidigt er det kun stregkode- og RFID-systemer som forventes at stille en standardbaseret snitflade til rådighed. For andre teknologier, som eksempelvis Wi-Fipositionering er der ikke etableret standarder på dette niveau. Hvis et sporingssystem udstiller både standardbaserede og proprietære snitflader bør de standardbaserede anvendes, da dette vil lette indførelsen af fremtidige sporingssystemer som anvender samme standard. P:snitflade-lag3 Der kan anvendes proprietære snitflader mellem Lag 3 og Lag 4. Hvis der findes en standardbaseret snitflade foretrækkes denne frem for en proprietær snitflade Anvendelse af standarder mellem Lag 2 og 3 Læsere og tilhørende sporingssoftware indkøbes oftest som en samlet løsning og snitfladen er normalt proprietær. Referencearkitekturen udelukker ikke sådanne løsninger og stiller derfor ingen krav til denne snitflade. Ved indkøb af sporingsteknologier hvor der findes standarder, eksempelvis Wi-Fi, RFID og stregkoder, bør standardiseringskrav overvejes. P:snitflade-lag2 Der kan anvendes proprietære snitflader mellem Lag 2 og Lag 3. Hvis der findes en standardbaseret snitflade foretrækkes denne frem for en proprietær snitflade Anvendelse af standarder mellem Lag 1 og 2 Protokollen mellem id-brik og læser afgøres i nogle tilfælde af, hvilke id-brikker der modtages udefra, eksempelvis stregkoder og RFID-brikker monteret på varer. Der hvor disse varer skal registreres er det nødvendigt at understøtte de pågældende standarder. En udbredt løsning på dette er indkøb af læsere som understøtter flere protokoller Side 44

45 (multiprotokollæsere). Mange stregkodelæsere understøtter f.eks. de mest udbredte stregkodestandarder. Det vil det være en fordel, hvis alle læsere, der benytter samme teknologi, kan læse alle organisationens egne id-brikker, således at uforudsete fremtidige behov nemt kan understøttes. I det omfang der findes standarder bør disse benyttes, da fremtidige behov om håndtering af udefrakommende id-brikker med større sandsynlighed vil kunne opfyldes. Hvilke konkrete protokoller, der skal anvendes, besluttes i forbindelse med indkøb og afprøvning af hvert sporingssystem. P:snitflade-lag1 Organisationens egne id-brikker bør anvende så få protokoller som muligt for hver teknologi. En standardbaseret protokol bør vælges hvis en sådan findes. Hvor flere typer id-brikker kan forekomme, benyttes multiprotokollæsere. 5.4 Identitet Id er uden meningsbærende information Informationen på id-brikker må ikke kunne aflæses eller forfalskes af uautoriserede personer. Det gælder især id-brikker som bæres af personer, mens det i andre situationer er mindre væsentligt, eksempelvis ved mærkning af varer som tøj eller plastikhandsker. Hvor størst sikkerhed ønskes bør kommunikationen mellem id-brik og læser sikres ved kryptering. Som en ekstra sikkerhed, og som eneste sikkerhed i de situationer hvor man ikke kan eller ønsker at kryptere kommunikationen, må id en på id-brikken ikke indeholde meningsbærende information som f.eks. personnummer eller navn. Det vil sige at der skelnes mellem objektets reelle id, eksempelvis personnummer og pseudo-id, det id der gemmes på id-brikken. Disse betegnes ofte henholdsvis GID (for genuine id) og PID (for pseudo-id). Denne afkobling af brikkens id fra det fysiske objekts id giver yderligere mulighed for at producere brikkerne på forhånd inden de tilknyttes de fysiske objekter, og gør det nemmere at uddele erstatningsbrikker. P:surrogat-id PID må ikke kunne bruges af uautoriserede personer til udlede GID eller på anden måde identificere det objekt som bærer id-brikken. Dvs. PID skal være et surrogatid EPC anvendes til PID I forbindelse med integration af data fra flere sporingssystemer, inklusive data fra andre organisationer, er der behov for en globalt unik identifikation af alle objekter som skal spores. En sådan id er et grundlæggende element i EPCGlobal-standarderne, og kaldes EPC (Electronic Product Code). EPC er opbygget hierarkisk, eksempelvis EPC:ID: Side 45

46 RM:wifi:1234 (lidt simplificeret), hvilket gør den globalt unik men samtidig nem at administrere decentralt. Systemer som ikke anvender EPC mappes til/fra EPC af Integrationssystemet. P:epc-pid EPC benyttes som eneste PID på Lag 4 og 5. Anvendes andre id er på Lag 3 og nedefter mappes disse til EPC er ved overførsel til Lag Ansvarsfordeling Dette afsnit beskriver hvilke ansvar de forskellige dele af løsningen har Identitetsoversættelse foretages på Lag 5 Lag 4 kan principielt udstille id er til Lag 5 som PID er, GID er eller begge dele. EPCISstandarden specificerer at disse udstilles som EPC er, dvs. PID er. Det vil sige at Lag 5 har ansvar for at oversætte fra PID til GID. For at simplificere oversættelsesprocessen etableres en Identitetsservice, som alle anvendelsessystemer kan anvende til at oversætte mellem PID og GID, forudsat at de nødvendige rettigheder besiddes. Der vil ofte blive etableret yderligere services på Lag 5 rettet mod specifikke formål, eksempelvis sporing af patienter. Det vil være naturligt at disse services indkapsler oversættelsen af id er for systemer som for eksempel EPJ. P:id-oversættelse Der etableres en fælles service, Identitetsservice, til at oversætte mellem PID og GID på tværs af personer, udstyr, varer osv. Selve oversættelsen foretages på Lag 5 ved anvendelse af denne service. Der kan evt. etableres fælles services på Lag 5 som indkapsler denne funktionalitet Tildeling af PID på Lag 4 eller under Sporingsløsninger inkluderer oftest specialiseret software til skrivning af data på de tilhørende id-brikker, herunder at generere PID. Disse vil ofte have en række fordele i forhold til den specifikke teknologi og bør derfor kunne anvendes. Samtidig bør det være muligt at foretage dette arbejde centralt, hvis det ønskes, eksempelvis på tværs af et antal sporingsløsninger som anvender samme teknologi. Selve sammenkædningen af PID og GID bør ske centralt i et eller flere værktøjer til formålet. Side 46

47 P:pid-tildeling Generering nye PID er kan ske i det enkelte sporingssystem eller uden for dette. Sammenkædning af PID og GID sker med et eller flere centrale værktøjer til formålet Forretningslogik på Lag 5 Integrationssystemet er ikke en generel dataintegrationsplatform. Som beskrevet i Afsnit 2, Vision og mål, er systemet rettet mod integration af sporingsdata. Information udenfor dette scope er derfor et Lag 5-ansvar. P:forretningslogik Al forretningslogik, dvs. information om behandlinger, sygdomme, logistikprocesser, arbejdsgange osv. hører hjemme på Lag 5. Det samme gør information om fysiske objekter som patienter, personale, udstyr, varer, osv Positionslogik på Lag 4 Fortolkning af fysiske objekters aktuelle position og bevægelsesmønstre, herunder sammenholdning af informationer fra forskellige sporingssystemer, er avanceret logik og bør kun implementeres et sted. Dermed sikres konsistens og det undgås at vedligeholde logikken flere gange. P:positionslogik Al logik omkring positioner, som for eksempel aktuel position, registrering af bevægelse, genkendelse af samme sted, hører hjemme på lag 4. Eneste information på Lag 4 om fysiske objekter som patienter, personale, udstyr, varer, osv. er disses type, identitet, fysiske position/bevægelse og evt. sensordata. Tilstandsskifte, sensordata, alarmer osv. videresendes ufortolket til Lag 5. Objekters type er nødvendig fordi der kan være forskellige rettigheder og forskellig logik tilknyttet forskellige objekttyper Udveksling af metadata med eksterne parter på Lag 5 Som konsekvens af [P:forretningslogik] er det ikke Integrationssystemets ansvar at udveksle data om varer, patienter, udstyr osv. med eksterne parter. Det ansvar ligger i stedet i det pågældende logistiksystem eller lignende. P:data-udveksling Data om objekter, eksempelvis varer, udveksles direkte mellem applikationer på Lag 5 og de eksterne parter. Data om lokationer, hændelsestyper og PID er udveksles via EPCIS snitfladen på Lag Historiske data på Lag 5 Historiske sporingsdata kan trækkes ud til af Integrationssystemet eksempelvis til analyseformål. Det er dog kun data som er automatisk registreret der opsamles i Integrationssystemet, manuelt indtastede data gør ikke. Det er desuden kun sporingsdata, som opbevares i Integrationssystemet. Generelle data om objekterne, som ofte er relevante i analysesammenhæng, er ikke tilgængelige i integrationssystemet. Endelig vil Integrationssystemet være optimeret til et stort antal transaktioner (OLTP) og ikke til dataanalyse (OLAP). Side 47

48 Egentlig OLAP/warehouse-funktionalitet hører derfor hjemme på Lag 5. Et sådant system kan eksempelvis periodisk udtrække de data fra Integrationssystemet som er relevante og kombinere disse med data fra andre systemer. Sporingshændelser gemmes dog kortvarigt i Integrationssystemet, dels for at kunne understøtte polling, som er krævet af EPCIS, og dels for at sikre persistens i forbindelse med nedbrud. Hændelser kan også være gemt i log-filer. Disse data skal slettes periodisk, enten manuelt eller automatisk. Hvor længe sporingshændelser og logs opbevares afhænger af anvendelsessystemernes aktuelle behov. Her skal der også tages hensyn til Persondatalovens krav om sporede personers samtykke samt princippet om proportionalitet mellem mål og middel. Se Afsnit 3.2 Lovgivning og regler. P:historiske-data Warehouse-funktionalitet hører hjemme på Lag 5. Sporingshændelser og logs opbevares kortvarigt i Integrationssystemet. 5.6 Administration Administration vha. medfølgende værktøjer Sporingsløsninger inkluderer oftest specialiseret software til administration og konfiguration af løsningen. Disse værktøjer vil derfor ofte være bedre end en generel løsning udviklet til en række forskellige sporingsteknologier. Nogle softwareprodukter indeholder dog funktionalitet til administration og konfiguration af læsere og id-brikker fra flere leverandører, men rettet mod en bestemt teknologi som eksempelvis RFID. En sådan funktionalitet bør overvejes i forbindelse med indkøb af konkrete produkter, men er ikke en del af Integrationssystemet. P:administrationsværktøjer Administration af sporingsløsninger foregår ved hjælp af de medfølgende eller til formålet indkøbte værktøjer. Integrationssystemet tilbyder ikke centraliseret administration på tværs af sporingsteknologier Snitflader til centraliseret monitorering Sporingsløsninger inkluderer ofte værktøjer til monitorering af at læsere fungerer, idbrikkers batteristatus, at der ikke er overbelastning af dele af systemet og lignende. Sådanne data bør udstilles via snitflader, som gør det muligt at overvåge løsningen fra centraliserede overvågningsværktøjer som Tivoli, Orion, mv. Der kan dog være attraktive sporingsløsninger som ikke gør dette. Side 48

49 P:monitoreringsværktøjer Ikke-trivielle sporingsløsninger skal indeholde mulighed for monitorering af løsningens sundhed. Sporingsløsninger bør udstille snitflader til monitorering. Dette er dog ikke et absolut krav. 5.7 Lokaliteter Identificering af steder på Lag 5 Et geografisk sted kan angives på to forskellige måder; som numeriske koordinater eller som et diskret, navngivet sted, i det følgende betegnet en lokalitet. Med koordinater kan man angive et vilkårligt sted, med en principielt vilkårlig præcision. Med lokaliteter kan man kun angive de steder man på forhånd har udvalgt; Det kunne være alle lokaler, navngivne sektioner af gangarealer, eller placeringen af en brandhane. Brugere benytter oftest navngivne lokaliteter til at identificere steder. Alle lokaliteter kan oversættes til et område angivet med koordinater. En gennemgang af alle identificerede brugsscenarier viser at navngivne lokaliteter er tilstrækkelige til at opfylde behovene med nogle få undtagelser. I særlige scenarier, eksempelvis hvor man har behov for at tegne detaljerede bevægelser på et kort, kan der være brug for at videreformidle koordinater til et eller flere anvendelsessystemer. Der findes en række standarder for geografiske koordinater, men ingen er direkte understøttet af EPCIS. Behovet for koordinater kan derfor kun understøttes ved at udvide EPCIS-standardens definitioner. P:steder Steder angives som udgangspunkt vha. navngivne lokaliteter. Hvis der er behov for geografiske koordinater udstilles disse af Integrationssystemet som supplement til de navngivne koordinater Central lokalitetsdatabase og -service Det er vigtigt at alle sporingsrelaterede systemer anvender de samme lokaliteter. For at sikre dette etableres en central lokalitetsdatabase således at disse data vedligeholdes ét sted. Der udstilles en service og brugerflade til at tilgå og vedligeholde data. Desuden etableres synkroniseringsmekanismer til at holde lokalitetsdatabasen opdateret i forhold til andre datakilder med information om steder. P:lokalitetsservice Der etableres en fælles database med alle lokaliteter som tilgås og vedligeholdes via en service, Lokalitetsservice Identificering af lokaliteter på Lag 3 eller 4 Ved brug af navngivne lokaliteter har nogle sporingssystemer, typisk RTLS-systemer, behov for at oversætte koordinater til lokaliteter. Denne opgave kan foretages på enten Lag 3 eller Lag 4. Det vigtige er at listen af lokaliteter ikke skal vedligeholdes flere steder. Side 49

50 P:positionsoversættelse Positionering af fysiske objekter i et bestemt lokale, dvs. oversættelse fra koordinater til navngivne lokaliteter, kan gøres enten på Lag 3 eller 4. Gøres det på Lag 3, typisk fordi der allerede er funktionalitet til dette i sporingssystemet, skal lokaliteterne automatisk trækkes ind i sporingssystemet fra Lokalitetsservice. 5.8 Filtrering Eksplicit filtrering Mange sporingsteknologier leverer hændelser med ned til et sekunds interval. Det bliver til et meget stort antal hændelser, som kan give skaleringsudfordringer, belaster netværket og ikke er nødvendigt i nogen af de identificerede brugsscenarier. For at undgå dette bør datamængden reduceres, og gerne decentralt, dvs. så tæt på læseren som muligt. Det kan dels ske ved at reducere frekvensen hvormed sporingshændelser udsendes og dels ved at filtrere hændelser fra som ikke har interesse. Eksempelvis er der ingen grund til at sende mange hændelser om at en person ikke har bevæget sig eller at antallet af varer i et lagerrum er uændret. Det er dog essentielt at anvendelsessystemer, så præcist som muligt, ved hvilke hændelser de kan forvente at modtage, da ændringer i dette mønster kan være komplicerede at håndtere i anvendelsessystemerne. P:eksplicit-filtrering Det er tilladt for både Integrationssystemet og sporingssystemer at filtrere hændelser fra som ikke er relevante. Dog må hændelser defineret som kritiske aldrig filtreres fra. Det skal være eksplicit dokumenteret, hvilke hændelser der leveres fra Integrationssystemet til anvendelsessystemerne, herunder hvilke hændelser der er kritiske, samt hvilke der filtreres fra enten i Integrationssystemet eller de underliggende sporingssystemer. Alle ændringer til dette skal godkendes af Styregruppen Filtrering decentralt Præcist hvordan filtreringen skal foregå afhænger af hvilke brugsscenarier der aktuelt skal understøttes; filtreringen skal således være konfigurerbar. P:decentral-filtrering Sporingssystemerne skal kunne konfigureres således at der kun udsendes sporingshændelser periodisk eller når bestemte værdier registreres. Filtreringen bør kunne ske decentralt, dvs. tæt på læseren. 5.9 Fejlhåndtering Redundans af hensyn til pålidelighed Hvis Integrationssystemet fejler, eksempelvis ved hardwarenedbrud, er det en forudsætning for overholdelse af oppetidskravene [K:oppetid] at systemet er redundant. Side 50

51 P:redundans For at sikre Integrationssystemets tilgængelighed etableres en redundant løsning, hvor selve Integrationssystemet og alle services er dublerede Korrektion af fejl i Integrationssystemet Fejlregistreringer, eksempelvis upræcis positionering, kan have store konsekvenser i anvendelsessystemerne. Det er derfor vigtigt at disse er opmærksomme på fejlregistreringer. Nogle af disse fejl kan korrigeres på Lag 3 og nogle kan først korrigeres på Lag 4 hvor der er mere information til rådighed, eksempelvis om hvordan senge kan bevæge sig. Et fælles mål for fejlraten kan ikke opstilles; I nogle situationer er høj fejlrate med høj opdateringsfrekvens optimalt og i andre er lav fejlrate og lav frekvens bedre. De samme data kan derfor blive udstillet med flere kvaliteter og en vigtig del af snitfladen mellem Lag 4 og 5 er således en angivelse af kvaliteten af registreringerne. P:korrektion-infrastruktur Fejlkorrektion kan ske på Lag 3 og/eller Lag 4. Korrektheden af de resulterende sporingsdata skal være klart specificeret således at anvendelsessystemer kan håndtere disse korrekt Fejl skal kunne korrigeres på Lag 5 Det kan ikke undgås at fejlregistreringer modtages på Lag 5. Det kan skyldes menneskelige fejl eller upræcise sensorer. Disse fejlhændelser kan afstedkomme en række konsekvenser i de berørte anvendelsessystemer; konsekvenser som kun kan korrigeres i de pågældende anvendelsessystemer. Det er således vigtigt at der findes funktionalitet til denne fejlkorrektion. Eksempelvis kan en sengs position medføre at den registreres som til vask. Hvis dette skyldes en fejlregistrering i positioneringssystemet, skal der være en måde at ændre sengens status tilbage. P:korrektion-applikationer Hver applikation på Lag 5 skal implementere brugerflade eller automatik til at rette op på konsekvenserne af fejlbehæftede hændelser Svartider Som en konsekvens af [K:forsinkelse]skal det være muligt at videresende hændelser til anvendelsessystemer umiddelbart efter at de er modtaget, dvs. uden at anvendelsessystemet eksplicit skal hente data (polling). Side 51

52 P:forsinkelse Integrationssystemet skal kunne videresende indkommende hændelser med det samme, dvs. uden polling Sikkerhed Netværk kan have varierende sikkerhed De netværk der benyttes til kommunikation mellem delsystemerne, hvad enten de er kablede eller trådløse, yder oftest i sig selv en vis beskyttelse mod uautoriseret adgang til data. Det er dog ikke sikkert at det altid vil være tilfældet for fremtidige anvendelser. Da data kan være følsomme kan der derfor være nødvendigt med yderligere beskyttelse. P:usikre-netværk Anvendelse af hospitalets netværk er ikke nødvendigvis tilstrækkeligt til at beskyttedataoverførsel på netværket eller adgang til systemer på netværket. Overførsel af følsomme data skal derfor kunne krypteres Audit-logning Som angivet i [K:auditering] bør det være muligt at registrere hvilke sporingssystemer der producerer data og hvilke anvendelsessystemer der konsumerer disse data. Periodisk review (evt. automatisk) af disse logninger kan medvirke til at opdage sikkerhedsproblemer, fejlagtig tildeling af rettigheder, mv. Registrering af hvilke systemer der producerer data kan registreres som en del af persisteringen af sporingshændelser uden væsentligt overhead. Registrering af hvem der anvender de enkelte hændelser vil medføre et væsentligt større overhead. I stedet kan det registreres hvilke forespørgsler der udføres af anvendelsessystemerne. P:auditlogning Integrationssystemet bør kunne logge hvilke systemer der producerer sporingsdata samt hvilke systemer der stiller hvilke forespørgsler. Disse logninger bør reviewes periodisk. Side 52

53 6 Arkitekturbeskrivelse Løsningen består af anvendelsessystemer, sporingssystemer og Integrationssystemet som afkobler disse, samt databaser til bl.a. lokaliteter, id er og sporingshændelser. Imellem disse definerer Referencearkitekturen klare servicesnitflader. Referencearkitekturen beskriver desuden hvorledes kravene til sikkerhed, svartider, skalering mv. kan opfyldes. Dette afsnit beskriver Referencearkitekturen fra en række forskellige synsvinkler. Afsnit 6.1, Funktionalitet identificerer arkitekturens funktionelle komponenter, dvs. hvilke delsystemer der indgår i løsningen. Afsnit 6.2, Information beskriver snitfladerne mellem løsningens komponenter samt de datakilder som indgår i løsningen. Afsnit 6.3, Miljø beskriver krav til og antagelser om eksekveringsmiljøet. Afsnit 6.4, Sikkerhed giver et overblik over trusler mod systemet og de modforanstaltninger som er indbygget i Referencearkitekturen eller kan etableres. Afsnit 6.5, Svartider beskriver hvorledes løsningens svartidskrav kan overholdes. Afsnit 6.6, Skalering beskriver hvorledes løsningens skaleringskrav kan overholdes. Afsnit 6.7, Fleksibilitet præsenterer en liste af ændringer som sandsynligt vil forekomme i løsningen samt hvorledes disse håndteres. 6.1 Funktionalitet Dette afsnit beskriver løsningens funktionelle komponenter, dvs. de væsentlige delsystemer der indgår, deres ansvar og interaktion. Snitfladerne mellem delsystemerne identificeres i dette afsnit, men beskrives først i Afsnit 6.2, Information Delsystemer I arkitekturen indgår de komponenter som er vist på Figur 3. Deres ansvar beskrives herunder. Side 53

54 Anvendelsessystemer Præsenterer sporingsdata for en bruger Eksterne anvendelsessystemer Henter sporingsdata til brug i en anden organisation Centrale værktøjer Bruges til at administrere/ monitorere integrationssystemet og relaterede databasers indhold Identitetsdatabase Indeholder sammenhænge mellem PID er og GID er (Hvem) Hændelsesdatabase Indeholder alle validerede og fejlkorrigerede hændelser Integrationsystem (ISSI) Integrerer hændelser fra flere sporingssystemer Procesdatabase Indeholder alle procestrin relateret til sporing/identifikation (Hvad) Lokalitetsdatabase Indeholder alle navngivne lokaliteter som anvendes på DNU (Hvor) Sporingssystemer Opsamler sporingshændelser fra en type sporingsteknologi i et bestemt område Decentrale værktøjer Bruges til at administrere/ monitorere et eller flere sporingssystemer Figur 3:De vigtigste systemer og del-systemer i Referencearkitekturen (bokse), samt de væsentligste afhængigheder mellem disse (linjer). Tre bokse oven på hinanden angiver en række af systemer. Sporingssystemer er de softwaresystemer der opsamler registrerede hændelser fra den fysiske hardware. Hver type system vil typisk høre til en bestemt teknologi, eksempelvis RFID, fra en bestemt leverandør. Sporingssystemer har ansvar for at opsamle hændelser og videresende disse til Integrationssystemet. Fejlkorrektion og kvalitetssikring af hændelser kan være en del af sporingssystemernes funktionalitet. Anvendelsessystemer er de systemer der aftager sporingsdata. Disse data anvendes typisk af andre services som beriger data, eksempelvis med patienters navne, hvorefter data præsenteres i en brugerflade. Det er således anvendelsessystemets ansvar at fastholde viden om objekternes aktuelle tilstand og fortolke, hvordan sporingsdata påvirker denne [P:forretningslogik]. Eksterne systemer er anvendelsessystemer som findes udenfor organisationen. Disse præsenterer nogle særskilte problematikker omkring sikkerhed og adgang til yderligere data om de sporede objekter, men agerer ellers som interne anvendelsessystemer. Side 54

55 Integrationssystemet har ansvar for at opsamle sporingsdata fra alle sporingssystemer og videreformidle disse til anvendelsessystemerne. I denne proces indgår yderligere fejlkorrektion og en vis berigelse af informationen i form af fortolkning af sporingshændelsers betydning. Integrationssystemet vedligeholder dog ikke tilstand for de sporede fysiske objekter og tilgår ikke forretningsdata fra eksempelvis EPJ, logistiksystemer eller økonomisystemer [P:positionslogik]. Hændelser fortolkes derfor alene baseret på objekternes type (f.eks. patient, seng, portør), sporingssystem (registreret af RFID-læser X fra Leverandør Y) og baggrundsviden om lokaliteter (f.eks. operationsstue, ingen adgang for patienter, sted til senge som skal vaskes ). Yderligere konklusioner omkring objekterne hører hjemme i anvendelsessystemerne. Dette gælder eksempelvis om en patient er under operation, som kræver mere information end blot hvor patienten aktuelt befinder sig. Det gælder også at en patient har bevæget sig fra en operationsstue til en opvågningsstue, som kræver viden om patientens tidligere tilstand (på operationsstuen). Identitetsdatabasen benyttes af anvendelsessystemer til at oversætte mellem et objekts faktiske identitet (GID) og elektroniske id på eksempelvis en id-brik (PID). Integrationssystemet har ikke ansvar for denne oversættelse og det er således kun anvendelsessystemer, der tilgår disse data. Integrationssystemet anvender dog Identitetsdatabasen til validering af PID er. Det betyder også at Integrationssystemet ikke vedligeholder nogen form for tilstand om de sporede objekter, eksempelvis hvor de tidligere har befundet sig. Lokalitetsdatabasen benyttes af Integrationssystemet til at angive positionen af objekter. Dvs. alle udsagn om hvor noget befinder sig fra Integrationssystemet til anvendelsessystemer refererer til lokaliteter i denne database. Yderligere information om lokaliteter som Integrationssystemet anvender findes også i denne database, dvs. Integrationssystemet bruger ikke andre datakilder med informationer om lokaliteter. Lokalitetsdatabasen definerer et unikt navn for alle lokaliteter som anvendes i organisationen, herunder relevante lokaliteter udenfor denne. Lokaliteter kan overlappe helt eller delvist. Disse data kan også anvendes til andre formål i organisationen, eksempelvis produktion af lokaleskilte. Procesdatabasen benyttes af Integrationssystemet til at angive betydningen af hændelser. Dvs. alle udsagn om hvad et objekt har foretaget sig refererer til procestrin i denne database. Det kan for eksempel være har bevæget sig ind i eller befinder sig på samme lokalitet som. Procestrin som patient er til opvågning eller ordre er leveret hører ikke hjemme her, men i de relevante anvendelsessystemer. I praksis kan Procesdatabasen være en database, en XML-fil eller andet. Side 55

56 Hændelsesdatabasen indeholder alle registrerede sporingshændelser og benyttes til at besvare historiske forespørgsler fra anvendelsessystemer til Integrationssystemet. Det kan for eksempel være Alle hændelser på en lokalitet mellem kl. 16 og 17 for objekter af typen Seng. Centrale værktøjer benyttes til administration og overvågning af Integrationssystemet og tilhørende databaser. Decentrale værktøjer benyttes til administration og overvågning af sporingsløsninger. Funktionaliteten i disse decentrale værktøjer kan overlappe med nogle af de centrale værktøjer. Denne problematik beskrives yderligere i Afsnit Afhængigheder og snitflader Figur 4 viser Referencearkitekturens komponenter, deres afhængigheder og de snitflader som defineres af Referencearkitekturen. Lokalitetsadministration (GUI) Anvendelsessystemer Identitetsadministration (GUI) EPCIS QueryInterface SOAP/XML via HTTP/HTTPS Integrationssystem (ISSI) LocalityService XML via HTTP/HTTPS Service IdentityService XML via HTTPS Lokalitetsservice Hændelsesdatabase EPCIS CaptureInterface XML via HTTP/HTTPS Procesdatabase Identitetsservice Id-kilder (BSK, Columna, Medikoteknisk DB, Maximo) Lokalitets-database Identitetsdatabase Sporingssystemer Lokalitetskilder EPJ, bygningstegninger, mv. Figur 4: Komponentdiagram (UML) der viser væsentlige komponenter i Referencearkitekturen og deres afhængigheder. Definerede snitflader er indikeret med navngivne interface-symboler. Fire snitflader defineres af Referencearkitekturen: 1. Snitfladen som sporingssystemer anvender til at aflevere sporingshændelser til Integrationssystemet (EPCIS CaptureInterface). Denne snitflade er baseret på EPCISstandarden, men der stilles ikke krav til at EPCIS-snitfladen benyttes direkte af sporingssystemet, jfr. afsnit Hvis sporingssystemet ikke er EPCIS-kompatibelt, indskydes en oversættelseskomponent. Side 56

57 2. Snitfladen som Integrationssystemet anvender til at aflevere sporingshændelser videre til anvendelsessystemer (EPCIS QueryInterface). Denne er også baseret på EPCIS-standarden. 3. Snitfladen som Integrationssystemet og andre anvender til at læse og skrive data i Lokalitetsdatabasen (LocalityService). Denne snitflade er proprietær. 4. Snitfladen som Integrationssystemet og andre anvender til at læse og skrive data i Identitetsdatabasen (IdentityService). Denne snitflade er også proprietær. Udover hovedkomponenterne præsenteret ovenfor, er her desuden vist de specifikke services som indkapsler databaserne (Identitetsservice og Lokalitetsservice), de datakilder som ejer de forskellige id er (eksempelvis EPJ som ejer patient-id er) og de services som kører i Integrationssystemet. Sidstnævnte kan være standard-services, defineret af EPCIS-standarden, eller proprietære services udviklet til specifikke behov. Figur 5 viser hvordan disse snitflader bringes i anvendelse for tre centrale scenarier: Metadata: Et anvendelsessystem henter information om de lovlige dataværdier der kan indgå i en sporingshændelse afsendt af Integrationssystemet. Dvs. vokabularielister. Push-scenarie: Anvendelsessystemet abonnerer på specifikke hændelser fra Integrationssystemet. Disse hændelser sendes løbende til anvendelsessystemet når en hændelse modtages af et sporingssystem. Pull-scenarie: I pull-scenariet forespørger anvendelsessystemet på specifikke hændelser fra Integrationssystemet, som returnerer disse. Der sendes ikke løbende hændelser. Hver af disse snitflader defineres mere præcist i næste afsnit. Side 57

58 Anvendelsessystem Integrationssystem Identitetsservice Lokalitetsservice Sporingssystem Metadata: Forespørgsel efter EPC er, Lokaliteter eller Procestrin Liste Læs fra relevant service/database Push-scenarie: Abonnement oprettes baseret på EPC er, Lokaliteter og/eller Procestrin Rapporter sporingshændelse (EPC er, Koordinat eller Lokalitet, Tid) Valider EPC er EPC er OK Oversæt koordinat eller valider lokalitet Lokalitet Genkend Procestrin Kan være flere lokaliteter Gem i Hændelsesdatabasen Notificer om sporingshændelse (EPC er, Lokalitet, Procestrin, Tid) Find modtagere Pull-scenarie: Forespørgsel baseret på EPC er, Lokaliteter, Procestrin og/eller Tid Hændelser Læs fra Hændelsesdatabasen Figur 5: Sekvensdiagram (UML), der viser hvordan snitfladerne bruges når anvendelsessystemer henter metadata, løbende modtager nye sporingshændelser og henter gemte sporingshændelser Anvendelsessystemer EPCIS-snitfladen kan benyttes direkte af et anvendelsessystem, hvis ikke behovene er specielt komplicerede. Anvendelsessystemet kan dog have behov for snitflader, som er mere målrettede mod dets specifikke behov. Der kan også være tale om fælles behov som flere anvendelsessystemer deler og som man derfor ønsker at løse på en gang. Figur 6 viser tre forskellige strategier for integration af anvendelsessystemer. Side 58

59 Figur 6: Tre forskellige måder hvorpå anvendelsessystemer kan tilgå Integrationssystemet. I integration (1) udvides anvendelsessystemet med EPCIS-specifik funktionalitet, der kalder de søgninger man har brug for. Dette er enkelt, men kræver at anvendelsessystemet forholder sig til EPCIS-specifikke begreber. Anvendelsessystemet skal altså selv lave oversættelse mellem sine egne domæne-begreber og EPCIS-begreberne. Desuden er søgesproget ret begrænset, så det er grænser for hvor komplicerede søgninger man kan formulere. I integration (2) er Integrationssystemet udvidet med Service plug-ins. Det er funktionalitet, der kan søge i Integrationssystemets databaser, og som returnerer data, der er kompatible med EPCIS-snitfladen. EPCIS-snitfladen giver mulighed for, at man kan anvende denne type udvidelser som en søgning på linje med almindelige søgninger. Dette giver mulighed for, at man kan lave vilkårligt komplekse søgninger. I integration (3) indskyder man en ekstra service (front-end service) mellem anvendelsessystemet og Integrationssystemet. Det giver mulighed for at lave en anvendelsessystem-specifikt snitflade, som tager sig af de oversættelser der skal ske mellem begreberne i anvendelsessystemet og begreberne i Integrationssystemet. Det betyder, at der ikke skal laves så mange ændringer i selve anvendelsessystemet, og det giver også mulighed for at lave services, der opfylder behov som flere anvendelsessystemer har. Figur 7 viser integration (3) eksemplificeret i EPJ. Side 59

60 Figur 7: Eksempel på anvendelse af Integrationssystemet, hvor en EPJ-service udstiller mere specifikke funktionaliteter til resten af EPJ samt andre systemer som ønsker at benytte disse funktionaliteter Sporingsløsninger Sporingsløsninger kommer i mange varianter. I dette afsnit beskrives hvordan denne variation håndteres. På Figur 8 er illustreret det simplest tænkelige sporingssystem; en enkelt læser koblet til en PC. Formålet kan være at undgå indtastning i et tekstfelt ved at tilkoble en kortlæser eller stregkodelæser til PC en. Anvendelsessystem En enkelt applikation der som den eneste anvender sporingsdata fra den pågældende læser Integrationsystem (ISSI) Simpelt sporingssystem Sender hændelser fra en enkelt læser til en enkelt PC. Fx driver installeret på PC en. Eneste undtagelse er hvis hændelsen med sikkerhed ikke kan være relevant for andre systemer. Figur 8: Simple sporingsløsninger skal også sende data til Integrationssystemet, dog med en enkelt undtagelse. Side 60

61 For simple systemer som dette gælder samme regel som for større systemer: Alle sporingssystemer skal sende hændelser til Integrationssystemet. Dette kan gøres nemt og asynkront via et simpelt HTTP-interface. Figur 9 viser et eksempel på en komplet sporingsløsning, der i sig selv indeholder de samme komponenter som vis på Figur 3. Dvs. den indeholder delsystemer på alle lag; brugerflade, middleware, sporingsdatabase, lokalitetsdatabase, id-database, læsere, id-brikker og administrationsværktøjer osv. Komplet sporingsløsning Lag 5, Slutbrugersystemer Proprietær snitflade Lag 4, Wi-Fi-middleware Proprietær snitflade Lag 3, Wi-Fi-edgeware Hændelser PID er Lokaliteter Integrationsystem (ISSI) Identitetsdatabase Lokalitetsdatabase Proprietær snitflade Lag 2, Wi-Fi-antenner Proprietær snitflade Lag 1, Wi-Fi-brikker Figur 9: Et eksempel på en komplet sporingsløsning som inkluderer elementer fra alle lag af arkitekturen, herunder egen database med identiteter og lokaliteter. En sådan løsning skal udveksle tre typer data: sporingshændelser, PID er og lokaliteter. En sådan løsning passer fint ind i Referencearkitekturen, så længe den blot overholder tre regler: 1. Alle valide og relevante sporingshændelser sendes også til Integrationssystemet. Dette gælder som minimum alle kritiske hændelser. Se også Afsnit 5.8.1, [P:eksplicit-filtrering]. 2. Hvis sporingsløsningen anvender navngivne lokaliteter, skal disse automatisk importeres fra Lokalitetsdatabasen. Processen herfor aftales med Styregruppen. 3. Alle PID er (id er på id-brikker) skal synkroniseres med Integrationssystemet. PID erne kan således enten skabes i sporingsløsningen og eksporteres til Identitetsdatabasen eller omvendt skabes i Identitetsdatabasen og importeres i sporingsløsningen. Den strategi der anvendes skal gælde for alle PID er anvendt i det pågældende sporingssystem, for at undgå komplekse opdateringsscenarier. En sporingsløsning med egen brugerflade behøver således ikke at anvende hændelser fra Integrationssystemet. Side 61

62 6.2 Information Dette afsnit beskriver designet af de fire identificerede snitflader, dvs. de vigtigste valg i relation til hver snitflade. Her beskrives ingen konkrete valg omkring opbevaring af data, blot indirekte krav via snitfladerne, til hvilke data der som minimum skal opbevares. Konkrete programmeringssnitflader (API er) defineres som en del af Integrationssystemets etablering. Alle ændringer til disse skal godkendes af Styregruppen, da selv små ændringer kan have store konsekvenser for anvendelsessystemerne Identitet EPC-standarden benyttes som PID på id-brikker [P:EPC]. Hvis dette ikke er praktisk muligt pga. plads (EPC er kan være ret lange) eller fordi id-brikker kommer udefra, så har integrationen mellem det pågældende sporingssystem og Integrationssystemet til opgave at oversætte mellem EPC og sporingsløsningens proprietære PID er. Det anbefales at anvende et hierarkiske navnerum med følgende elementer: Identifikation af EPC-standarden Identifikation af id-kategorien. (f.eks. om id beskriver objekt, lokalitet eller organisation) Identifikation af den ansvarlige organisation Identifikation af id-tildelingssystem indenfor organisationen. Identifikation af den enkelte id-brik Et id vil dermed have følgende format: urn:epc:id:gid:[dnu].[system].[id-brik] Opdelingen efter id-tildelingssystem, eller evt. id-tildelingsansvarlig hvis id er tildeles manuelt af en person, giver hvert system/ansvarlig frihed til at råde over sin egen idnummerserie. Derved undgås at forskellige systemer eller personer skal koordinere id er indbyrdes Snitflade til anvendelsessystemer Snitfladen som udstilles til anvendelsesapplikationer baseres på EPCGlobals EPCISstandard. Den relevante snitflade er EPCIS Query Interface, som giver mulighed for simple forespørgsler på EPC-baserede hændelser, både som forespørgsel-svar via SOAP og som abonnement på en bestemt forespørgsel med callback via HTTP. EPCIS udstiller ikke blot sporingsdata, men også lister af de metadata, der kan returneres om disse hændelser, eksempelvis lokaliteter og typer af objekter (f.eks. patient, seng, personale, mv.). Standarden giver som udgangspunkt kun mulighed for simple forespørgsler som kombinerer udvalgte hændelsesattributter, eksempelvis alle hændelser i områderne A, B, C i tidsrummet Det er dog tilladt at tilføje egne forespørgsler. For mere information om EPCIS se Afsnit B.2.1 EPCGlobal. Side 62

63 EPCIS giver som mange andre standarder kun interoperabilitet til et vist punkt. Eksempelvis definerer den de grundlæggende beskedformater, men udtaler sig ikke præcist om, hvilke af disse man skal benytte i hvilke situationer. EPCIS er således en relativt åben standard, som tillader forretningspartnere at definere deres fælles sprog. EPCGlobal definerer dog også Core Business Vocabulary Standard, som er et konkret bud på et sådant fælles sprog. Heri defineres mange begreber som også er nyttige indenfor hospitalsdomænet, men der mangler også en række begreber, dels i relation til hospitaler og dels i relation til andre sporingsteknologier end RFID. Den konkrete anvendelse af EPCIS tilpasset sporing på hospitaler kaldes i det følgende for EPCIS-RATI (for Reference Architecture for Tracking and Identification). Samme format bør som minimum benyttes inden for den samme organisation, eksempelvis Region Midtjylland. Det desuden anbefales at arbejde hen imod en bredere standard for udveksling af sporingsdata på hospitaler. EPCIS-RATI vil udvikle sig over tid, eksempelvis når nye sensorer eller konkrete brugsbehov kommer til. Det er Styregruppens ansvar at styre denne udvikling under hensyntagen til den langsigtede kvalitet af løsningen. Hvis et begreb findes i Core Business Vocabulary Standard anvendes det i EPCIS-RATI i denne betydning. Hvis et begreb ikke defineres af Core Business Vocabulary Standard defineres det af Styregruppen. I det følgende beskrives de basale elementer som anvendes i den initielle udgave af snitfladen, kaldet version 1.0. EPCIS-RATI version 1.0 er baseret på EPCIS version Dele af Core Business Vocabulary Standard version 1.0 anvendes, som defineret nedenfor. Følgende 4 hændelsestyper defineres af EPCIS. Kun de tre første understøttes af EP- CIS-RATI: ObjectEvent: En registreret hændelse for et antal EPC er. Eksempelvis patienter der bevæger sig rundt uafhængigt af hinanden. AggregationEvent: En registreret hændelse for et antal EPC er, som befinder sig inden i en anden EPC. Eksempelvis en vogn med varer. QuantityEvent: En registreret hændelse for et antal objekter, som ikke angives eksplicit men blot ved et antal. Eksempelvis antallet af en bestemt type varer i et lagerrum. TransactionEvent: Denne type hændelse angiver at et antal EPC ers relation til en forretningstransaktion, eksempelvis varer som tilknyttes et ordrenummer. Dette er udenfor Integrationssystemets ansvarsområde. En række dataelementer er valgfrie i EPCIS. Integrationspartnere er dog nødt til at blive enige om, hvilke der benyttes, samt præcist hvad de betyder. De valgfrie dataelementer er beskrevet nedenfor, herunder hvorvidt og hvordan de anvendes i EPCIS-RATI 1.0: Side 63

64 Element Anvendt? Specifikation Business Location Ja Betegner det sted for hændelsen forekom, eksempelvis hvor RFIDaflæsningen skete eller hvor et Wi-Fi-tag blev sporet til. Der kan også være tale om flere steder. Business Location skal være et ID på et af de steder der er defineret i Lokalitetsdatabasen. I selve hændelsen vil kun indgå den unikke id på stedet, mens øvrig information skal hentes fra Lokalitetsdatabasen. Business Step Ja Betegner betydningen af denne hændelse. Som udgangspunkt benyttes værdier defineret i EPCGlobal Core Business Vocabulary Standard, eksempelvis begreber som: arriving, departing, picking, receiving, removing, repackaging, replacing og shipping. Udover disse standardværdier kan det også give mening at definere business steps som er specifikke for DNU. Disse kan være af overordnet karakter som ovenfor eller mere konkrete, afhængigt af de aktuelle behov og indenfor rammerne af de informationer Integrationssystemet har til rådighed. Eksempler: positioning, entering, exiting, patient_entering, sending_signal, sending_sensordata, sending_alarm. Etablering af den endelige liste foretages i forbindelse med opbygning af integrationssystemet. Listen vedligeholdes og versioneres derefter af Styregruppen. Disposition Nej Forretningstilstanden af sporede objekter. Read Point Nej Den læser som aflæste id-brikken. Business Transaction Nej Identifikation af en specifik forretningstransaktion, som f.eks. et ordrenummer. EPCIS-standarden understøtter udvidelser på en række punkter, eksempelvis tilføjelse af nye værdier som beskrevet ovenfor, men også tilføjelse af nye felter i hændelsesbeskeder. Sidstnævnte er nødvendig for at kunne overføre sensordata og andre signaler fra id-brikker. Udvidelser vedligeholdes og versioneres af Styregruppen. Korrektheden af de hændelser som udsendes er afgørende for hvorledes de kan anvendes. Det er derfor en obligatorisk del af snitfladespecifikationen at angive, hvor stor fejlrate der kan forventes af forskellige typer hændelser. Ændringer i denne kvalitet bør betragtes og behandles som en ændring af snitfladen. Der kan eventuelt tilføjes specifikke business steps til data af særlig kvalitet, eksempelvis hændelser som er upræcise men med høj frekvens. Som beskrevet i afsnit kan visse brugssituationer kræve steddata i form af koordinater. Hvis der bliver behov for at udsende disse koordinatdata med høj frekvens for et stort antal objekter kan det blive nødvendigt at benytte et simplere format end EP- CIS-XML for at reducere overheadet. Denne udvidelse er mulig indenfor rammerne af EPCIS. Da disse koordinatdata vil være relativt simple dataelementer og kun vil blive Side 64

65 benyttet til særlige formål, bør det dog overvejes om en proprietær snitflade er mere velegnet. Det er Integrationssystemets ansvar at sikre at alle kritiske hændelser, dvs. hændelser som ikke må gå tabt, leveres til alle som har abonneret på disse. Afgørelsen af hvilke hændelser der er kritiske foretages af Integrationssystemet. Det skal være eksplicit dokumenteret hvilke hændelser der leveres til anvendelsessystemer, herunder hvilke der filtreres fra af Integrationssystemet og af sporingssystemerne. EPCIS Query Control Interface understøttes via SOAP over HTTP eller HTTPS. (HTTPS er en tilladt udvidelse ift. EPCIS-standarden.) EPCIS Query Callback understøttes via EPCIS XML over HTTP eller HTTPS Snitflade til sporingsssystemer EPCIS Capture Interface benyttes til at opsamle hændelser fra sporingssystemer. Snitfladen består af en enkelt operation Capture som overfører en liste af sporingshændelser og ikke returnerer noget svar. Disse hændelser er defineret som ovenfor med følgende ændringer: Business step er ikke obligatorisk og behøver ikke benytte samme værdier som defineret ovenfor. Det er Integrationssystemets opgave at fortolke betydningen af en hændelse, herunder oversætte mellem business steps, hvis nødvendigt. Business Location kan være defineret som ovenfor eller være en URN som på anden måde specificerer en lokalitet. Formatet for sidstnævnte kan være koordinater, alternative navne eller lignende som Integrationssystemet via information i Lokalitetsdatabasen kan oversætte til lokalitets-id er. Se næste afsnit, Afsnit Read Point er tilladt. Det er op til Integrationssystemet at oversætte denne til Business Location når hændelser sendes videre til anvendelsessystemerne. EPCIS Capture Interface tilgås via XML over HTTPS eller HTTP. Sporingssystemet skal sikre at alle hændelser bliver modtaget korrekt af Integrationssystemet, ved at gensende hændelser for hvilke der ikke er modtaget kvittering jfr. EPCIS Capture Interface. Dette gælder også ikke-kritiske hændelser. Det skal eksplicit dokumenteres hvilken grad af filtrering der foretages af sporingssystemet. Selvom den generiske snitflade til opsamling af hændelsesdata er EPCIS Capture Interface, er det stadig muligt at oprette fælles komponenter, i Integrationssystemet eller andetsteds, som modtager data via andre formater. Eksempelvis vil mange RIFDløsninger kunne levere data via LLRP-protokollen. Hvorvidt det kan betale sig at etablere en fælles snitflade til opsamling af eksempelvis LLRP-hændelser afhænger af de konkrete sporingsløsninger Snitflade til Lokalitetsdatabasen Lokalitetsdatabasen indeholder alle lokaliteter som har interesse, dvs. også lokaliteter uden for organisationen. Disse data udstilles via Lokalitetsservicen, hvor selve snitfladen kaldes LocalityService. Denne snitflade skal bruges til flere formål: Side 65

66 1. Integrationssystemet skal udstille lokaliteter og deres attributter via EPCISsnitfladen til anvendelsessystemer(en obligatorisk del af EPCIS-standarden). 2. Integrationssystemet, og muligvis andre systemer, skal kunne slå lokaliteter op baseret på koordinater, evt. i flere koordinatsystemer. 3. Sporingssystemer skal kunne læse lokaliteter og evt. deres koordinater og andre attributter. 4. Brugerfladen til at vedligeholde lokaliteter skal kunne vise, tilføje, slette og opdatere alle lokalitetsdata. Til de to første punkter ville det være tilstrækkeligt blot at udstille databasens indhold via EPCIS-snitfladen. Men de to sidste punkter kan ikke realiseres vha. EPCIS, som kun giver adgang til meget simple forespørgsler på metadata. Derfor, og fordi denne service sandsynligvis vil blive udvidet med nye formål i fremtiden, defineres en samlet, proprietær service som dækker alle fire punkter. Denne service kan udstilles som XML via HTTP eller HTTPS. Hvis Lokalitetsdatabase og -service købes som et produkt kan en SOAP-snitflade også anvendes. Den præcise etablering af denne snitflade foretages i forbindelse med etablering af Integrationssystemet Snitflade til Identitetsdatabasen Identitetsdatabasen indeholder sammenhængen mellem PID og GID samt eventuelle ekstra informationer som gør det muligt at søge i og oversætte mellem disse. Denne snitflade skal bruges til flere formål: 1. Integrationssystemet skal kunne validere indkommende PID er (dvs. EPC er) 2. Integrationssystemet skal kunne identificere typen af en PID (Patient, Seng, Personale, mv.) Dels til systemets interne logik, dels fordi EPCIS-standarden kræver at disse udstilles til anvendelsessystemer. (EPCClass) 3. Anvendelsessystemer skal kunne oversætte mellem PID og GID, og vice versa. 4. Brugerfladen til at vedligeholde identitetssammenhænge skal kunne vise, tilføje, slette og opdatere alle identitetsdata. Ligesom for Lokalitetsdatabasen, kan alle disse (1, 2 og 4) ikke realiseres via EPCISsnitfladen, og en separat, proprietær service etableres derfor. Denne service udstilles også som XML via HTTPS eller SOAP via HTTPS. Den præcise etablering af denne snitflade foretages i forbindelse med etablering af Integrationssystemet. 6.3 Miljø Der er ikke faste krav til afviklingsmiljøet, så længe det er i stand til at honorere de svartidskrav og oppetidskrav, der er stillet. Der er dog nogle egenskaber ved miljøet, der kan forudses: Side 66

67 Integrationssystemet skal afvikles på et cluster af servere for at kunne sikre tilstrækkelig oppetid. Forskellige leverandører af RFID integrationsløsninger har forskellige strategier; Nogle kører hele løsningen i et cluster. Andre kører kun eventmodtagelsen i et cluster, mens services til forespørgsler mv. køres på parallelle maskiner, der ikke er i cluster. Der bliver brug for en central databaseserver med et SAN til at gemme historiske data, log-data og data fra diverse anvendelsessystemer. Der bliver brug for et parallelt miljø, der ligner afviklingsmiljøet til test og prototype-projekter. Der er meget stor forskel på, hvad man må forvente af kapacitetskrav på kort og lang sigt. Skaleringsmulighederne skal derfor overvejes nøje. 6.4 Sikkerhed På Figur 10ses de væsentligste kommunikationskanaler arkitekturen samt hvorledes de sikres. Figur 10: Sikring af kommunikationen mellem de forskellige komponenter i løsningen Autentificering og autorisation Følgende principper anvendes til autentificering og autorisation i Referencearkitekturen: Brugernes adgang til anvendelsessystemerne er personlig, dvs. de skal autentificeres (f.eks. med login) inden brug og de har rettigheder der kan variere pr bruger. Forbindelsen vil typisk være HTTP eller HTTPS, hvis der er brug for kryptering at datatrafikken. Administratorer behandles i princippet lige som almindelige brugere, men de har typisk mange flere rettigheder til at ændre på systemet, herunder ændre sikkerhedssystemets opsætning. Anvendelsessystemernes adgang til Integrationssystemet er applikationsspecifik, dvs. applikationerne skal autentificeres (f.eks. med et software-certifikat) inden brug og de Side 67

68 har rettigheder der kan variere per applikation. Al adgang til Integrationssystemet bør logges, som ekstra sikring mod uberettiget adgang. EPCIS-standarderne definerer hvorledes enten SOAP over HTTP eller EPCIS-XML over AS2 kan benyttes til Query-snitfladen. Query Callback Interfacet (push) defineres baseret på EPCIS-XML over HTTP eller HTTPS. AS2-standarden, som er baseret på HTTP og S/MIME, er aktuelt ikke særligt udbredt. Den kan anvendes, men vil ofte være et uhensigtsmæssigt valg. Til sikring af kommunikationen er disse to muligheder derfor de anbefalede: Forespørgsler stilles via SOAP over HTTP, dvs. ukrypteret. Call-back-interfacet bruges til at modtages krypterede resultater via HTTPS. Dvs. der anvendes kun Push. Forespørgsler stilles via SOAP over HTTPS. Dette er en tilladt udvidelse af EPCISstandarden, men det er dog ikke et krav til Integrationssystemet at dette skal være muligt. Sporingssystemernes adgang til Integrationssystemet er i princippet lige som anvendelsessystemernes, men situationen er simplere, da de kun kan udføre én funktion, nemlig aflevere hændelser. Dermed er styring af rettigheder ikke særlig relevant i denne situation. Snitfladen er EPCIS-XML over HTTP eller HTTPS. HTTP benyttes kun hvis data ikke er følsomme eller hvis kommunikationen foregår via sikre net. Interfacet mellem sporingssystemer og ID-brikker er baseret på mange forskellige protokoller med forskellige egenskaber. I nogle tilfælde er rækkevidden så kort at kryptering ikke er nødvendig. Generelt bør dog anvendes id-brikker, der anvender sikre protokoller. Internt i Integrationssystemet er der ikke specificeret særlige sikkerhedsforhold. Kommunikation mellem integrationsservere og databaseservere forventes at foregå over sikrede net (dvs. net som brugere ikke har direkte adgang til). Databaserne må ikke være direkte tilgængelige for brugere Trusselsvurdering I dette afsnit kortlægges trusselsbilledet for den overordnede løsning som beskrives af Referencearkitekturen, og det beskrives hvordan hver trussel er adresseret. I sagens natur kan dette kun ske i overordnede termer, da konkrete sporingsteknologier og - produkter vil påvirke dette. Afsnittet her kan dog tjene som en ramme, hvori de konkrete trusler og trusselshåndteringer kan evalueres med henblik på at bidrage til kompletheden. Trusselsbilledet beskrives i form af mål for en eventuel angriber af løsningen og for hvert mål listes de metoder som angriberen kan anvende for at nå målet. For hver af disse beskrives hvorledes denne trussel bør adresseres. Mål: Få adgang til sporingsdata for identificerbare fysiske objekter [K:uautoriseretdataadgang] Metode: Stjæle id-brik Side 68

69 Håndtering: Fysisk beskyttelse mod tyveri. Spærring af id-brikker. Monitorering af unormal adfærd. Metode: Tilgå data mellem id-brik og læser. Håndtering: Princip om ikke at bruge meningsfulde id er (f.eks. CPR-numre) som PID. Kryptering af radiokommunikationen hvis data er følsomme. Metode: Tilgå data mellem læser og Integrationssystem. Håndtering: Princip om ikke at bruge meningsfulde id er som PID gør data begrænset anvendelige. Kryptering af kommunikationen vha. HTTPS hvis data er følsomme. Metode: Tilgå data mellem Integrationssystem og anvendelsessystem. Håndtering: Princip om ikke at bruge meningsfulde id er som PID gør data begrænset anvendelige. Kryptering af kommunikationen vha. HTTPS hvis data er følsomme. Anvendelsessystemet kan også forbindes til Integrationssystemet via et sikkert netværk. Metode: Tilgå data i Integrationssystemet. Håndtering: Servere placeres på et sikkert net. Adgang til databaser kun fra Integrationssystemet og udvalgte roller. Unormal adfærd kan monitoreres via logs. Metode: Tilgå data i Lokalitetsdatabasen. Håndtering: Adgangsbeskyttelse dels til Lokalitetsservice og dels til selve databasen. Unormal adfærd kan monitoreres via logs. Metode: Tilgå data i Identitetsdatabasen. Håndtering: Adgangsbeskyttelse dels til Identitetsservice og dels til selve databasen. Unormal adfærd kan monitoreres via logs. Mål: Sende uautoriserede sporingshændelser ind i systemet [K:uautoriserettilslutning] Metode: Aflæse signal fra id-brik, afspille signal igen (replay attack). Håndtering: Brug kryptering mellem id-brik og læser. Brug meget kortrækkende læsere. Brug en pin-kode eller lignende sammen med id-kortet. Mål: Ændre Lokalitetsdata [K:uautoriseret-tilslutning] Metode: Tilgå Lokalitetsservice eller Lokalitetsdatabasen. Håndtering: Sikres med adgangskontrol. Mål: Ændre Identitetsdata [K:uautoriseret-tilslutning] Metode: Tilgå Identitetsservice eller Identitetsdatabasen. Håndtering: Sikres med adgangskontrol. Side 69

70 Mål: Forhindre at systemet virker [K:uautoriseret-funktionsstop] Metode: Oversvømme systemet med tilfældige data (denail-of-service-attack) med falsk id-brik. Håndtering: Kan modvirkes ved at lave filtre, der fjerner hurtige repetitioner. Lav overvågningsfunktioner der opdager usædvanlige brugsmønstre. Overvåg at der ikke kommer uventede nye sporingssystemer. 6.5 Svartider Der er brug for en del metadata (ID-mapninger, ID typer, lokaliteter og processer). Disse data er forventes ikke at blive mere omfattende end at de kan caches i serverne og derfor ikke udgør en performance-risiko. Diverse services der stilles til rådighed for anvendelsessystemerne kan indeholde søgninger i hændelsesdatabasen, som kan være performance-kritiske. Da hændelsesdatabasen i princippet er en endeløs lang liste af hændelser kan det være en udfordring at optimere søgninger til specielle formål. Det bliver vigtigt, at man, når man designer nye anvendelser, har adgang til databasen for at kunne indføre nye indekser, accelerator-tabeller og andre performance-initiativer. Der er tidskritiske og ikke tidskritiske scenarier. Langt de fleste anvendelser er ikke særligt tidskritiske, men enkelte er. På database-niveau er dette svært at gøre noget ved. Databasen kan ikke prioritere skrivninger og søgninger. I integrationsserveren kan man lave to indgangs-køer til aflevering af data og så altid tage de tidskritiske opgaver før de ikke tidskritiske. Dette øger dog kompleksiteten af løsningen og en sådan implementation skal derfor afvejes i forhold til indkøb af ekstra hardware. Den mest effektive adressering af de tidskritiske scenarier er at undersøge hvilke søgninger disse scenarier udfører og så i øvrigt monitorere performance således, at man kan gøre noget ved problemet, hvis det skulle opstå, og således at man kan identificere de situationer som skaber problemerne. Brugernes oplevelse af svartider er altid anvendelsesapplikationens svartid mens dette afsnit kun omhandler sporings-systemets svartid. Det kan være afgørende for succesfuld performance, at man er i stand til at måle anvendelsesapplikationernes performance og relatere det til sporingssystemets performance. 6.6 Skalering Alle services i integrationssystemet, både dem der realiserer capture og query interfacene skal være stateless. De afhænger altså kun af hvad der kommer ind af parametre og af hvad der ligger i databaserne. Dermed kan man forøge systemets kapacitet ved at tilføje flere servere til clusteret. Med det antal hændelser per sekund, der er estimeret forventes det ikke, at det vil være andet end processorkraft og databasekraft, der vil være begrænsende. Netværk og lignende vil ikke være en begrænsende faktor. Side 70

71 Da kommunikationen mellem hospitaler typisk vil foregå på et kraftigt netværk forventes dette ligeledes ikke være en begrænsende faktor i forhold til at skalere til en løsning, der dækker geografisk adskilte hospitaler. 6.7 Fleksibilitet Dette afsnit beskriver ændringsscenarier, f.eks. tilføjelse af nye delsystemer eller ændring af en snitflade, og hvorledes de håndteres. De driftsmæssige konsekvenser af forskellige ændringsscenarier er også beskrevet i Appendiks C. Det er intentionen at denne liste skal dække alle væsentlige ændringsscenarier. Ændringsscenarie Anvendelsessystem tilføjes Sporingssystem tilføjes Anvendelsessystem fjernes Sporingssystem fjernes Lokalitet tilføjes, fjernes eller ændres PID (id-brik) tilføjes PID (id-brik) fjernes PID flyttes til anden GID En snitflade udvides En snitflade ændres Håndtering Rettigheder tildeles. Ingen ændringer nødvendige i Integrationssystemet. Rettigheder tildeles. Kun ændring i integrationssystemet hvis logikken skal ændres, f.eks. pga. nye objekttyper. Rettigheder fjernes. Ingen ændringer nødvendige i Integrationssystemet. Rettigheder fjernes. Ingen ændringer nødvendige i Integrationssystemet. Evt. fjernes unødvendig logik. Lokalitetsdatabasen opdateres. Evt. sporingssystemer med cache af lokaliteter opdateres via Lokalitetsservice. Det samme gør anvendelsessystemer via EPCIS-snitfladen (efter behov). Identitetsdatabasen opdateres med relation til GID (på et tidspunkt). Identitetsdatabasen opdateres. Hvis hændelser modtages af Integrationssystemet med denne PID ignoreres de og fejlen rapporteres. Identitetsdatabasen opdateres. Anvendelsessystemer benytter den gamle værdi indtil nyeste data hentes fra Identitetsdatabasen. Nye brugere kan anvende den nye funktionalitet. Nye og gamle brugere kan anvende den gamle funktionalitet. Den nye snitflade udstilles på ny URI. Den gamle kører videre indtil ingen længere bruger den. Side 71

72 Side 72

73 7 Konklusion Grundlaget for Referencearkitektur for Sporbarhed og Emneidentifikation er en række krav og forventninger opstillet i samarbejde med en række aktører i Region Midtjylland: it-ledelse og personale på udvalgte hospitaler, regionens it-arkitekturfunktion og projektafdelingen for Det Nye Universitetshospital i Aarhus. Referencearkitekturen er designet således at alle disse krav kan opfyldes. De væsentligste elementer i dette kravbillede er: Et katalog af mulige fremtidige sporingsprojekter som arkitekturen skal understøtte, eksempelvis Lokalisering af udstyr, (Afsnit 3.1) Et katalog af sporingsteknologier som arkitekturen skal understøtte, eksempelvis RFID og stregkoder, (Afsnit 4) En liste af øvrige krav til løsningen, eksempelvis krav til svartider og stabilitet. (Afsnit ) Selve Referencearkitekturen (Afsnit 5-6) beskriver en separation af sporingssystemer, dvs. systemer som producerer sporingsdata, og anvendelsessystemer, dvs. systemer som konsumerer disse data. Disse systemer separeres ved at introducere et centralt system som alle sporingsdata går igennem, kaldet Integrationssystem til Sporing og Identifikation (ISSI). Herved opnås en ensartet og simplere adgang til sporingsdata og redundante integrationer mellem systemer undgås. De vigtigste anbefalinger i Referencearkitekturen er opstillet i form af en række arkitekturprincipper. De vigtigste af disse er følgende: Integrationssystemet baseres på EPCIS-standarden fra EPCGlobal, som er den mest udbredte standard til udveksling af RFID-data, men også kan anvendes til at formidle data fra andre sporingsteknologier. Anvendelsen af en udbredt standard betyder at det vil være lettere og billigere at integrere sporingsrelaterede systemer i fremtiden. Udover Integrationssystemet beskrives også nogle nye centraliserede databaser, hvoraf den vigtigste er Lokalitetsdatabasen, som indeholder alt data om steder der er relevante i forbindelse med sporing, dvs. alle relevante lokaler, udendørsarealer, opsamlingspunkter, eksterne leverandørfaciliteter, osv. Denne database er ikke blot til brug for Integrationssystemet, men kan også anvendes af andre systemer, som skal benytte data om steder. Fundamentet for en langtidsholdbar og sund løsning er løbende styring af udviklingen. Derfor anbefales det udpege en styregruppe, som er ansvarlige for at den videre udvikling af løsningen sker i henhold til Referencearkitekturen. De forvaltningsmæssige opgaver en vigtig del af større it-projekter. Som supplement til selve arkitekturen er derfor beskrevet de generelle administrative opgaver, der findes i relation til fremtidige projekter baseret på Referencearkitekturen. (Appendiks C) Referencearkitekturen beskriver således de fælles begreber, it-systemer og processer som er en forudsætning for at opnå en langsigtet, effektiv og økonomisk anvendelse af teknologier til sporbarhed og emneidentifikation. Side 73

74 Side 74

75 Appendiks A. Implementering i Region Midtjylland A.1 Regionsspecifikke krav A.1.1 Eksisterende systemer Her beskrives krav der relaterer sig til de systemer som allerede findes på hospitalet og i regionen. K:sameksistens Referencearkitekturen må ikke stille krav om ændring af eksisterende sporingsløsninger. Arkitekturen skal kunne sameksistere med disse. Der er en række etablerede systemer som eksempelvis anvender stregkoder. At ændre eller udskifte disse er ikke realistisk, men det bør overvejes for hvert enkelt system, eksempelvis i forbindelse med opgradering af systemet eller hvis der viser sig et behov for bredere anvendelse af de data der opsamles af systemet. K:wifi-kompatibilitet Referencearkitekturen bør være kompatibel med den eksisterende Wi-Fi-løsning i Region Midtjylland Infrastrukturen er etableret og indeholder positioneringsfunktionalitet. A.1.2 Skaleringskrav for Det Nye Universitetshospital i Aarhus For at kunne dimensionere løsningen er det centrale spørgsmål hvor mange enheder, der skal spores og hvor ofte hver enhed identificeres af en læser. Disse tal kan ikke med sikkerhed kendes på forhånd og nedenstående tal er derfor baseret på skøn, som skal vejlede dimensioneringen af systemet. Bemærk at nedenstående estimater alene dækker Det Nye Universitetshospital i Aarhus. De estimerede værdier bør løbende revurderes og sammenholdes med den aktuelle kapacitet ved større ændringer i antallet af enheder eller deres aflæsningsfrekvens. K:antal-objekter Antallet af objekter som skal spores i løbet af et døgn vil maksimalt være Omkring 2500 ansatte. Baseret på estimat af at ca ansatte er på arbejde samtidigt og ca. 50% af disse indgår i processer der spores. Omkring 3000 patienter. Dette tal kommer af antallet af normerede senge x belægningsprocenten + 50% af de ambulante besøg pr dag. Omkring 200 besøgende. Dette tal kommer fra et gæt på 1000 samtidige besøgende hvoraf 20% spores. Omkring stykker mobilt inventar/udstyr. Primært senge, vogne, it-udstyr og medikoteknisk udstyr. Omkring 7500 hjælpemidler. Baseret på estimeret hjælpemidler hvoraf 10% har relevans for sporbarhed på en given dag. Side 75

76 Omkring 200 varer der transporteres per dag. En del af disse vil efterfølgende blive registreret mens de ikke transporteres. Forventet 10% af det samlede antal varer per år, svarende til 7500 varer. Langt de fleste varer forventes således kun at blive sporet i de vogne og beholdere som de transporteres i. K:antal-hændelser Det maksimale antal hændelser (busy hour) er ca. 40 per sekund. Heraf er 9 tidskritiske. Nedenstående summerer beregningsgrundlaget for kravet[k:antal-hændelser]. Objekttype Antal Sporingsprocent Timer/døgn Ansatte på job % 8 Patienter % 8 Besøgende % 1 Udstyr % 24 Hjælpemidler % 24 Varer lager % 1 Varer transport % 24 Antal er det totale antal, dog er varer og udstyr kun den andel der spores. Sporingsprocent er den andel af Antal der faktisk spores. Timer/døgn er det antal timer per døgn som emnet spores. Tidskritisk, med garanti Antal/time Peak Antal/time Gennemsnit Antal/sekund Peak Antal/uge Gennemsnit Ansatte på job 2 1 1, Patienter 2 1 1, Besøgende 1 1 0, Udstyr 0,1 0,1 0, Hjælpemidler 0,1 0,1 0, Varer lager Varer transport 2 1 0, Total 7,2 4,2 3, Side 76

77 Ikke-tidskritisk, med garanti Antal/time Peak Antal/time Gennemsnit Antal/sekund Peak Antal/uge Gennemsnit Ansatte på job Patienter Besøgende Udstyr Hjælpemidler Varer lager 0,1 1 0, Varer transport Total 0,1 1 0, Ikke-tidskritisk, uden garanti Antal/time Antal/time Antal/sekund Antal/uge Peak Gennemsnit Peak Gennemsnit Ansatte på job , Patienter , Besøgende , Udstyr , Hjælpemidler , Varer lager Varer transport Total , Antal/time Peak er det antal hændelser der maksimalt måles i de timer hvor der måles. Antal/time Gennemsnit er det antal hændelser, der normalt måles i de timer hvor der måles, midlet over en lang periode således at tallet kan ganges op til uger eller år. Antal/sekund Peak er Antal/time Peak x Antal x Sporingsprocent / 3600 Antal/sekund Gennemsnit er Antal/time Gennemsnit x Antal x Sporingsprocent x Timer/døgn x 7 Tilsammen giver det i størrelsesordenen 16 mio hændelser om ugen. Det svarer til ca. 25 transaktioner pr sek i middel og 50 transaktioner per sekund i peak. Med et estimat på 3 kb data pr hændelse giver det en belastning af netværk og servere på ca. 75 kb/s i middel og 150 kb/s i peak, hvilket ikke er noget der giver grund til bekymring for netværket og databaseservere. Det samlede databasebehov kan da estimeres til i størrelsesordenen 45 GB per uge. Hertil kommer data til logfiler, performancestatistik etc. Hvor længe man ønsker at gemme data er åbent, men de fleste data forældes ret hurtigt. Side 77

78 A.2 Regionsspecifikke arkitekturvalg A.2.1 Allerede etablerede sporingsløsninger Eksisterende integrationer mellem sporingssystemer og anvendelsessystemer skal ikke ændres som konsekvens af Referencearkitekturen. A.2.2 Stregkoder, RFID og Wi-Fi Baseret på de identificerede krav og brugsscenarier er der behov for en eller flere sporingsløsninger som dækker følgende: Løbende positionering overalt på hospitalet, herunder positionering af patienters egne enheder, samt sporing af et potentielt stort antal objekter som beskrevet i afsnit A.1.2. Identifikation Signalering Opsamling af sensordata. Af hensyn til omkostninger til drift og udvikling/vedligehold af integrationer anbefales det at holde sig til så få sporingsløsninger og teknologier som muligt. I det følgende anbefales tre teknologier som forventes at dække disse punkter. Disse teknologier forventes således at kunne understøtte alle de forventede anvendelser. I forbindelse med indkøb af konkrete produkter (id-brikker, læsere og software) skal disse dog afprøves i praksis, for at se om de kan levere den nødvendige præcision, stabilitet, hastighed, sikkerhed og brugervenlighed til at understøtte de valgte scenarier. Andre teknologier end de anbefalede kan blive relevante i fremtiden, eksempelvis ved ønske om bestemte sensorer eller it-systemer, ligesom den teknologiske udvikling kan ændre forudsætningerne for valget. P:rfid Passiv RFID anvendes til identificering af objekter, til positionsbestemmelse på udvalgte steder, og til registrering af sensordata. Passiv RFID vælges af følgende årsager: Passiv RFID kan benyttes til at spore et meget stort antal objekter da RFID-brikker er markant billigere end mere avancerede teknologier, eksempelvis aktiv RFID. Passiv RFID vil blive vidt udbredt efterhånden som flere og flere producenter erstatter eller supplerer stregkoder med passiv RFID. Mange mobiltelefoner vil indeholde passiv RFID-læsere og -sendere. På Skejby Sygehus anvendes allerede id-kort baseret på passiv RFID-teknologi. Passiv RFID er billigere at købe og administrere end aktiv RFID. Passiv RFID giver tilstrækkelig rækkevidde til en række formål som for eksempel optælling af varer i skabe, vogne, på paller o.l. eller til at afgøre om noget bevæger sig ind og ud af et lokale. Side 78

79 Passiv RFID kan også være tilstrækkelig kortrækkende til at erstatte stregkoder i mange sammenhænge. For passiv RFID anbefales UHF af typen EPC GEN2, da de tilbyder den bedste rækkevidde og fleksibilitet. Denne bør suppleres af ISO/IEC som benyttes i både idkort og mobiltelefoner (NFC). P:stregkoder Stregkoder anvendes til identificering af objekter. Stregkoder er allerede vidt udbredt på hospitaler i Region Midtjylland og vil fortsat have mange anvendelser i Region Midtjylland. Fremtidige anvendelser bør dog som hovedregel gå via Integrationssystemet, jfr. [P:indirekte-adgang]. P:wifi Wi-Fi-positionering anvendes til løbende positionsbestemmelse af objekter, signalering og opsamling af sensordata. Det eksisterende Wi-Fi-netværk på bl.a. Aarhus Universitetshospital Skejby er indkøbt blandt andet med henblik på positionering og Wi-Fi-sporing videreføres i Region Midtjylland, jfr. [K:wifi-kompatibilitet]. Desuden kan Wi-Fi som den eneste teknologi opfylde behovet for indendørs positionering af patienters egne digitale enheder. Wi-Fipositionering er en moden teknologi som forventes at levere den stabilitet og præcision, der skal til for at opfylde krav og brugsscenarier. Side 79

80 Side 80

81 Appendiks B. Sporingsteknologier og standarder Dette afsnit beskriver udbredte teknologier og standarder til sporing og identifikation. B.1 Stregkoder En stregkode er en visuel repræsentation af data, som kan læses maskinelt. Stregkoder findes i en række forskellige udformninger, kaldet symbologier: traditionelle lineære stregkoder, som består af en række streger af forskellig tykkelse og evt. forskellig afstand, og 2D-stregkoder, som typisk er et rundt eller rektangulært mønster. Mængden af data der kan repræsenteres er afhængig af stregkodens type og størrelse, men ligger typisk mellem 10 bytes og nogle få kilobytes. Nogle stregkoder standardiserer indholdet, dvs. hvad dataene betyder, og nogle gør ikke, mens andre standardiserer en del af dataene og efterlader plads til valgfrie informationer. Stregkodelæsere findes i en række udformninger, men de mest benyttede er laserskannere og kamerabaserede læsere. Laserskannere sender en lysstråle henover stregkoden og aflæser refleksionen fra denne, hvilket kan gøres på afstande op til ca. 1 meter. Kamerabaserede læsere tager et billede af stregkoden og analyserer dette. Afstanden hvormed dette kan gøres afhænger af stregkodens størrelse og kameraets kvalitet. Mange moderne mobiltelefoner kan aflæse stregkoder vha. det indbyggede kamera. 2D-stregkoder kan normalt kun læses af kamerabaserede læsere. Stregkoder indeholder ofte kun en identifikation af producenten og det konkrete objekt, f.eks. en varetype. For at kunne bruge stregkoden til noget, er man ofte nødt til at have yderligere informationer om det objekt der skannes. Det kan for eksempel være en papirliste eller database med varenumre og yderligere informationer om varerne. Udvekslingen af disse supplerende oplysninger er således en vigtig del af den samlede proces. Det koster ned til ca. 30 øre at påføre og administrere en stregkode. Der findes en lang række organisationer, som standardiserer stregkoder til forskellige formål. De vigtigste internationale standarder er beskrevet i det følgende. Kilder: [makebarcode], [gs1]. B.1.1 GS1 GS1 er en international, nonprofit-organisation der udvikler standarder som understøtter udveksling af varer på tværs af landegrænser og sektorer. Sundhedssektoren er et af organisationens fokusområder og disse standarder benyttes af sundhedsorganisationer i en lang række lande. GS1 har en række standarder af relevans for sporbarhed og emneidentifikation i sundhedssektoren. Nogle af de vigtigste er: Global Traceability Standard for Healthcare: Beskriver den overordnede proces der skal anvendes for at sikre global sporbarhed af produkter indenfor sundhedsområdet. Side 81

82 Global Data Synchronisation Network: Definerer hvordan produktdata kan synkroniseres mellem samhandelspartnere. Netværket bygger på et centralt register og et antal decentrale databaser. Global Trade Item Number (GTIN): Definerer hvordan produkter kan tildeles unikke ID er, således at produkterne kan spores igennem hele deres livscyklus. Global Location Number (GLN): Definerer hvordan geografiske steder og organisationer kan tildeles unikke ID er. GS1-stregkoder: Definerer en række stregkodeformater til forskellige formål, bl.a. EAN-13, GS1-128 og GS1 Datamatrix. Indeholder typisk en GTIN og evt. yderligere informationer. Pedigree Standard: Definerer hvordan oplysninger om sundhedsprodukters historiske livsforløb udveksles. GS1 har desuden udarbejdet en vejledning til sporbarhed og emneidentifikation i sundhedssektoren som beskriver hvordan forskellige teknologier som RFID og stregkoder bør anvendes. [AIDC, 2010] For flere detaljer, se [GS1 HCS, 2011], [GS1 HCR, 2011]. B.1.2 Health Industry Business Communications Council HIBCC er en international, nonprofit-organisation som standardiserer information til sporing af varer og andre objekter indenfor sundhedssektoren. Disse kan repræsenteres som stregkoder eller vha. RFID. Selve stregkodesymbologien og RFID-aflæsningen defineres dog ikke, i stedet henvises til eksisterende ISO og GS1 standarder. Det centrale koncept i HIBCC er et Health Industry Number (HIN) som kan bruges til global identifikation af en række materielle og immaterielle enheder, såsom varer, patienter, prøver, personale, procedurer, udstyr, steder og dokumenter. HIBCC definerer også standarder for egentlig E-business eller EDI. For mere information, se [HIBCC, 2011]. B.2 RFID Radio Frequency Identification, RFID, er en teknologi til automatisk identifikation af ting eller personer ved hjælp af radiosignaler. Identifikationen sker principielt på samme måde som ved stregkoder; en RFID-brik som er monteret på tingen/personen indeholder et id-nummer en RFID-læser aflæser denne id. Der skelnes normal mellem to typer at RFID: passiv og aktiv RFID. Ved passiv RFID har RFID-brikken ikke noget batteri, men fungerer ved at RFIDlæseren sender et signal til brikken, som denne reflekterer tilbage til RFID-læseren med en lille ændring i signalet der gør det muligt at identificere brikken. Ved aktiv RFID har RFID-brikken et batteri og kan derfor selv sende signaler til RFID-læsere. Passive brikker er typisk meget små, på størrelse med en stregkode. Rækkevidden er normalt kun nogle få meter, men går helt op til flere hundrede meter. Rækkevidden af aktive tags afhænger af sendestyrken som primært begrænses af batteriets størrelse Side 82

83 og levetid. Passive brikker kan købes fra under 50 øre, aktive fra ca. 100 kr. per styk [BuyRFID, 2011]. RFID bruger en række forskellige frekvensområder, men de typiske er LF (ca. 125 khz), HF (13,56 MHz) og UHF ( MHz). Generelt har de lavere frekvenser kortere rækkevidde og bedre gennemtrængningsevne end højere frekvenser. Der findes læsere som kan aflæse RFID-brikker ved flere forskellige frekvensområder. Nogle RFID-brikker kan udsende data op til et par kilobytes, og disse kan kombineres med sensorer som aflæser eksempelvis temperatur eller luftfugtighed. RFID-brikken får i to typer: brikker hvor data kun kan skrives en gang (read-only), eller brikker hvor data kan skrives flere gange (read-write). Near Field Communication (NFC) er kombinationen af en RFID-brik og en RFID-læser i samme enhed, typisk en mobiltelefon. NFC er understøttet i en række nyere mobiltelefoner og smartphones. Eksempler på produkter: PureLink, Mojix, WhereNet, Versustech, SpotON, LANDMARC B.2.1 EPCGlobal EPCglobal Inc er en nonprofit-organisation under GS1 (se ovenfor), som udvikler et bredt spektrum af RFID-relaterede standarder. Disse standarder dækker selve den trådløse aflæsning af RFID-brikker, videreformidling og opbevaring af disse læsninger, samt administration af RFID-læsere og brikker. EPCGlobal-standarderne er uafhængige af valget af teknisk platform og er til dels uafhængige af forretningsområdet. Hvor standarderne berører egentlige forretningsprocesser er dette dog rettet mod traditionelle logistikprocesser mellem virksomheder, eksempelvis afsendelse og modtagelse af varer. Hospitalsprocesser er ikke direkte dækket, men standarderne åbner op for udvidelser på disse punkter. Det centrale element i standarderne er Electronic Product Code, EPC, som er en globalt unik ID, der kan tildeles til produkter, beholdere, personer og andre objekter som typisk bærer en RFID-brik. Denne navngivning følger samme principper som den måde domænenavne tildeles på Internettet (DNS). EPC-koder er kompatible med en række andre ID-standarder og vil ofte indeholde eventuelle eksisterende ID er således at der ikke skal vedligeholdes flere koder. Der er en veldefineret sammenhæng mellem EPC er og ID er defineret af GS1. Udover EPC giver standarderne mulighed for globalt at identificere de fysiske steder og hændelser der svarer til aflæsning af et eller flere RFID-brikker. Steder kan eksempelvis være koordinater eller lokalenavne mens hændelser kan være vare blev modtaget eller patient gik ind i lokale. På Figur 11 er vist de vigtigste snitflader der defineres af EPCGlobal-standarderne, samt de systemkomponenter som kommunikerer ved hjælp af disse. Hver af snitfladerne kan bruges alene og forudsætter således ikke anvendelse af de øvrige snitflader. Tag Air Interface beskriver den trådløse kommunikation mellem RFID-brik og RFID-læser. Brikker der er indenfor rækkevidde kan aflæses. Desuden kan der sendes kommandoer til en eller flere brikker, eksempelvis tildeling af EPC eller Side 83

84 slukning af brikken. Aktuelt understøttes kun kommunikation via UHF, men en standard for HF er på vej. Reader Interface, også kaldet Low Level Reader Protocol, benyttes af RFIDlæseren til at videresende de rå brik-aflæsninger til den software-komponent, der er ansvarlig for at filtrere og aggregere det typisk store antal læsninger som foretages. Hændelser på dette niveau er på formen Læser L så brik B klokken K. Desuden giver dette interface mulighed for at skrive til RFID-brikker samt konfigurere en række parametre der kontrollerer radiokommunikationen. Filtering & Collection Interface, også kaldet Application Level Events (ALE) abstraherer, i modsætning til Reader Interface, de radiospecifikke detaljer såsom frekvensvalg og timing, væk. Hændelser på dette niveau er af typen På lokation L observeredes brikkerne B1, B2 og B3 mellem klokken K1 og K2. Dette interface tillader desuden specifikation af hvordan mængden af hændelser begrænses, for eksempel ved filtrering. Capture Interface er en del af EPC Information System (EPCIS)-specifikationen og giver hændelser på et højere abstraktionsniveau, efter formen Hvad, hvor, hvornår og hvorfor, eksempelvis Person P modtog varen V i lokale L klokken K som en del af ordren O. Query Interface er også en del af EPCIS og er tiltænkt som den primære snitflade der stilles til rådighed for slutbrugerapplikationer og andre organisationer. EP- CIS er dog ikke en erstatning for egentlig EDI-standarder, såsom EDIFACT eller OAGIS, men er tænkt som supplement til disse. Udover disse indeholder EPCGlobal også standarder til administration af RFID-læsere og brikker, udveksling af metadata, etc. Side 84

85 Slutbrugersystem Handelspartner Query Interface Hændelsesdatabase Slutbrugersystem Capture Interface Opsamlingskomponent Filtering & Collection Interface Filtreringskomponent Filtreringskomponent Anden datakilde Reader Interface Læser Læser Læser Tag Air Interface Id-brik Id-brik Id-brik Id-brik Id-brik Id-brik Figur 11: Oversigt over de vigtigste EPCGlobal-standarder, samt de komponenter og systemer som typisk benytter disse. For flere detaljer, se [EPCGlobal, 2011]. B.2.2 ISO/IEC Denne standard definerer en konkret anvendelse af passiv RFID til brug i trådløse IDkort. Rækkevidden er op til ca. 10 cm. Standarden anvendes blandt andet i mange adgangskort og biometriske pas. B.2.3 ISO/IEC Svarer til ISO 14443, blot med en længere rækkevidde på op til et par meter. B.2.4 ECMA 340/352 Disse standarder, også betegnet som Near Field Communication (NFC), beskriver kombinationen af både RFID-læser og brik i en enhed, som for eksempel en mobiltelefon. Side 85

86 Standarden er en enkel udvidelse af ISO/IEC 14443, og er også kompatibel med ISO/IEC En række mobiltelefoner understøtter i dag NFC og det forventes at næste versioner af Android og iphone også vil have NFC-understøttelse [NFC-phones, 2011]. B.2.5 ISO/IEC Denne standard specificerer en række protokoller til trådløs kommunikation mellem RFID-brikker og læsere i forskellige frekvensområder. EPCGlobals nyeste standard for UHF-brikker er inddraget ved udformningen af ISO C, hvilket betyder at de to standarder er kompatible. B.3 Wi-Fi Wi-Fi er den absolut mest udbredte teknologi til trådløse netværk (normalt 2.4 GHz). Wi-Fi bruges ofte synonymt med IEEE standarderne, hvor de mest brugte er b, g eller n. Varemærket Wi-Fi kan dog teknisk set kun benyttes af enheder som er certificeret af Wi-Fi Alliance. Wi-Fi enheder kan positionsbestemmes ved at måle bl.a. sendestyrken fra den mobile enhed til et antal opstillede antenner. For at opnå en god præcision kræves dels et antal antenner indenfor enhedens rækkevidde og dels at positionsbestemmelsen kalibreres. Kalibreringen foretages ved at en Wi-Fi-enhed placeres på et antal steder, f.eks. i alle lokaler, hvor enhedens faktiske position udpeges manuelt i systemet. Denne fuldstændige kalibrering foretages kun en gang og efterfølgende kan suppleres med yderligere kalibrering på steder hvor positioneringen ikke er tilstrækkelig god. Det kan være nødvendigt at kalibrere på forskellige tidspunkter af dagen, f.eks. både når lokalerne er fyldt med mennesker og når de er tomme. For at kunne positionsbestemme kræves kontakt til mindst 3 antenner, og i praksis nogle flere. Eksisterende Wi-Fi-netværk kan nogle gange benyttes men Wi-Fiinfrastrukturer opstillet alene til datakommunikation er ikke altid tilstrækkelige til at opnå en acceptabel præcision [Assetmgt, 2010]. Wi-Fi-brikker bruger mere strøm en de fleste andre radioteknologier, da sendestyrken er relativt høj. Wi-Fi-leverandører hævder at positionering vha. Wi-Fi kun kræver begrænset båndbredde, så den almindelige datatrafik på det trådløse netværk ikke påvirkes væsentligt. [Ekahau, 2009] Eksempler på produkter: Ekahau, Trapeze, AeroScout, Zebra Technologies, InnerWireless, AirMagnet, CISCO WLSE B.3.1 ISO/IEC ISO/IEC definerer dels en snitflade som applikationer kan benytte til at tilgå et RTLS-system og dels et antal radioprotokoller i 2.4 GHz-området. Standarden har ringe udbredelse blandt de store leverandører, men benyttes dog af bl.a. Zebra Technologies. Side 86

87 For mere information, se [ISO24730, 2011] B.4 UWB Ultra-Wideband (UWB) er en trådløs radioteknologi som sender i et bredt spektrum (i Danmark mellem 6 og 8,5 GHz). Fordelen ved dette frem for den gængse smalspektrede kommunikation er lavere sendestyrke og dermed mindre forstyrrelse af andre systemer, bedre modstand overfor forstyrrende signaler, og gode muligheder for afstandsbedømmelse. Rækkevidden af UWB er ofte kort, op til 10 meter, mens båndbredden kan være op til 480 MBit (over 3 meter). UWB benyttes bl.a. til RFID og er således delvist overlappende med denne teknologi. Indenfor sundhedsområdet er der en række anvendelser, bl.a. til overførsel af billeder og sensordata. [medical-uwb, 2008] UWB benyttes også i Wireless USB. [wusb, 2011] Eksempler på produkter: Ubisense B.5 GPS Global Positioning System (GPS) er en udbredt, stabil og billig teknologi til positionering. Som udgangspunkt giver en nøjagtighed på ca meter, men da den er afhængig af satellitsignaler kan teknologien normalt kun anvendes udendørs. Teknologier som Assisted GPS (AGPS) og Differential GPS (DGPS) kan anvendes til at opnå bedre præcision og hurtigere positionsbestemmelse. [GPS Accuracy, 2011] Forsøg med indendørs positionering vha. GPS viser at det kun er praktisk anvendeligt i visse typer bygninger. [Kjærgaard et al, 2010] Galileo-projektet er et europæisk alternativ til GPS og har bl.a. til formål at forbedre mulighederne for indendørs positionering og undgå kontrol fra USA's militær. Projektet forventes at være operativt anvendeligt i [ESA, 2011] B.6 Sensornetværk Trådløse sensornetværk (Wireless Sensor Network, WSN) består af en række enheder der kommunikerer indbyrdes vha. radiobølger. Netværkstrukturen kan variere, men fungerer ofte efter mesh-principper, hvor hver enhed ikke blot har ansvar for at sende egne data, men også at videresende data fra andre enheder i nærheden. Dette giver et meget robust netværk. B.6.1 ZigBee / IEEE ZigBee er en standard for trådløs kommunikation (oftest 2.4 GHz) efter bl.a. meshprincipper. ZigBee defineres af ZigBee Alliance som er et consortium bestående af en lang række større og mindre firmaer. Standarden bygger oven på IEEE , som definerer de mere hardware-nære kommunikationslag. ZigBee har, afhængigt af den konkrete konfiguration, en rækkevidde fra 10 til 1500 meter og en batterilevetid fra få måneder til adskillige år. Et ZigBee-netværk består af tre type enheder: Side 87

88 En ZigBee Coordinator, som opbevarer informationer om nettets tilstand og skaber forbindelse til andre netværk Et antal ZigBee Routers, som kan både sende egen information og videresende informationer fra andre Et antal ZigBee End Devices, som kan sende information men ikke videresende fra andre. Positionering af ZigBee-enheder forgår eksempelvis ved at måle sendestyrken fra andre enheder. ZigBee Health Care er en specification af, hvordan ZigBee kan anvendes i sundhedssektoren. Specifikationen dækker en række sensorer til detektion af bl.a. temperatur, gas, bevægelse, fald og personlig alarm. Specifikationen pointerer at den udelukkende er beregnet til ikke-kritiske formål. Eksempler på produkter: AwarePoint For flere detaljer, se [ZBHC, 2011]. B.6.2 Andre typer sensornetværk Der findes andre lignende WSN-standarder. For eksempel DASH7, som benytter en lavere frekvens end ZigBee (433 MHz) og er baseret på ISO/IEC Rækkevidden af DASH7 er op til et par km og strømforbruget er mindre end ved brug af ZigBee. Protokollen har indbygget positionering. B.7 DECT Digital Enhanced Cordless Telecommunications (DECT) er en standard til trådløs telefoni defineret af European Telecommunications Standards Institute (ETSI). I modsætning til mobiltelefoni har håndholdte DECT-enheder en kortere rækkevidde på meter indendørs. [InfraCom, 2011] Ekahau Inc. tilbyder deres positioneringsløsning på DECT-teknologi med en præcision der svarer til Wi-Fi. [Ekahau-DECT, 2010] DECT har en batterilevetid på ca. 15 timers tale. Sendestyrken er lavere end Wi-Fi og batterilevetiden er derfor længere. [ETSI, 2011] DECT kan også bruges til datatransport med en båndbredde på op til ca. 56 kbit. [RTX- DECT, 2011] Eksempler på leverandører: Polycom, Siemens, RTX, InfraCom B.8 GSM GSM (Global System for Mobile Communications) er den mest udbredte standard for mobiltelefoni. Ved positionsbestemmes vha. celleinformation opnås en præcision mellem ca. 200 meter i byområder og ca. 15 km i landområder. Ved brug af andre typer informationer Side 88

89 kan præcisionen øges men disse er ikke tilgængelige i Danmark. [Fredslund et al, 2010] B.9 Bluetooth Bluetooth er en trådløs netværksteknologi (2.4 GHz) beregnet til personlige netværk (Personal Area Network), dvs. netværk mellem de enheder som en person omgiver sig med, eksempelvis PC, mobiltelefon, headset, MP3-afspiller og trådløse højttalere. Bluetooth er baseret på IEEE og overførselsraten er op til ca. 1 Mbit mens rækkevidden typisk er op til meter. Bluetooth er understøttet af de fleste computere, mobiltelefoner og tilhørende udstyr. Der er også en række sensorer som understøtter Bluetooth. Hvert Bluetooth-enhed har et unikt id, som kan anvendes til at identificere bæreren af enheden. Etablering af kontakt mellem enheder kan tage 15 sekunder til 1 minut og kræver normalt indtastning af en kode. Af disse grunde er Bluetooth ikke særligt udbredt til dette formål. På grund af Bluetooth-enheders relativt høje strømforbrug, i forhold til eksempelvis ZigBee, benyttes Bluetooth primært i enheder med et vist størrelse batteri og ikke i små id-brikker. Bluetooth-signaler stoppes normalt af vægge og døre og Bluetooth er derfor mest velegnet til positionering på rumniveau. [BT, 2011] Eksempler på produkter: BlueLon, Zonith B.10 Infrarød Infrarød sporing fungerer ved at de emner, der skal spores, bærer id-brikker, som udsender infrarøde stråler. Disse modtages af et eller flere kameraer monteret i hvert lokale. Med flere kameraer kan den tredimensionelle positionering blive meget nøjagtig, ned til under en millimeter, og er derfor velegnet til måling af detaljerede kropsbevægelser og lignende. Infrarøde stråler blokeres ikke blot af vægge, men også af andre fysiske genstande som personer og stof. For kontinuert at positionsbestemme et objekt i et typisk lokale er der derfor brug for kameraer i flere retninger, for eksempel på alle fire vægge. Infrarøde id-brikker kan fås ned til samme størrelse som en mønt. Rækkevidden fra idbrik til modtager er maksimalt 6-7 meter, og infrarød sporing er derfor ikke anvendelig i meget store lokaler. Stærkt lys, som for eksempel direkte sollys, kan nedsætte rækkevidden markant. Der er ikke etableret standarder for positionering vha. infrarød. Eksempler på produkter: Versustech, Firefly, OPTOTRAK B.11 Ultralyd Sporing vha. ultralyd fungerer typisk ved at der opstilles specielle mikrofoner i hvert lokale og de emner der skal spores bærer en id-brik der indeholder en højttaler. Side 89

90 Lyd stoppes af døre, vægge, vinduer osv. men ikke af andre fysiske genstande som personer, senge og lignende. Ultralyd er derfor velegnet til at afgøre om et emne befinder sig i et rum, dvs. positionering på rumniveau. Batterilevetid på flere år for id-brikker på størrelse med en lille mobiltelefon. Ultralyd kan også benyttes til mere præcis positionering indenfor få centimeter. Dette kræver at læsere placeres i loftet med ca. 1 læser per kvadratmeter. Der er ikke etableret standarder for positionering vha. ultralyd. Eksempler på produkter: Sonitor B.12 Billedgenkendelse Automatisk genkendelse og positionsbestemmelse af personer og ting har længe været brugt i forskerkredse, især indenfor robotindustrien. Fremkomsten af Microsoft Kinect til XBox Live i 2009 har demonstreret at teknologien er klar til en lang række andre anvendelsesområder. Kinect benytter et videokamera og en infrarød laser til at aflæse kroppens udseende og bevægelser således at systemet dels kan identificere personen og dels kan gengive dennes bevægelser i realtid. Kroppens bevægelser kan således bruges til at styre spil, betjene menuer osv. Flere personer kan håndteres samtidigt, og kræver blot at personerne registreres i systemet. Med Microsofts offentliggørelse af API et til Kinect er det muligt at koble Kinect til en almindelig PC og skrive programmer som anvender teknologien. Der er dog endnu ikke billedkendelsesprodukter på markedet til sundhedsmæssige anvendelser, men potentialet er til stede. [Versel, 2010] B.13 Biometri Biometrisk genkendelse af personer er oftest baseret på aftryk af hænder eller fingre, mønstret i øjets iris, eller ansigtsgenkendelse. Fingeraftrykslæsere er de mest udbredte og fås i en række varianter med varierende præcision. De mest avancerede kan detektere om fingeren er ægte ved at registrere blodomløbet, og kan desuden guide personen til at placere fingrene korrekt på læseren. Fingeraftryk er digitalt lagret i alle nyudstedte pas i EU og en række andre lande. Til dette formål benyttes standarden ANSI/NIST-ITL. B.14 Bevægelsesfølere Bevægelsesfølere fungerer typisk ved brug af et gyroskop og et accelerometer, som bestemmer henholdsvis hvilken retning objektet bevæger sig og hvor kraftig bevægelsen er. Bevægelsesfølere findes mange nyere mobiltelefoner og andre enheder. Den væsentligste fordel ved bevægelsesfølere er at de ikke er afhængige af udefrakommende signaler for at kunne fungere. Anvendes kun bevægelsesføler til positionsbestemmelse vil den sikkerhed, der er i bestemmelsen af hastighed og retning dog Side 90

91 over tid resultere i en større og større fejlpositionering. Bevægelsesfølere anvendes derfor oftest sammen med andre teknologier, eksempelvis til at fjerne støj ved Wi-Fipositionering eller til at supplere GPS-positionering ved kortvarigt tab af satellitforbindelse. Desuden anvendes bevægelsesfølere ofte til at øge batterilevetiden for positioneringsenheder. Eksempelvis vil mange Wi-Fi tags kun udsende deres position, når en bevægelsesføler mærker at objektet bevæger sig. For flere detaljer, se [Woodman, 2007]. B.15 Stemmegenkendelse Stemmegenkendelse er identificering af en person baseret på dennes stemme, ikke at forveksle med talegenkendelse som er registrering af de ord der siges uden at vide hvem der taler. Anvendelsen af stemmegenkendelse falder i to kategorier: verifikation og identifikation. Ved verifikation identificerer personen sig på anden vise overfor systemet og stemmen benyttes kun til at bekræfte dette. Ved identifikation benyttes stemmen også til at finde ud af hvem personen er ved at gennemsøge en database med registrerede stemmer. Stemmegenkendelse anvendes i politimæssige og militære sammenhænge og visse telefonsystemer til bl.a. banker, men er endnu ikke udbredt i kommercielle produkter. For flere detaljer, se [Falavigna, 2011], [Globalsecurity, 2011]. Side 91

92 Side 92

93 Appendiks C. Administrationsprocesser I dette afsnit beskrives anbefalinger omkring vedligehold, tilpasning og drift af løsningen. Da Referencearkitekturen ikke udpeger konkrete produkter vil beskrivelsen være af overordnet, generel karakter. Det er intentionen, at afsnittet kan bruges til planlægning og opgaveestimering i relation til den centrale infrastruktur og fremtidige sporingsprojekter. Desuden kan afsnittet bruges som udgangspunkt for en tjekliste i forbindelse med løsningens fremtidige udvikling og drift. C.1 Generelle anbefalinger Sporbarhed er ikke noget man køber en gang for alle. Det griber så meget ind i styring af processerne på hospitalet, at det er noget som konstant vil være under forandring og forbedring. I en sporingsløsning spiller mange aspekter sammen på tværs af faggrænser; eksempelvis bygningsdrift, logistik, sundhed og it-drift. Der er således et stort behov for at koordinere mellem disse. Det anbefales at etablere en styregruppe med ansvar for: Teknologiudnyttelse, herunder sikre at der ikke introduceres nye teknologier ud fra behov som eksisterende teknologier kan opfylde. Styring af anvendelse af elektroniske id er (EPC) så der ikke opstår nummersammenfald i forskellige dele af løsningen. Styring af EPCIS-anvendelse herunder ensretning af betegnelser for lokaliteter, processer, mv. Koordinering med eksterne parter som anvender/producerer id-brikker. Prioritering og godkendelse af nye projekter, ud fra en vurdering af, hvordan de har eller kan få indflydelse på eksisterende systemer og processer. Konsekvensvurdering af ændringer, f.eks. nye projekter. Synergi mellem driftsopgaver og udviklingsopgaver. Mange af disse behov vil opstå med jævne mellemrum, og Styregruppen skal derfor være en permanent gruppe. C.2 Udrulning af integrationssystemet Inden man kan starte det første projekt som anvender sporingsdata skal der etableres en første version af infrastrukturen. Dette involverer følgende opgaver: Valg og evt. indkøb af platform til Integrationssystemet Valg og evt. indkøb af databaseplatform Etablering af databaser: Lokalitetsdatabasen, dvs. navne på alle steder, herunder evt. kortdata. Side 93

94 Identitetsdatabasen, dvs. mapninger mellem PID og GID Procesdatabasen, dvs. lovlige værdier for EPCIS Business Step Etablering af indhold af ovenstående databaser. Det anbefales at begynde med at skaffe et overblik over eksisterende information. Etablering af services: Lokalitetsservice, dvs. tilgang til lokalitetsdata samt mulighed for at holde disse synkroniserede med andre systemer. Identitetsservice, dvs. adgang til oversættelse mellem PID er og GID er. Etablering af Integrationssystemet, dvs. installation, tilpasning, konfiguration, afprøvning. Udvikling af integrationer: Fra Integrationssystemet til det/de første sporingssystemer Fra Integrationssystemet til eksisterende systemer (primært login) Fra udvalgte anvendelsessystemer til Integrationssystemet Etablering af en drifts-, support- og overvågningsorganisation. Afprøvning af: Alle funktionaliteter, herunder datakvalitet Driftsprocesser Performance og skalerbarhed Stabilitet/oppetid Første praktiske anvendelse af sporingsdata i et anvendelsessystem. Det anbefales at afprøve løsningen i mindre skala først, og derefter gradvist udvide anvendelsesområdet. C.3 Udrulning af nyt sporingsprojekt I dette afsnit beskrives de vigtigste emner, som bør overvejes i forbindelse med definition og udrulning af et nyt projekt baseret på den etablerede sporingsinfrastruktur. For små projekter vil mange af opgaverne ikke være relevante eller trivielle. Vurdering af om projektet er en sporingsløsning Referencearkitekturen beskriver kun sporingsløsninger, ikke it-løsninger i almindelighed. Projektet skal derfor være inden for rammerne af Referencearkitekturen. Se Afsnit 2.3 Afgrænsning. Vurdering af business case og risici Input til estimater kan findes i dette afsnit. Input til risici kan findes i dette afsnit samt Afsnit Trusselsvurdering. Vurdering af lovmæssige krav i henhold til Persondataloven, eksempelvis krav om overvågede personers tilsagn Side 94

95 Gennemførsel af pilotprojekter med henblik på risikominimering og mere præcis estimering, eksempelvis: Placering af læsere og id-brikker Forstyrrelser mellem læsere, id-brikker og andet udstyr Behov for supplerende teknologier i bestemte situationer Vurdering af om fejlraten er acceptabel til formålet Id-brikker: Valg af EPC-id (nummerserie) Proces for produktion af id-brikker Proces for udskiftning eller opladning af batterier. Infrastruktur: Montering, kalibrering og test af evt. nye læsere mv. Planlægning af løbende rekalibrering hvis nødvendigt. Udviklingsopgaver Udvikling eller udvidelse af anvendelsessystemer. Integration mellem Integrationssystemet og det nye sporingssystem. Dataændringer Opdatering af Lokalitetsdatabasen ved nye/ændrede lokaliteter. Registrering af id-brikker og objektid er (PID/GID) Integrationssystemet Overvej om belastningen af integrationssystemet stiger væsentlig. Beslut strategi for decentral filtrering og frekvens af hændelser. Evaluering af genbrugsmuligheder Genbrug af projektet i andre sammenhænge, og heraf afledte krav. Genbrug af eksisterende komponenter i projektet. Beskrivelse af projektet Lav en brugsanalyse af applikationen. Kortlæg aktører, sporede ressourcer og processer. Beslut hvilke af disse processer der skal komme fra automatisk registrerede hændelser. Beslut hvilke menneskelige godkendelser, der skal ske af de automatisk registrerede hændelser. Beslut hvorledes der rettes op på fejlregistreringer og de konsekvenser det måtte have i anvendelsessystemerne. Beskriv interfaces til eksisterende systemer der skal integreres. Definer datamænger og kvalitet (f.eks. svartid, pollingsfrekvens) osv. for API er Side 95

96 Styregruppens godkendelse af projektet under hensyntagen til bl.a. nye administrationsopgaver, konsistens af data, interferens/forstyrrelse, sikkerhed, behandling af personlige data. Dokumentation af administrative processer. Udrulningsplan. C.4 Overvågning De forskellige systemer der med tiden indføres til procesunderstøttelse baseret på informationer om emners identitet og placering vil blive af stor vigtighed for hospitalets daglige drift. Det er derfor nødvendigt, at systemet overvåges for at sikre stabiliteten. Der er flere komponenter der kræver overvågning: Fysisk infrastruktur: Det er nødvendigt at sikre at det opdages, hvis id-brikker, RFID-læsere/-antenner, Wi-Fi-accesspunkter og andet hardware fejler. Hvis f.eks. en Wi-Fi-enhed fejler vil alting sandsynligvis virke, så man opdager ikke nødvendigvis problemet. Men nøjagtigheden kan være påvirket således at der periodisk sendes forkerte positionsdata videre i systemet eller at disse slet ikke registreres. Batterier: En del id-brikker anvender batterier og er i stand til at fortælle om batteriets tilstand. Det kan være svært, at finde enheden når batteriet svigter helt, så en præventiv overvågning er hensigtsmæssig. Performance: Der er anvendelser, hvor svartiden er kritisk. Performance af database og transmission skal overvåges. Desuden skal svartider for services i de integrerede systemer måles og overvåges. Procesflow: Flere anvendelser indeholder workflows, hvor der er en forventning om at forskellige personaletyper løser opgaver i samme takt, som de opstår. Hvis dette ikke sker, skal der være nogen, der griber ind og løser problemet. Ligeledes kan det også være nødvendig at gribe ind, hvis man kan se, at der sker en ophobning af ressourcer et sted, hvor der ikke er den nødvendige kapacitet, f.eks. hvis sengevaskeriet får flere senge tilsendt på en gang end de kan klare. For at denne overvågning kan realiseres, må der stilles krav til de indgående systemer om, at de indeholder en sådan funktionalitet. C.5 Løbende driftsopgaver Der skal afsættes ressourcer til løbende vedligeholdelse af infrastrukturen: Uddeling/montering af nye id-brikker Udskiftning af defekte eller slidte id-brikker Udskiftning/opladning af batterier Ændring af lokalers indhold eller anvendelse kan kræve kalibrering eller omplacering af læsere/antenner Ændringer i arbejdsgange kan give nye behov Flytning eller opsætning af nye læsere Side 96

97 Særlig præcis kalibrering i bestemte områder C.6 Afslutning af sporingsprojekt Ved lukning af et sporingsprojekt er der en række opgaver som skal udføres: Fjerne infrastruktur, inkl. læsere og opladere Afmontere/fjerne id-brikker Gennemgåbrugerflader og API er for funktionalitet indført af det lukkede projekt. Fjerne evt. død funktionalitet/data Opdatere dokumentation. Side 97

98 Appendiks D. Arkitekturvalidering I dette afsnit valideres Referencearkitekturen op imod de krav, brugsscenarier og teknologier som er beskrevet i Afsnit 3 og 4. Validering i forhold til de overordnede målsætninger i Afsnit 2 er beskrevet i konklusionen (Afsnit 7). For hvert af kravene og brugsscenarierne vurderes det om Referencearkitekturen opfylder punktet Fuldt, Delvist eller Ikke. Opfyldelse henviser her til om Referencearkitekturen adresserer punktet. Dette betyder ikke at Integrationssystemet nødvendigvis skal gøre noget aktivt for at håndtere den pågældende situation, eksempelvis kan et punkt være adresseret ved en manuel procedure. D.1 Kravopfyldelse Alle krav angivet i Afsnit 3 Rammer og krav opfyldes fuldt ud af Referencearkitekturen. I nedenstående tabel gennemgås alle kravene med forklaring af, hvorfor kravet er opfyldt. Krav Opfyldt Kommentar [K:afkobling] Fuldt Anvendelsessystemer er kun afhængige af Integrationssystemet, jfr. Afsnit 5.2.2, [P:indirekte-adgang] og det er derfor muligt kun at lave integrationer en gang. [K:sameksistens] Fuldt Eksisterende systemer er undtaget og kan således kræve flere integrationer, jfr. Afsnit 5.2.2, [P:indirekte-adgang]. [K:wifikompatibilitet] Fuldt Wi-Fi anbefales som generel positioneringsteknologi, jf. Afsnit A.2,[P:wifi]. [K:id-systemer] Fuldt Der er separation mellem PID og GID jfr. Afsnit 5.4.1, [P:surrogat-id]. GID bevares hvor de er og linkes kun fra Identitetsdatabasen, jfr. Afsnit 5.5.1, [P:id-oversættelse]. [K:bygningsdata] Fuldt Lokalitetsdatabasen indeholder disse informationer, jfr. Afsnit 5.7, [P:lokalitetsservice]. [K:metadata-ind] Fuldt Dette sker på Lag 5, jfr. Afsnit 5.5.5, [P:data-udveksling]. [K:spor-ud] Fuldt Dette sker via Integrationssystemet, jfr. Afsnit 5.3.2, [P:snitflade-lag4]. [K:metadata-ud] Fuldt Dette kan ske via Integrationssystemet eller på Lag 5 afhængigt af hvilke data der er tale om, jfr. Afsnit 5.5.5, [P:data-udveksling]. [K:spor-ind] Fuldt Eksterne systemer kan levere data ind via EPCIS Capture Interface ligesom interne systemer. Referencearkitekturen stiller dog ikke krav om dette, jf. afsnit 5.2.2, [P:indirekteadgang]. Side 98

99 Krav Opfyldt Kommentar Fuldt Se Afsnit 5.11 og Afsnit 6.4. Fuldt Se Afsnit 5.11 og Afsnit 6.4. [K:uautoriseretdataadgang] [K:uautoriserettilslutning] [K:uautoriseretfunktionsstop] Fuldt Se Afsnit 5.11, [P:auditlog] og Afsnit 6.4, samt Afsnit 5.9.1, [P:redundans]. [K:auditering] Fuldt Se Afsnit 5.11 [P:auditlog] og Afsnit 6.4. [K:oppetid] Fuldt En redundant løsning defineres i Afsnit 5.9.1, [P:redundans]. Praktisk oppetid afhænger dog også af konkrete valg af produkter og netværkets stabilitet. [K:tilkobling] Fuldt Efter tildeling af login og rettigheder kan systemer sende data til og modtage data fra Integrationssystemet. Sporingssystemer vil typisk også have behov for at tilføje data til Identitetsdatabasen. Se også Afsnit 6.7. Hvis tilkoblingen kræver ændringer i selve Integrationssystemet kan dette muligvis også håndteres uden nedetid pga. redundansen. Dette afhænger dog af det konkrete produkt og dets konfiguration. [K:leveringsgaranti] Fuldt Det er sporingssystemets ansvar at al data leveres fuldt til Integrationssystemet, jfr. Afsnit Det er Integrationssystemets ansvar at kritiske hændelser leveres til abonnenter, jfr. Afsnit Se også Afsnit 5.8.1, [P:eksplicit-filtrering]. [K:forsinkelse] Fuldt Løsningen er designet således at disse krav vil kunne honoreres af konkrete produkter. Se Afsnit 6.5 og 6.6. [K:antal-objekter] Fuldt Se svar til [K:forsinkelse]. [K:antal-hændelser] Fuldt Se svar til [K:forsinkelse]. [K:monitorering] Fuldt Medfølgende værktøjer skal kunne monitorere sporingsløsninger, jfr. Afsnit [P:administrationsværktøjer]. Se også Appendiks C.4. [K:fejlsituationer] Fuldt Se Appendiks C.4. Fuldt De centrale data om lokaliteter og identiteter vedligeholdes centralt, jfr. Afsnit 5.7.2, [P:lokalitetsservice] og Afsnit 5.5.1, [P:id-oversættelse]. [K:snitflader] Fuldt Referencearkitekturens snitflader er primært beskrevet i Afsnit samt i Afsnit 6.2. [K:centraltvedligehold] [K:parallellesnitflader] Fuldt Se Afsnit 6.7 Fleksibilitet. Det er op til implementationen af snitfladerne at beskrive præcist hvorledes dette opfyldes. Side 99

100 D.2 Scenarieopfyldelse Alle brugsscenarier angivet i Afsnit 3Rammer og krav opfyldes fuldt ud af Referencearkitekturen. Der er dog nogle få forbehold som beskrives nedenfor. I nedenstående tabel gennemgås alle brugsscenarierne med angivelse af om scenariet er understøttet af Referencearkitekturen. Desuden angives særlige karakteristika eller udfordringer ved en løsning på det pågældende scenarie. Kommentaren Ingen særlige tekniske udfordringer nedenfor betyder at der ikke er identificeret særlige udfordringer ift. anvendelse af Referencearkitekturen for det pågældende scenarie. Det betyder ikke, at der ikke vil være problemer med at få konkrete sporingsløsninger til at virke, at indføre it-systemer i stedet for manuelle procedurer, osv. Brugsscenarie Opfyldt Kommentar Adgangskontrol Fuldt Kan opfyldes med passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Advisere modtagere af rørpost Cytostatikabebehandling Demente patienter forlader afdelingen Finde vej i bygninger med egen mobiltelefon Finde vej i bygninger med udleveret tablet Følsomme varer med rørpost Identifikation af genstand Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Kan opfyldes med Wi-Fi eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi på hospitalets område. Kræver GPS og mobilforbindelse for at kunne spore udenfor. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med passiv RFID. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi. Ikke tidskritisk. Præcision på lokalitetsniveau kan blive utilstrækkeligt, afhængigt af hvordan brugerfladen udarbejdes. Kan opfyldes med Wi-Fi. Ikke tidskritisk. Præcision på lokalitetsniveau kan blive utilstrækkeligt, afhængigt af hvordan brugerfladen udarbejdes. Kan opfyldes med Wi-Fi eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med stregkoder eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Side 100

101 Brugsscenarie Opfyldt Kommentar Identifikation af patient ved stuegang Kontrol af sterile varer Kontrol over sengeflow på hele hospitalet Lokalisering af senge Lokalisering af udstyr Notifikation om forkert opbevaring Opfyldning af lokalt lager Optimering af arbejdsgange Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Kan opfyldes med stregkoder eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med stregkoder og/eller passiv RFID. Tidskritisk. Kompatibilitet med udefrakommende id-brikker spiller væsentlig rolle. Kan opfyldes med Wi-Fi. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi. Ikke tidskritisk. Præcision på lokalitetsniveau kan blive utilstrækkeligt, hvis der skal positioneres meget præcist (eksempelvis på hylder). Kan opfyldes med Wi-Fi eller passiv RFID. Ikke tidskritisk. Giver stort antal hændelser, så opdateringsfrekvens og tidspunkt for aflæsning er vigtige parametre. Kan opfyldes med passiv RFID. Ikke tidskritisk. Giver stort antal hændelser, så opdateringsfrekvens og tidspunkt for aflæsning er vigtige parametre. Kan opfyldes med stregkoder eller passiv RFID. Ikke tidskritisk. Dataopsamling foretages i anvendelsessystem. Ingen særlige tekniske udfordringer. Overfaldsalarm Fuldt Kan opfyldes med Wi-Fi. Tidskritisk. Ingen særlige tekniske udfordringer. Overvågning af udløbsdatoer Fuldt Kan opfyldes med passiv RFID. Ikke tidskritisk. Giver stort antal hændelser, så opdateringsfrekvens og tidspunkt for aflæsning er vigtige parametre. Side 101

102 Brugsscenarie Opfyldt Kommentar Patienters tilkald af personale Fuldt Kan opfyldes med Wi-Fi. Tidskritisk. Ingen særlige tekniske udfordringer. Afhængighed af batteri vil muligvis være et problem. Personale-login Fuldt Kan opfyldes med passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Personale-login med valg Positionering af andet personale Positionering af demente Procesdokumentation rengøring Processer på operationsstuen Prøvetagningsrunde Reducere spild pga. udløbsdato Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Kan opfyldes med Wi-Fi eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi eller passiv RFID (præcision afhængig af antal læsere). Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi på hospitalets område. Kræver GPS og mobilforbindelse for at kunne spore udenfor. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med stregkoder eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med passiv RFID. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi på hospitalets område. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med passiv RFID. Ikke tidskritisk. Giver stort antal hændelser, så opdateringsfrekvens og tidspunkt for aflæsning er vigtige parametre. Skift batterier Fuldt Kræver understøttelse i id-brikkerne og den software der følger med. Ikke tidskritisk. Sporing af blodpræparater Fuldt Kan opfyldes med stregkoder eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Side 102

103 Brugsscenarie Opfyldt Kommentar Sporing af patientforløb Sporing af rørpostpatroner Sporing af varer i rørpost Søgning efter varer i andre afdelinger Tyverisikring af hjælpemidler Tyverisikring af inventar Uddeling af medicin Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Fuldt Kan sandsynligvis opfyldes med Wi-Fi eller passiv RFID i alle rum. Præcisionen skal dog være ret høj, afhængigt af brugerflade og beslutningsproces. Ikke tidskritisk. Fuldt opfyldt da det vil være muligt at indføre et manuelt godkendelsestrin i brugerfladen. Kan opfyldes med Wi-Fi eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. NB! Anvendelse til styring af rørpostanlægget vil stille meget høje krav til svartiderne, og er ikke understøttet. Kan opfyldes med passiv RFID. Ikke tidskritisk. Giver stort antal hændelser, så opdateringsfrekvens og tidspunkt for aflæsning er vigtige parametre. Kan opfyldes med Wi-Fi eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med stregkoder eller passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Udlån/returnering Fuldt Kan opfyldes med passiv RFID. Tidskritisk. Ingen særlige tekniske udfordringer. Udstyr signaleres klar til afhentning Vejledning af patienter Fuldt Fuldt Kan opfyldes med Wi-Fi-brik med trykknap eller ved brug af stregkoder/passiv RFID som signaleringsmekanisme. Ikke tidskritisk. Ingen særlige tekniske udfordringer. Kan opfyldes med Wi-Fi. Ikke tidskritisk. Præcision på lokalitetsniveau bør være tilstrækkeligt. Ingen særlige tekniske udfordringer. Side 103

104 Det vurderes at alle brugsscenarierne kan opfyldes indenfor rammerne af Referencearkitekturen. Der er nogle scenarier som kan få brug for mere præcis positionering end på lokalitetsniveau, nemlig Finde vej i bygninger med udleveret tablet og Finde vej i bygninger med egen mobiltelefon samt de brugsscenarier der handler om at finde ting, dvs. Lokalisering af. Disse er dog understøttet af Referencearkitekturen, da koordinater (f.eks. x,y,z) kan overføres på samme måde som sensordata. Der er ikke aktuelle krav til at Referencearkitekturen skal understøtte styring af rørpost, selvkørende vogne og lignende og sådanne scenarier er da heller ikke understøttet. Kravet til den maksimale forsinkelse af sporingshændelser vil i sådanne scenarier være mindre end det ene sekund angivet i [K:forsinkelse]. Der er dog ikke noget i arkitekturen, der gør at man ikke skulle kunne komme væsentligt længere ned i maksimal forsinkelse med passende optimering og hardware. Om dette er tilstrækkeligt, eller der er behov for et egentligt realtidssystem, afhænger af det konkrete scenarie. D.3 Teknologiunderstøttelse Referencearkitekturen understøtter alle de sporingsteknologier som er beskrevet i Afsnit 4, Sporingsteknologier. Mange af teknologierne fungerer konceptuelt ens og det er derfor ikke så meget de enkelte teknologier, der er interessante at vurdere, men mere de forskellige typer af teknologier. Sporingsteknologierne kan, som beskrevet i Afsnit 4, opdeles i tre grupper med hver deres karakteristika og udfordringer: Automatic Identification and Data Capture (AIDC), Real-Time Locating System (RTLS) og Wireless Sensor Network (WSN). Desuden findes en fjerde gruppe som adskiller sig ved, at der ikke indgår id-brikker i løsningen, nemlig stemmegenkendelse, biometri og billedgenkendelse. De fire gruppers særlige karakteristika og disses understøttelse i Referencearkitekturen gennemgås i det følgende. Karakteristika Type Opfyldt Kommentar I AIDC-systemer spiller det sporede objekts position ikke nødvendigvis nogen rolle. Måske opsamles positionen slet ikke. AIDC-sporingssystemer kan være meget simple, og principielt svare til dataindtastning via tastaturet på en PC. RTLS-sporingssystemer kommer ofte med et delsystem til håndtering og præsentation af lokaliteter. AIDC Fuldt Integrationssystemet kan videresende hændelsen med Lokaliteten Region Midtjylland eller lignende. AIDC Fuldt Dette aspekt er særskilt adresseret af Referencearkitekturen i [P:indirekteadgang]. RTLS Fuldt Referencearkitekturens princip om central lokalitetsdatabase, [P:lokalitetsservice], stiller krav om åbenhed på dette punkt. Side 104

105 Karakteristika Type Opfyldt Kommentar WSN-løsninger er ofte decentraliserede, dvs. uden et centralt opsamlingspunkt. WSN Fuldt Uanset om der er et eller flere opsamlingspunkter kan sporingsdata sendes til Integrationssystemet, blot der er forbindelse til dette. Visse RTLS- og WSN-produkter giver mulighed for feedback til id-brikken, eksempelvis pagerfunktionalitet. RLTS/ WSN Fuldt Dette er understøttet af Referencearkitekturen som beskrevet i Afsnit 5.2.2Separation af dataopsamling og anvendelsessystemer. Ved biometriske systemer er der ingen id-brik, men blot en person som genkendes. Biometri Fuldt Hvis genkendelsen er succesfuld vil det altid resultere i en id som repræsenterer personen. Denne id kan sendes til Integrationssystemet på samme måde som hvis den var aflæst fra en id-brik. At alle ovenstående teknologier understøttes af Referencearkitekturen er dog ikke nogen garanti for at et givet produkt vil gøre det. Eksempelvis stiller Referencearkitekturen nogle få krav til hvor sporingssystemer skal have åbne API er, se Afsnit Afhængigheder og snitflader, og ikke alle produkter vil have disse. Side 105

106 Side 106