Arkitekturbeskrivelse: RoS i RSD Analyse

Transkript

1 Arkitekturbeskrivelse: RoS i RSD Analyse Dokumentidentifikation Projekt id Projekt titel Projektleder Systemejer/projektejer Projektregi Projektidentifikation Applikationsansvarlig enhed Deltagende enheder Region Syddanmark Systemejer Laboratorieforvaltning COSMIC-forvaltning Sundheds-IT Regional IT Projektets varighed Rekvisition og Svar i Region Syddanmark - Analyse Jesper Dahl SLB Sæt kryds RSI / NSI Regional Lokal X SLB og OUH Udarbejdet dato Udarbejdet af Flemming Elbrønd og Trine Hynkemejer i samarbejde med SLB og OUH Revisionshistorik Version Dato Beskrivelse Navn Skabelon/disposition oprettet Flemming Elbrønd Første udkast til tekstindhold i div. afs. udarbejdet Mere tekstindhold og rettelser efter kommentarer fra Jesper og Trine Flemming Elbrønd Flemming Elbrønd Rettelser/justering af konklusion mv. ift. Koordinering med Projektbeskrivelse sammen med Jesper Flemming Elbrønd Risikovurdering rettet + div. smårettelser Flemming Elbrønd Rettelser efter første interne review i Arkitekturteamet Flemming Elbrønd, Anders Barlach, Niels Gundtoft Smårettelser og præciseringer Flemming Elbrønd, Trine Hynkemejer Afsnit 8 udfyldt. Afsnit 9 udfyldt med input fra Henning. Flemming Elbrønd Smårettelser Flemming Elbrønd Endelig version Flemming Elbrønd Side 1 af 13

2 Indhold 1 Vejledning Indledning Ordliste og forkortelser Baggrund og opsummering Baggrund og formål Arkitektur Vision Projektets målgruppe og hovedinteressenter Arkitekturvurdering LIMS-RoS Konklusion Begrundelse Forslag videre proces Generisk kontekststyring Konklusion Begrundelse Forslag videre proces Analysens udgangspunkt og forløb Overordnet proces diagram Konceptuelt oversigtsbillede Forretningsarkitektur Nuværende situation (AS-IS) Fremtidig situation (TO-BE) Applikation og integration Nuværende applikation- og integrationssituation (AS-IS) Fremtidig applikation- og integrationssituation (TO-BE) Teknologi og nødvendig infrastruktur Arkitekturrisiko (TO-BE) Referencedokumenter Bilagsoversigt Side 2 af 13

3 1 Vejledning Nærværende dokumentet er en arkitekturbeskrivelse og anbefalinger, som regionens it-arkitekter leverer til projekterne i forbindelse med gennemførelse af Analysefasen. Projektet skal efterfølgende egenhændigt indsætte relevante konklusioner i valgte projektbeskrivelse. Det er projektet, der har ansvaret for at udfylde projektbeskrivelsen herunder ligeledes at udarbejde business case. Det kan evt. ske i et samarbejde med it-arkitekterne. Når den samlede projektbeskrivelse er udfærdiget af projektet, skal denne efterfølgende sendes til review hos it-arkitektteamet. 2 Indledning Baggrunden for projekter er, at der i nogen tid har været arbejdet på to fronter omkring løsninger til rekvisition og svar. Dels har der på OUH været arbejdet på at få "alle svar ind i COSMIC, og dels har der på SLB været arbejdet på at samle alle laboratorie rekvisitioner (og svar 1 ) i nyt LIMS/RoS. USIT har påpeget behovet for at koordinere indsatserne i de to spor, med det mål at kunne præsentere udvalget for en samlet roadmap for RoS funktionaliteten på laboratorieområdet i Region Syddanmark. Der er derfor gennemført et analyseprojekt med følgende formål: Hvorvidt LIMS-RoS på den korte bane kan anvendes bredere end til rekvirering. Hvorvidt LIMS-RoS funktionaliteten kan være den langsigtede løsning for RoS i COSMIC, således at LIMS-RoS bliver så integreret i COSMIC, at det for klinikerne opleves som en del af COS- MIC. Hvorvidt 2-vejs kontekststyring kan udvikles/anskaffes som en generisk komponent der indledningsvis udelukkende understøtter bevarelse af patientkontekst mellem COSMIC og LIMS-RoS. Men over en periode kan tænkes bredere anvendt mellem applikationer. Denne arkitekturbeskrivelse er resultatet af analysen. Se en mere detaljeret gennemgang af baggrunden for projektet i beskrivelsen i projektforslaget (Bilag 1). Den gennemførte analyse har været delt op i to spor: Kravopfyldelse og fordele/ulemper ved forskellige løsningsscenarier Undersøgelse af muligheder for indførelse af en generisk kontekststyringskomponent Som grundlag for beskrivelse af de mulige scenarier, er der udarbejdet en samlet liste over forretningskrav til RoS området. Opfyldelsen af disse krav er så holdt op mod hvert af scenarierne krav for krav, og der er ud fra dette udarbejdet et scenariedokument, der fremhæver fordele og ulemper for hvert scenarie. Der er i scenariedokumentet (og andre steder i baggrundsmaterialet) nævnt røntgen, selv om scopet for denne analyse udelukkende er RoS på laboratorieområderne. Som grundlag for vurderingen af en fælles generisk komponent til kontekststyring, er der fortaget en indledende markedsafdækning af mulige standardløsninger for dette. Desuden har der været dialog med leverandøren af COSMIC og LIMS/RoS, for at høre om muligheder for en specifik løsning af kontekstproblematikken mellem disse systemer, og der er foretage en mindre interviewrunde blandt udvalgte klinikker for at afdække behov for kontekststyring. 1 SLB har arbejdet også med svar. LIMS-RoS kontrakten er i samarbejde med RSJ, og RSJ har behov for at kunne se laboratoriesvar i løsningen. Dette er baggrunden for at LIMS-RoS både kan håndtere rekvisition og svar. Side 3 af 13

4 3 Ordliste og forkortelser Ordliste og forkortelser CCOW COSMIC ESA POC RoS SSO Forklaring Clinical Context Object Workgroup. Standard for synkronisering mellem afkoblede sundhedsapplikationer (kontekststyring). Den regionale version af Region Syddanmark elektroniske patientjournal. Effektiv System Adgang Proof Of Concept Rekvisition og Svar Single Sign-On 4 Baggrund og opsummering Afsnittet beskriver bagrund og formål med analysen, redegør for arkitektur visionen og lister hovedinteressenter. 4.1 Baggrund og formål Nærværende arkitekturbeskrivelse udføres i forbindelse med gennemførelse af en it analyse på RoS området i Region Syddanmark. Projektledelsen varetages af Sygehus Lillebælt, og gennemføres med ressourcer fra SLB, OUH, Regional-IT og Sundheds-IT. Projektet er igangsat af Udvalg for Sundheds-IT. Formålet med analysen er at sikre et fagligt grundlag for at kunne etablere grundlaget for den fremtidige indsats på RoS område, som udmøntes i en anbefaling indeholdt i en Projektbeskrivelse. Analysen skal især sikre, at løsningsforslag og udviklingsstrategi er afstemt med forretningen og det øvrige systemlandskab. Som input til denne udviklingsstrategi på RoS-området udarbejdes nærværende arkitekturbeskrivelse med udgangspunkt i interessenternes konkrete forretningsbehov til at understøtte arbejdsgangene og de mulige scenarier for understøttelse af forretningsbehovene. Arkitekturanalysen vil endvidere afdække behovet for snitflader til omkringliggende applikationer og komponenter. I analysen vurderes den nuværende situation (AS-IS) efterfulgt af mulige fremtidige situationer for området (TO-BE). Slutteligt fremlægges en samlet anbefalet arkitektur. 4.2 Arkitektur Vision Vision er at RSD skal have én samlet løsning til håndtering af rekvisition og svar for alle områder. Der skal derfor findes en løsning, der: Understøtter én samlet klinisk it arbejdsplads, til håndtering af rekvisitioner og svar. Understøtter klinikkens behov for rekvirering og svarvisning. Understøtter modtagelse af rekvisitioner fra og levering af svar til primær sektoren. Understøtter klinikernes behov for koordinering af flere rekvisitioner og tilhørende aktiviteter. Kan integrere med i RSD s øvrige systemlandskab. Harmonisering af implementering og anvendelse af fælles regionale løsninger skal forenkle drift og vedligeholdelse af systemerne, reducere risikoen for fejl af tekniske og brugermæssige årsager og gøre det lettere for kliniske brugere at se svar vedrørende patienter som har forløb på tværs af organisationen. 4.3 Projektets målgruppe og hovedinteressenter Projektet har identificeret følgende hovedinteressenter med udgangspunkt i interessentanalysen i RSD itprojektmodel, der beskrives nærmere i projektbeskrivelsen. Interessent Anliggende Indflydelse Interesse USIT Budget, Plan, Milepæle Høj Side 4 af 13

5 Interessent Anliggende Indflydelse Interesse Systemejer for hhv. COSMIC og LIMS-RoS Projektgruppe Regional-it Klinisk personale Rekvirenter Laboratorier Producenter Sundheds-it Udmøntning af strategi Plan, Aktiviteter, Milepæle Infrastruktur arkitektur Høj Høj Høj Anvendelse Høj Funktionalitet og arbejdsgange Forretnings- og applikations arkitektur Høj Høj 5 Arkitekturvurdering Afsnittet beskriver dokumentets hovedkonklusioner og anbefalinger og begrunder efterfølgende disse, samt giver et forslag til den videre proces. Alle disse er opdelt i to: LIMS-RoS og Generisk kontekststyring. 5.1 LIMS RoS Til at vurdere hvilken løsning, der bør anbefales, er der udarbejdet fem løsningsscenarier, hvor funktionaliteten omkring rekvisition og svar på forskellig vis er delt mellem LIMS-RoS og COSMIC. Se nærmere om scenarierne i Bilag Konklusion Det vurderes ud fra analysen, at det er mest fordelagtigt for Regionen, at scenario 2 - Fuld LIMS-RoS i første omgang vælges som den fremtidige løsning på Rekvisition og Svar for laboratorie området. Når en implementering af LIMS-RoS er gennemført på samtlige sygehuse, kan en løsning, hvor man får samlet svar fra laboratorieområdet med andre prøvesvar (her tænkes specielt på røntgen), overvejes Begrundelse Der er identificeret to forretnings services (hovedprocesser), som et RoS system skal kunne håndtere: 1. Rekvirer analyser. Herunder mulighed for at rekvirere analyser fra flere laboratorieområder i én samlet arbejdsgang (ved brug af foruddefinerede rekvisitionssæt). 2. Se svar Under se svar er der tre funktioner: 1. Se svar på analyser for en rekvirent/svarmodtager (liste niveau). Herunder én samlet indbakke med muligheder for passende filtrering og sortering. 2. Se svar på analyser for én patient (kumuleret svar). Herunder at man skal kunne se en samlet oversigt over prøvesvar fra flere laboratorieområder på én gang, og at man samtidig med læsning af svar kan dokumentere i journalen i EPJ. 3. Kvittér for svar. Herunder nem udsøgning og behandling af svar, der ikke er kvitteret for. Alle disse vil kunne understøttes af LIMS-RoS. Begrundelsen for at vælge LIMS-RoS skal både ses i perspektivet af både en strategisk og en praktisk værdi. Ved valget af èt system til RoS-området opfyldes IT-princippet om Samme system til samme opgave. Ved den systemmæssige konsolidering, opnås tillige grundlaget for at få fælles arbejdsgange på alle sy- Side 5 af 13

6 gehuse, hvilket vil gøre personaleskift mellem sygehusene nemmere, højne kvaliteten i patientbehandlingen og øge patientsikkerheden. Ud over implementering af ensartede arbejdsgange, opnås der også klinikergevinst i form af bedre funktionalitet omkring rekvirering, f.eks. ved indførelse af rekvisitionssæt, og omkring svar bedre overblik over svar, f.eks. forskellige filtreringsmuligheder og mulighed for at se kumuleret svar. Det sidste vil blive endnu bedre på sigt, når alle laboratorieområder integreres fuldt ud. Svar fra praksis vil umiddelbart også være tilgængelige. Se evt. yderligere argumentation og begrundelse i Scenariodokumentet i Bilag Forslag videre proces Forslag fra arkitekturteamet er følgende. Der igangsættes et projekt der sørger for 1. Implementering af LIMS-RoS på alle sygehuse 2. Integration af manglende laboratorieområder (Patologi og Genetik) med LIMS-RoS 3. Analyse og optimering af LIMS-RoS på udvalgte områder, bl.a. bedre kvitteringsfunktionalitet for opnåelse af rettidig reaktion på prøvesvar Efterfølgende eller parallelt skal der igangsætte et analyseprojekt/afprøvningsprojekt, der foretager en grundigere undersøgelse af generisk kontekststyring og afprøver et produkt, med henblik på en evt. fremtidig implementering af dette, jf Generisk kontekststyring Konklusion To-vejs-kontekststyring en absolut nødvendig funktionalitet for en sikker anvendelse af RoS sammen med COSMIC og andre applikationer. Derfor skal to-vejs-kontekststyring etableres. Det vurderes dog, at LIMS-RoS godt kan idriftsættes med den en-vejs-kontekststyring, som følger med LIMS-RoS på de sygehuse, der i dag ikke ser svar i COSMIC. Dette vil nemlig ikke forringe deres nuværende funktionalitet. Det er dog en forudsætning for OUH med to-vejs-kontekststyring, da de ellers skal omlægge arbejdsgangene væsentligt for at få det til at fungere. Produkter til kontekststyring, der bygger på teknologier der kan tilgå de enkelte moduler udefra (såkaldt bridgeing teknologi) foretrækkes, så kontekstdeling kan etableres, uden at alle leverandører skal udvikle ny funktionalitet Begrundelse Følgende overvejelser/begrundelser er årsagen til denne anbefaling: RoS er et eksempel på et eksternt modul, der indgår sømløst i det daglige kliniske arbejde med COSMIC og eksterne systemer. En sammenblanding af patientinformationer er nærliggende, da man nemt skifter fra et modul til et andet, uden at være opmærksom på hvilken patient, der arbejdes med. Klinikerne peger på, at det er antallet af klik, der er afgørende. Kontekststyring vil nedsætte antallet af klik og indtastninger af CPR numre. Regionens systemer er ikke alle klar til at indgå i et set-up med et kontekststyringsprodukt, der kræver integration på serversiden Forslag videre proces Omkring kontekststyring foreslås det, at der startes et afprøvningsprojekt (POC-projekt) udelukkende med det formål at afprøve generisk kontekststyring (i første omgang med COSMIC og RoS i fokus). Der er behov for en mere dybdegående teknisk analyse af området, herunder: Side 6 af 13

7 Bedre indblik i standarder på området Undersøgelse af sammenhænge/afhængigheder mellem SSO og kontekststyring Udarbejdelse af liste over RSD-applikationer, som det giver mening at inkludere i et kontekststyringsmiljø/-produkt Bedre afdækning af klinikernes brugsmønstre og idéer til hvor kontekststyring kan forbedre disse Opstilling af krav til fremtidig softwareanskaffelser, så systemerne nemt kan indgå i et kontekststyringsmiljø/-produkt Set i lyset af den opblødning, der ses omkring den strategiske retning for COSMIC, vil der givetvis komme flere krav til, at der er en intelligent integration mellem COSMIC og system X. Derfor vil det være ekstra relevant, at få igangsat en analyse, så man får defineret en systemarkitektur, der inkluder og tager højde for implementering af kontekststyring. 6 Analysens udgangspunkt og forløb Analysearbejdet er gennemført i to spor. Et, der har opstillet scenarier for en fremtidig løsning for Rekvisition og Svar i RSD, og et, der har undersøgt mulighederne for generisk kontekststyring. Analysen omkring RoS løsning har taget sit udgangspunkt i den eksisterende dokumentation og tidligere analyser, der har derfor kun i begrænset omfang været inddraget klinikere i denne analyse. Alle kendte krav er blevet samlet (se Bilag 3), og der er opstillet fem scenarier for et fremtidigt RoS, og hvert af kravene er holdt op mod disse. Ud fra dette er der lavet et scenarie-dokument (se Bilag 2), hvor fordele og ulemper ved hver enkelt scenarie er listet, og hvor scenariet er vurderet ud fra forskellige perspektiver. Projektgruppen har derefter udvalgt tre scenarier (2, 4 og 5) som mulige løsninger, og bedt leverandøren (CGI) om at kommentere på disse. Da CGI ikke har givet nogen vurdering, der giver værdi, men blot kommenteret at Ingen af de tre angivne scenarier vurderes som forkerte eller umulige, har projektgruppen selv vurderet og valgt det bedste af de tre scenarier. Da de fleste af scenarierne forudsætter implementering af to-vejs-kontekststyring, er CGI blevet bedt om et bud på, hvordan dette vil kunne realiseres mellem LIMS-RoS og COSMIC (en-vejs-kontekststyring er allerede en del af LIMS-RoS leverancen, og en generisk løsning af kontekststyring er undersøgt separat). CGI foreslår her fire løsningsforslag, hvor de to går på en specifik løsning mellem LIMS-RoS og COSMIC, og de to andre på en mere generisk løsning. I Analyse af generisk kontekststyring har projekts arbejdsgruppe foretaget en interviewrunde hos udvalgte klinikere for at afdække deres normale arbejdsgange for at vurdere, hvor stort behovet for to-vej kontekststyring er. En konkluderende sammenfatning af interviewene kan ses i Bilag 4. Analysen viser, at det aktuelle behov for to-vej kontekststyring ift. RoS er begrænset. Det skal dog bemærkes, at klinikerne med de nuværende systemer (og deres begrænsninger) meget vel kan have tilegnet arbejdsgange og workarounds, som ikke er de mest optimale, og som begrænser dem i at se mulighederne i en to-vej kontekststyring. Interviewene afslørede, at klinikerne tilsyneladende er ret ligeglade med, om tingene er samlet i ét eller flere systemer. Det der er vigtigt er, at de ved så få museklik som muligt kan tilgå de oplysninger, de har behov for, fra deres arbejdsplads. Dermed dokumenterer de behov for kontekststyring, da det netop nedsætter antallet af klik og indtastninger. Projektgruppen har desuden lavet en meget begrænset markedsafdækning, hvor to produkter til kontekststyring blev præsenteret. WeAdd Sync fra Evry og Single Sign-On and Context Management fra Caradigm. Projektgruppen har også haft kontakt til Region Østergotland i Sverige og set, hvordan kontekststyring er implementeret mellem COSMIC og andre kliniske applikationer (bl.a. et RoS system) gennem Evry s WeAdd sync. Der har også været holdt et telefonmøde med GartnerGroup, for at få en vurdering af, hvor modent markedet er, og hvilke konkrete generiske løsninger, der findes. Resultatet af dette møde var, at der omkring produkter til generisk kontekststyring med anvendelse af CCOW standarden ikke sker ret meget i øjeblikket, og at der kun er få aktører på markedet. Dette skyldes at mange hospitaler vælger suite-software, hvor samspillet mellem modulerne er kontrolleret, og der dermed ikke er behov for kontekst-software. Denne trend er dog (i USA) ved at ændre sig, idet der er en erkendelse af, at ikke alle klinikernes behov dækkes tilstrækkeligt af suite-softwaren. Det er ligeledes Gartners vurdering, at kontekststyring stadig giver god værdi for brugerne, og derfor anbefaler de, at det er noget, som RSD etablerer. Side 7 af 13

8 6.1 Overordnet proces diagram Nedenstående diagram viser de overordnede processer for RoS, som løsningen skal understøtte. Figur 1: Diagrammet viser de overordnede RoS processer. Der er i analysen ikke foretaget yderligere analyse (nedbrydning) af processerne, idet der allerede ligger detaljeret materiale (herunder alle de udledte krav fra processerne) fra de to tidligere projekter. Vi har i dette projekt samlet alle krav i én samlet liste. Denne kan ses i Bilag Konceptuelt oversigtsbillede Hvor der i ovenstående diagram var fokus på forretningsmæssige afhængigheder, er der i det konceptuelle diagram taget udgangspunkt i det systemlandskab, som et kommende RoS system vil skulle indgå i. Side 8 af 13

9 Figur 2: Konceptuelt oversigtsbillede, Oversigtsbilledet opsummerer de samlede forhold, til det systemlandskab, som systemet skal ses i sammenhæng med. 7 Forretningsarkitektur 7.1 Nuværende situation (AS IS) Den nuværende RoS systemunderstøttelse på Laboratorieområdet er dels meget forskellig fra sygehus til sygehus, og dels er der nogle områder, der slet ikke er understøttet, dvs. rekvisition og/eller svar foregår på papir. Der anvendes i dag flere forskellige systemer. På laboratoriespecialerne Biokemi, Immunologi og til en vis grad Mikrobiologi bruges primært BCC-Web 2 til rekvisition og COSMIC eller BCC-Web til svar. Indenfor Patologi, har specialet sit eget system, her anvendes Patoweb til både rekvisition og svar. På Genetik området er der kun minimal systemunderstøttelse, så her anvendes primært papir. I Bilag 5 ses en matrice, der viser den præcise, nuværende systemunderstøttelse. 7.2 Fremtidig situation (TO BE) Harmonisering af brugen af systemerne i Region Syddanmark vil forenkle drift og vedligeholdelse af systemerne, reducere risikoen for fejl af tekniske og brugermæssige årsager og gøre det lettere for kliniske brugere at flytte mellem forskellige sygehuse i regionen og se svar på patienter, som har forløb på tværs af hospitalerne. Dette vil også højne kvaliteten i patientbehandlingen samt øge patientsikkerheden. Derfor skal den fremtidige løsning bygge på en fælles RoS løsning, der understøtter de i afsnit nævnte to forretningsservices for alle laboratoriespecialer, hvortil der hver er knyttet en række krav: 1. Rekvirer analyser. 2. Se svar. 1. Se svar på analyser for en rekvirent/svarmodtager (liste niveau). 2. Se svar på analyser for en patient (kumuleret svar). 3. Kvittér for svar. 2 Ved klassisk mikrobiologi dog enten COSMIC (på OUH og SHS) eller papir Side 9 af 13

10 De overordnede forretningskrav, der skal opfyldes kan formuleres således: Det skal være muligt at rekvirere analyser fra flere laboratorieområder på én gang (Rekvireringssæt) Man skal kunne se en samlet oversigt over undersøgelsesresultater fra flere laboratorieområder på én gang Undersøgelsesresultater skal kunne ses for alle parakliniske specialer på tværs af hospitalerne i Region Syddanmark Der skal være mulighed at læse og dokumentere i patientens journaldata, mens undersøgelsesresultater læses Den samlede detaljerede kravliste findes i Bilag 3. 8 Applikation og integration 8.1 Nuværende applikation og integrationssituation (AS IS) Til brugerne af laboratorieprøver: BCC-Web (Rekvisitioner og svar på blodprøver mm.) COSMIC (Svar på blodprøver mm.(kun OUH)) Patoweb (Rekvisitioner og svar på patologiprøver) Til understøttelse af laboratoriernes produktion: BCC Patologi MADS (x4 - en version for hvert sygehus) Prosang Se også afsnit 7.1. og 8.2 Fremtidig applikation og integrationssituation (TO BE) I det fremtidige systemlandskab vil der kun være ét system til rekvisition og svar for laboratorieområderne. Det betyder, at alle sygehuse skal have det samme systemlandskab bestående af: Til brugerne af laboratorieprøver: LIMS-RoS Til understøttelse af laboratoriernes produktion: BCC Patologi MADS (x4 - en version for hvert sygehus) Prosang Nyt genetik system Det er vigtigt at minimere antallet af integrationer, da det for det første ofte er dyrt at etablere, og for det andet gør løsningen mere kompleks i forhold til drift og vedligeholdelse. Det betyder, at der kun skal etableres de absolut nødvendige integrationer. Tages der udgangspunkt i identificerede databehov og funktionalitet, er nedenstående integrationer et absolut minimum. Alle produktionssystemer skal integrere med LIMS-RoS. For rekvireringer har LIMS-RoS Integration til BCC (leveres med LIMS/RoS) Integration til Patologi (mangler) Integration til MADS (leveres med LIMS/RoS) Side 10 af 13

11 Integration til Prosang (leveres med LIMS/RoS) Integration til Nyt Genetiksystem (mangler) For svar fra produktionssystemerne sendes til LIMS-RoS via REGIS. 9 Teknologi og nødvendig infrastruktur Der har i analysefasen været undersøgt, om en eventuel implementering af en generisk kontekststyring ville give udfordringer. Det vurderes, at med den nuværende projekt-/tidsplan, ikke er muligt at udarbejde en ordentlig analyse af dette. Det er en forudsætning, at hvis man ønsker at introducere en generisk kontekststyring til klinikerne, at dette undersøges bedre, inden en anbefaling gives på, hvordan det kan implementeres. Der er flere faktorer, som understøtter, at en generisk kontekststyring vil kunne give værdi for brugerne. Det siger både analysefirmaet Gartner og andre sygehuse, der har implementeret kontekststyring. Der er flere faktorer som understøtter, at der skal analyseres mere, herunder at nogle producenter har bundet både SSO og kontekststyring sammen. Det betyder, at det skal undersøges nærmere, hvordan den nuværende SSO i ESA vil understøtte dette, eller man står overfor at skulle skifte hele SSO delen ud i tilfælde af, at man ønsker at lave generisk kontekststyring. Der er ligeledes på nuværende tidspunkt ikke noget godt bud på, hvor mange applikationer, der ville skulle understøttes af en generisk kontekststyring, ej heller hvor meget, der skal etableres, for at en kontekststyringskomponent kan implementeres. 10 Arkitekturrisiko (TO BE) Ud fra anbefalingen er følgende risici identificeret: Vurderet risiko Niveau Imødegåelse af risiko CGI s manglende kommentering af RoS løsningsscenarier Lav Projekts arbejdsgruppe har foretaget valg af anbefalelsesværdigt scenarie. Man kan evt. efterfølgende indhente leverandørens kommentarer til det valgte scenarie, og hvis det viser sig at der er ting, der er overset, revurdere anbefalingen. Da LIMS-RoS ikke er i produktion nogen steder, er der endnu ikke en vurdering af den reelle brugeroplevelse, performance osv. Analyseprojekt har ikke haft deltagelse af alle sygehuse, hvorfor opbakning omkring den foreslåede beslutning måske kan blive problematisk. Den gennemførte brugerundersøgelse omkring anvendelsen af RoS løsninger i hverdagen er kun gennemført på et meget begrænset antal brugere, og er derfor måske ikke dækkende for alle klinikere, og den umiddelbare konklusion kan derfor være forkert Lav Der forslås en sekventiel implementeringsstrategi (sygehus for sygehus) så evt. problemer løbende imødegås. Der skal gøres en indsats for, at der løbende oplyses om indsatsen omkring implementering af LIMS-RoS, med fokus på både de kortsigtede og langsigtede mål. Oplysningen skal især målrettes mod de sygehuse, hvor skiftet til LIMS-RoS vil opfattes som en stor omvæltning, dvs. dem der i dg ser svar i COSMIC. Projektet er i konklusionen gået ud fra at der er behov for to-vejs-kontekststyring, og at dette vil være en forudsætning for at forbedre brugervenlighed og sikre patientsikkerhed. Side 11 af 13

12 11 Referencedokumenter Dokumentnavn [Regionens it-principper]. Findes som bilag til regionens strategi for sundheds-it på: Forfatter Afdeling for sundheds-it Strategi for sundheds-it, se Afdeling for sundheds-it 12 Bilagsoversigt Følgende bilag knytter sig til Arkitekturbeskrivelsen og uddyber i detaljer, de ting, der er beskrevet i rapporten: Bilag nummer Bilag 1 Bilag 2 Bilag 3 Bilag 4 Bilag 5 Beskrivelse Grundlag for analysen: Projektforslag: Rekvisitioner og svar i RSD MasterROS.Projektforslag.SLB.OUH.SITv01.01.pdf ents/usit%20materiale/masterros.projektforslag.slb.ouh.sitv01.01.pdf Scenariebeskrivelser: Scenarier for it understøttelse af Rekvisition og Svar RosScenarie_v med fordele og ulemper for scenarie 1-5 FE.docx ents/usit%20materiale/rosscenarie_v%2001%2000%20med%20fordele%20og%20ulemper %20for%20scenarie%201-5.docx Samlet kravlist: Klinikernes ønsker/behov til funktionalitet ifm. Rekvisition til og svar fra parakliniske specialer Klinikernes ønsker til RoS-funktionalitet ver. 1.0.docx ents/usit%20materiale/klinikernes%20ønsker%20til%20rosfunktionalitet%20ver.%201.0.docx Konklusion på interviewrunde: Afdækning af brugsmønstre / arbejdsgange i arbejdet med rekvisition og svar Afdækning af brugsmønstre og arbejdsgange i arbejdet med rekvisition og svar.docx ents/usit%20materiale/afdækning%20af%20brugsmønstre%20og%20arbejdsgange%20i%2 0arbejdet%20med%20rekvisition%20og%20svar.docx AS-IS systemunderstøttelse: Nuværende systemunderstøttelse af RoS-funktionalitet for de enkelte laboratorieområder Matrice - Systemunderstøttelse på RoS AS-IS - v01.00.docx ents/usit%20materiale/matrice%20-%20systemunderstøttelse%20på%20ros%20as- IS%20-%20v01.00.docx Side 12 af 13

13 Bilag nummer Bilag 6 Beskrivelse Kravopfyldelse ved de enkelte scenarier: RoS kravopfyldelse med kommentarer for scenarie 1-5 RoS-scenarier kravsopfyldelse med kom. scenarie aspx?id=/rekvisitioner%20og%20svar%20i%20rsd/project%20documents/usit%20materia le/ros-scenarier%20kravsopfyldelse%20med%20kom.%20scenarie%201-5.xlsx&source=http%3a%2f%2fleverancesystem%2ersyd%2enet%2frekvisitioner%2520og %2520Svar%2520i%2520RSD%2FProject%2520Documents%2FForms%2FAllItems%2Easpx %3FRootFolder%3D%252FRekvisitioner%2520og%2520Svar%2520i%2520RSD%252FProje ct%2520documents%252fusit%2520materiale%26folderctid%3d0x ad304c 9DB43A5AEECE077C39661%26View%3D%7BF764C609%2DF009%2D45E8%2D8D0B%2D 37A93AE4EA60%7D%26InitialTabId%3DRibbon%252ELibrary%26VisibilityContext%3DWSS TabPersistence&DefaultItemOpen=1&DefaultItemOpen=1 Side 13 af 13