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, henrik.stilling@stab.rm.dk 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