Arkitekturbeskrivelse, Øjenområdet

Transkript

1 Arkitekturbeskrivelse, Øjenområdet Dokumentidentifikation Projekt id Projekt titel Projektleder Systemejer/projektejer Projektregi Projektidentifikation RØS Analyse i Region Syddanmark. Projektleder: Heidi Graversen Niels Nørgaard, Sygehus Lillebælt Sæt kryds RSI / NSI Regional Lokal x Sygehus Lillebælt Applikationsansvarlig enhed Deltagende enheder Region Syddanmark Systemejer Øjen afdelinger fra OUH, SLB og SHS Sundheds-IT Regional IT Projektets varighed Udarbejdet dato Udarbejdet af Trine Hynkemejer, Mikkel Senniksen (Henning Markussen) Revisionshistorik Version Dato Beskrivelse Navn Oprettelse af dokument Trine Hynkemejer Intern review af dokument rettelser indarbejdet. Trine Hynkemejer Distributionsliste Navn Dato Version Systemejer xx Projektgruppe xx Side 1 af 26

2 Indhold 1. Vejledning Indledning Referencedokumenter Ordliste og forkortelser Baggrund og opsummering Baggrund og formål Projektets målgruppe og hovedinteressenter Samlet arkitektvurdering opsummerende konklusioner Arkitektur Vision Opsummeret konklusion Forslag videre proces Analysens metodik og struktur Udmøntning af metoden Analysens udgangspunkt Overordnet proces diagram Konceptuelt oversigtsbillede Forretningsarkitektur Nuværende situation (as-is) Fremtidig situation (to-be) Forretningsprocesser beskrivelser Databehov Nuværende databehov (as-is) Fremtidige databehov (to-be) Applikation og integration Nuværende applikation- og integrationssituation (as-is) Fremtidig applikation- og integrationssituation (to-be) Teknologi og nødvendig infrastruktur Udveksling med medicoteknisk udstyr og 3. parts software Storage, database og server Service Level Arkitekturrisiko (to-be) Bilagsoversigt Bilag 1: Scenarier for it understøttelse af øjenafdelinger Bilag 2: Oversigt over Use Case Bilag 3: Use cases Side 2 af 26

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 I maj 2014 blev det besluttet, at der skulle igangsættes en analyse på øjenområdet, hvor arbejdsgange, snitflader og eksisterende løsninger skulle identificeres. Dette med henblik på, at fremkomme med mulige scenarier for en evt. videre anskaffelsesproces. SLB har i tæt samarbejde med projektgruppen, Regional IT og Sundheds IT drevet den overordnede proces, med at afklare forretningens behov til en løsning, hvor arbejdsprocesserne systemunderstøttes, snitflader til det øvrige systemlandskab identificeres og medicotekniske opkoblinger afdækkes. 3. 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 4. Ordliste og forkortelser Ordliste og forkortelser RØS COSMIC EG Clinea Forklaring Regionalt øjensystem Den regionale version af Region Syddanmark elektroniske patientjournal. EG Healthcare har opkøbt software leverandøren EMAR, øjensystemet blev tidligere kend som EMAR men benævnes nu EG Clinea Side 3 af 26

4 5. Baggrund og opsummering 5.1 Baggrund og formål Nærværende arkitekturvurdering udføres i forbindelse med gennemførelse af en it analyse på øjenområdet i Region Syddanmark. Projektledelsen varetages af Sygehus Lillebælt, og er igangsat af udvalg for Sundheds-it. Analysens formål er ud fra USIT s beslutning, at afdække hvorvidt nedenstående scenarier kan blive en realitet inden for en rimelig tidshorisont. Analysen skal jvf. Sundheds IT strategien forholde sig til følgende 2 scenarier. 1. Best of suite : Kan forretningens, arbejdsgange og medicotekniske opkoblinger understøttes inde for rammerne af COSMIC. Virkning: Der udvikles et nyt øjenmodul i COSMIC. 2. Best of breed : Kan forretningens, arbejdsgange og medicotekniske opkoblinger understøttes inde for rammerne af allerede eksisterende øjensystem. Virkning: Der anskaffes et allerede eksisterende øjensystem, med snitflader til COSMIC PAS, til medicoteknisk udstyr og Notatservice. Formålet med analysen er således at sikre et fagligt veldokumenteret grundlag for at kunne etablere et egentligt projekt med henblik på en ensartet it understøttelse. Som input til afgrænsning udarbejdes nærværende arkitekturvurdering med udgangspunkt i interessenternes konkrete forretningsbehov til at understøtte arbejdsgangene. Arkitekturanalysen vil endvidere afdække behovet for snitflader til omkringliggende applikationer og komponenter. I analysen vurderes den nuværende situation (as-is) efterfulgt af den fremtidige situation for området (to-be). Konklusionerne er opsummeret først i arkitekturbeskrivelsen. 5.2 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 Middel Projektgruppe Plan, Aktiviteter, Milepæle Lav Høj Regional-it Infrastruktur arkitektur Høj Middel Klinisk personale på øjenafdelingerne i RSD Funktionalitet og arbejdsgange Høj Høj Sundheds-it Forretnings- og applikations arkitektur Høj Middel Medicoteknik Opkobling til Instrumenter Lav Lav Side 4 af 26

5 6. Samlet arkitektvurdering opsummerende konklusioner Afsnittet beskriver den samlede arkitektur vision, dokumentets hovedkonklusion samt et forslag til den videre proces. 6.1 Arkitektur Vision Visionen er at skabe en sammenhængende digitaliseret klinisk arbejdsplads, der understøtter personalet på øjenafdelingerne i forhold til de identificerede arbejdsgange. Visionen er således, understøttelse af en ensartet digitaliseret arbejdsgang, eliminere behov for dobbeltregistrering i form af overførsel af medicotekniske data, samt sikre at data deles på tværs af regionens sygehusenheder. Samlet vil det konkret betyde et stort kvalitets- og sikkerhedsmæssigt løft for både patienter og det kliniske personale. Endvidere forventes en effektivisering af interne arbejdsgange og patientflow. Skal denne vision indfries, med udgangspunkt i det eksisterende systemlandskab, Sundheds it strategien og it-principperne er der reelt 2 mulige scenarier. Scenarierne er i forbindelse med analysen blevet belyst ud fra fordele og ulemper og endvidere fremstillet i forhold til fem perspektiver. Beskrivelse af mulige scenarier kan læses i sammenhæng i bilag Opsummeret konklusion Forretningens behov er identificeret ved 4 primære forretnings services, som et øjensystem skal kunne håndtere: 1. Udfør forundersøgelse (med opkobling til medicoteknisk udstyr) 2. Udfør undersøgelse (supplerende), (med opkobling til medicoteknisk udstyr) 3. Udfør behandling, (med opkobling til medicoteknisk udstyr) 4. Udfør kontrolbesøg (med opkobling til medicoteknisk udstyr) Som beskrevet i afsnit 6.1 vurderes det ud fra analysen, at der er 2 mulige scenarier til it-understøttelse af øjenafdelingernes forretningsbehov: Nedenstående scenarier vil, på forskellig vis og med forskelligt tidsperspektiv, kunne understøtte forretningens behov, ligesom de vil kunne udmøntes inde for rammerne af Sundheds-it strategien, herunder It-principperne, og kan således anbefales af arkitekturfunktionen. 1.Scenarie: COSMIC 7.5 inkl. ny konfiguration + Apparaturintegration gennem 3. parts software til COSMIC Der har været afholdt et afklarende møde med leverandøren, som indikerer, at mulighederne for procesunderstøttelse i COSMIC, ikke er udnyttet i den nuværende konfiguration til øjenafdelingerne (OUH og SHS). Scenariet omfatter derfor en ny konfiguration i COSMIC, der er arbejdsgangsunderstøttende, samt at der etableres nødvendige integrationer fra apparatur gennem 3. parts software til COSMIC. Hvilket vil sige, at der skal anskaffes et 3. parts software, for at kunne integrerer medicotekniske data. Opsummerende konklusion: Den umiddelbare fordel ved scenarie 1 er, at det opfylder det langsigtede mål om COSMIC som strategisk platform. Der skal dog gennemføres en egentlig gap-analyse, hvor udfaldet og udfrdringer aktuelt ikke kendes. Imidlertid er to store udfordringer ved denne løsning identificeret: (1) Om-konfiguration af øjenforløb i COSMIC og (2) Integration af apparatur. Der vil skulle findes ressourcer, der kan konfigurere COSMIC, og der skal findes 3. parts software til at kommunikere data mellem (både til og fra) apparatur og COSMIC, da der ikke er udsigt til, at dette vil blive standardfunktionalitet i COSMIC foreløbig. Der er konstateret flere usikkerheds-faktorer i COSMIC leverancerne, der i dette projekt hidrører manglende kapacitet til at gennemføre omkonfigurering. Ligesom tidsperspektivet for en løsning er usikker. 2. Scenarie: Administrativ proces i COSMIC og klinisk proces i Øjensystem COSMIC PAS anvendes til modtagelse af henvisning samt visitering af patienter, herefter anvendes øjensystem til booking, ankomstregistrering, flowstyring og dokumentation af den kliniske proces. Patientens medicin dokumenteres i COSMIC, ligesom afsluttende administrative processer omkring epikriser og LPR Side 5 af 26

6 indberetninger håndteres gennem COSMIC. Der udestår en afklaring af hvilke informationer der i forbindelse med patientdokumentation skal overføres til COSMIC gennem Notatservice. Opsummerende konklusion: Fordelene ved scenarie 2 er mange. Løsningen procesunderstøtter umiddelbart øjenområdet både relateret til administrative og kliniske processer og er dermed det scenarie, som hurtigt vil kunne realisere en forretningsmæssig værdi. Scenariet understøtter en løs kobling, som sikrer, at øjensystemet på sigt vil kunne udskiftes eller erstattes af COSMIC funktionalitet. Integrationen mellem øjensystemet og COSMIC er enten allerede etableret eller handler om en simpel mapning af data, der forventes, at kunne løses vha. den eksisterende Notatservice. Al integration til/fra apparatur vil ske gennem øjensystemet. 6.3 Forslag videre proces Procesforslag fra arkitekturteamet er følgende: At der nedsættes et projekt, der har ansvaret for en udbudsproces, der omfatter anskaffelse af en øjenløsning, som understøtter de 4 primære forretningsservices At der udarbejdes en kravspecifikation, hvor der o Beskrives funktionelle krav, bl.a. ud fra allerede udarbejdede use cases. o Beskrives non-funktionelle krav (servicemål, arkitektur etc.) o Beskrives snitflader til medicoteknisk udstyr, som skal opkobles og understøttes af løsningen o Beskrives testcases, bl.a. ud fra allerede udarbejdede use cases o Udarbejdes specifikation af, hvilke informationer, der skal udveksles mellem relevante applikationer. 7. Analysens metodik og struktur Forretningsarkitekturen anskues som et hierarki, der består af 5 niveauer. Niveauerne beskriver forskellige abstraktionsniveauer for forretningsdomænet. Identificeringen af de 5 niveauer er nødvendige, for at kunne koble den teknologiske arkitektur på forretningsarkitekturen efterfølgende. 1. Formål og vision er, organisationens formål og vision som en helhed. Dette er mål i højeste abstraktion og kan ses som organisationens miljø for selvforståelse af kvalitet. 2. Forretnings service er en refleksion af de ovenstående formål og visioner, dog i en mere konkret overvejelse om realiseringen af forretningsområdet. Hvad er det for nogle service forretningsdomænet udstiller/tilbyder til andre samarbejdspartere. Antallet af services kan variere fra én enkelt service til flere sammenhængende services. 3. Forretnings processer, er en samling af flere flow aktiviteter. Processerne er generelle og velkendte termer i arbejdsdomænet. I klinisk sammenhæng er det typisk arbejdsgange eller hændelser som f.eks. gå stuegang, udfør konsultation, udfør analyse, etc. 4. Forretnings funktioner er den konkrete forretningsproces brudt ned i enkelt elementer funktioner. F.eks. Læs notat, registrer samtale, dokumenter plan, modtag prøve, registrer prøve etc. 5. Fysiske objekter og opgaver. Kan være prototyper, dokumenter, skærmbilleder eller konkrete beskrivelse af hvad der skal registreres af data. Når de 5 niveauer er identificeret og dokumenteret, har man grundlaget for at kunne beskrive applikationsog infrastrukturlaget. Analysen vil overordnet beskrive disse to arkitekturlag, der vil skulle belyses og beskrives mere detaljeret i en anskaffelsesfase. 7.1 Udmøntning af metoden Analysen er udarbejdet med udgangspunkt i 3 workshops med deltagelse af klinisk personale fra OUH SHS og SLB. Procesmodelleringen er udarbejdet i Archimate notationen, som er anvendt til overordnet at Side 6 af 26

7 visualisere de 3 arkitekturlag (forretnings-, applikation-, og infrastrukturlag) inden for de 4 overordnede forretningsservices. Forretnings-arkitektur Udfør forundersøgelse Udfør undersøgelse (supplerende) Udfør behandling Udfør kontrolbesøg Informations- og applikationsarkitekturen Udfør forundersøgelse Udfør undersøgelse (supplerende) Udfør behandling Udfør kontrolbesøg Infrastrukturarkitekturen Udfør forundersøgelse Udfør undersøgelse (supplerende) Udfør behandling Udfør kontrolbesøg Figur 1: Viser analysens nedbrydning i 3 arkitekturlag Hver forretningsservice er følgende brudt ned i forretningsprocesser og funktioner. Der slutteligt er beskrevet i form af Use cases (se bilag 3). Forretningsfunktioner skal i en kommende anskaffelsesfase yderligere analyseres og kvalificeres i form af funktionelle krav. 8. Analysens udgangspunkt For at kunne opfylde de opstillede visioner omkring datasammenhæng samt kliniske sammenhænge, er der taget udgangspunkt i en normalproces for grøn- og grå stær, da disse prøver udgør størstedelen af undersøgelserne og behandlingerne på øjenafdelingerne. Ligeledes vil disse forløb kunne rumme andre typer af undersøgelser på afdelingen. Med udgangspunkt i disse processer og i dialogen på de afholdte workshops, har det været muligt at identificere følgende: Hvilke aktører, roller, forretningsservices, forretningsprocesser og forretningsfunktioner. Hvilke overordnede funktioner, der fremadrettet ønskes understøttet Hvilke applikationer og integrationer, der er involveret. Hvilke medicotekniske apparaturer, der skal understøttes. Hvilke snitflader, der skal beskrives følgende i projektet. I analysen udestår konkret at identificere hvilke data der, afhængigt af valget af løsning skal udveksles. I analysen har der i første omgang været fokus på forretningsprocesser, forretningsfunktioner og data, som skal understøttes i forbindelse arbejdsgangene på øjenafdelingerne. Efterfølgende er analyseret, hvordan dette hænger sammen med resten af applikationslandskabet og ikke mindst, om den ønskede funktionalitet kan understøttes af eksisterende løsninger i RSD. De beskrevne processer skal detaljeres, forfines og evt. suppleres med andre flows i det videre forløb. 8.1 Overordnet proces diagram Nedenstående diagram viser overordnede processer, hvor svømmebanerne illustrerer faglige/professionelle skel. Processerne, der er identificeret, skal fremadrettet understøttes af et kommende øjensystem. Omdrejningspunktet er processen Undersøgelse og Behandling, da der her gennem et besøg kan ligge mange undersøgelser under samme kontakt Side 7 af 26

8 Figur 2: Diagrammet viser de processer, der af forretningsdomænet ønskes understøttet af et kommende øjensystem. Side 8 af 26

9 8.2 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 øjensystem vil skulle indgå i. Figur 3: Konceptuelt oversigtsbillede, Oversigtsbilledet opsummerer de samlede forhold, til det systemlandskab som øjensystemet skal ses i sammenhæng med. 9. Forretningsarkitektur 9.1 Nuværende situation (as-is) Regionens øjenafdelinger omfatter følgende sygehusenheder, Sygehus Lillebælt (SLB), Sygehus Sønderjylland (SHS) og Odense universitetshospital (OUH). Her er der er i store træk et ensartet billede af forretningsprocesserne, dog med en variation af kompleksitet, og behov for samarbejde med andre specialer/afdelinger. Aktuelt it-understøttes afdelingerne forskelligt, OUH, anvender i dag COSMIC, til dokumentationsdelen, DIPS til at flowstyre patienterne og forskellige apparatursoftware til at tilgå målinger og grafer. SHS anvender ligeledes COSMIC (lokal platform) til dokumentation og forskellige apparatursoftware til at tilgå målinger og grafer. Fælles for de to enheder er, at de manuelt overfører relevante data fra eksternt apparatur software til COSMIC. Ligeledes anvendes COSMIC med de standardskabeloner, som initialt blev implementeret for 8 år siden, og som ikke nødvendigvis understøtter afdelingen i den reelle arbejdsproces i dag. SLB anvender i dag EG CLINEA, et specialespecifikt øjensystem, som derfor er tilpasset øjenafdelingens arbejdsgange. EG CLINEA er integreret med C-PAS. Booking foregår i EG CLINEA, der sender booking svaret til COSMIC. Øjensystemet har en del kontekstbærende links til apparatursoftware, såkaldte dybe links og 4-5 apparatur integrationer, hvor apparaturet sender data til EG CLINEA, og EG CLINEA sender i enkelte tilfælde data til apparatur. Systemet understøtter ligeledes ankomstregistrering og overblik over, hvor lang patienten er i forløbet på dagen (flowstyring). Side 9 af 26

10 9.2 Fremtidig situation (to-be) På baggrund af analysen er der, som angivet i afsnit 6.2 identificeret 4 forretningsservices som systemet skal understøtte: Figur 4: 4 Forretningsservices for øjenområde Analysen har vist, at processerne er ensartede på tværs af sygehus enheder, dog kan der kan være variationer i hvilken rolle, der på hhv. SHS, OUH og SLB varetager processerne, hvilket angives i beskrivelsen af de enkelte processer. Herved sikres, at forskelligheder mellem afdelingerne dokumenteres og håndteres. Ligeledes er der variation af samarbejde med andre afdelinger på de enkelte sygehusenheder. Forskellighederne afdelingerne imellem, vurderes ikke at have systemmæssige konsekvenser Roller Rolle Sekretær Sygeplejersker Læge IT-system administrator Beskrivelse Sekretæren har ansvaret for patientadministrative processer og bookning af patienter. Det kan i forskellige tilfælde være sygeplejerske der håndtere booking. Sygeplejersken varetager undersøgelser, behandling og fotografering af patienter. Fotografering varetages ligeledes af fotograf. Sygeplejersken er ansvarlig for dokumentation. Lægen varetager den egentlige konsultation med Patienten (undersøgelse og behandling), og han/hun er ansvarlig for dokumentation af behandling og undersøgelse. Lægen er ligeledes ansvarlig for visitation. IT-systemadministrator varetager løbende opsætning og konfiguration af øjensystemet Rolle / Funktions matrix Matricen nedenfor beskriver fagpersoner, der varetager hvilke funktioner. De enkelte steps under nedenstående funktioner er yderligere beskrevet nedenfor og desuden i Use cases, Bilag 4. Roller Funktion Sekretær Læge Sygeplejerske Administrator Modtag henvisning Visiter henvisning Book patient Indkald patient Udlever mødetid Registrer patientankomst Side 10 af 26

11 Roller Funktion Sekretær Læge Sygeplejerske Administrator Håndter kørselsgodtgørelse Undersøg patient Dokumenter undersøgelse Dokumenter medicin Forbered patient til behandling Udfør behandling på patient Dokumenter behandling Vurder og planlæg videre behandling Håndter befordring Kontroller og signer procedurekoder Send epikrise Afslut behandlingsforløb Konfigurer fraser Konfigurer opslagstabeller Konfigurer patientforløb Konfigurer kø funktion Tabel 1: Rolle / funktions matrix skitserer hvilke roller der varetager hvilke forretningsfunktioner Funktions- / Applikationsmatrix Nedenfor er en matrice over forretningsprocesser i forhold til Applikationer. Efterfølgende er der en kort beskrivelse af hver af processerne og de underliggende forretningsfunktioner. Funktions / Application matrix Tabellen nedenfor viser hvilke forretningsfunktioner, der er identificeret i analysen. Endvidere viser tabellen hvilke applikationer, der fremadrettet anbefales til understøttelse af forretningsfunktionerne. De rækker hvor der fremkommer to krydser indikere at der skal etableres snitflader, mellem de forskellige applikaitoner. Symbolforklaring: Grønne felter indikerer at der er etableret integration mellem øjensystem og COSMIC. Røde felter indikerer at der ikke er etableret integration. Applikation PAS* Forretningsfunktioner Øjensystem COS- MIC EPJ Digital Post Befordring Apparatur SW Middelware Modtag henvisning () Side 11 af 26

12 Applikation PAS* Forretningsfunktioner Øjensystem COS- MIC EPJ Digital Post Befordring Apparatur SW Middelware Visiter henvisning () Book patient * () Send indkaldelse Udlever mødetid Registrer patientankomst Håndter kørselsgodtgørelse Undersøg patient Dokumenter undersøgelse Dokumenter medicin () Forbered patient til behandling Udfør behandling på patient Dokumenter behandling () Vurder og planlæg videre behandling Håndter befordring Kontroller og registrer () procedurekoder Send epikrise () Afslut forløb () Konfigurer fraser Konfigurer opslagstabeller Konfigurer patientforløb Konfigurer kø funktion Tabel 2: Forretningsfunktion / applikations matrix skitserer hvilke forretnings funktioner, der understøttes af hvilke applikationer. Herved fremgår snitflader mellem applikationer tydeligt *3 forskellige PAS systemer i Region Syddanmark: SLB C-PAS, OUH F-PAS, SHS Opus-PAS Side 12 af 26

13 9.2.4 Forretningsservice nedbrudt i processer Nedenstående diagrammer viser de 4 forretningsservices (fra Figur 4) nedbrudt i forretningsprocesser og funktioner, samt hvad der trigger processerne. Slutteligt i afsnittet er indholdet for hver proces alfabetisk beskrevet Udfør forundersøgelse Patienten kommer til forundersøgelse med henblik på at blive undersøgt 1. gang. Som det ses af diagrammet kan en forundersøgelse trigge, en ny undersøgelse, en kontrol undersøgelse eller en behandling. Alternativt afsluttes patienten. Figur 5: Viser forretningsprocesser for en forundersøgelse Side 13 af 26

14 9.2.6 Udfør undersøgelse (Supplerende) Udfør supplerende undersøgelse beskriver en sammenhængende proces, hvor patienten kommer til en fornyet undersøgelse inden en eventuel behandling. Alternativt afsluttes patienten. Forskellen fra ovenstående proces er i forbindelse med bookningen af patienten og udlevering af tid til patienten. Figur 6: Viser forretningsprocesser for en supplerende undersøgelse (f.eks. forud for en operation) Side 14 af 26

15 9.2.7 Udfør behandling Inden en behandling har patienten altid været til en forundersøgelse, supplerende undersøgelse eller kontrol. Patienten er her blevet vurderet til behandling. Udfør behandling vil altid trigge en kontrol af patienten. Figur 7: Viser forretningsprocesser for kirurgisk- og medicinsk behandling Side 15 af 26

16 9.2.8 Udfør kontrol Patienten har været til medicinsk eller kirurgisk behandling og er vurderet til kontrol. Udfør kontrol kan trigge en ny kontrol eller en ny behandling. Udfør kontrol vil normalt ende med at Patienten afsluttes. Alternativt kan der trigges en ny kontrol eller en ny behandling. Figur 8: Viser forretningsprocesser for et kontrolbesøg Administrer øjensystem En væsentlig del af understøttelsen i øjensystemet forudsætter, at systemet er konfigureret korrekt efter afdelingernes behov. Figur 9: Viser processer til understøttelse af systemets opsætning og konfiguration Side 16 af 26

17 9.3 Forretningsprocesser beskrivelser Nedenfor er samtlige processer beskrevet med navnet på ovenstående proceskasser og efterfølgende med en beskrivelse af hvad processen omhandler Processer Navn Afslut behandling Afslut behandlingsforløb Afslut undersøgelse Behandl patient Book patient Dokumenter behandling Dokumenter medicin Dokumenter undersøgelse Forbered patient til behandling Forundersøg patient Håndter befordring Håndter kørselsgodtgørelse Indkald patient Kontroller og signer procedurekoder Beskrivelse I processen Afslut behandling verificeres procedurekoder og besked sendes til patientens praktiserende læge. Der justeres (tilføjes eller slettes) og til slut signeres, så procedurekoderne overføres til COSMIC Hvis det vurderes at den aktuelle konsultation er patientens sidste, registreres det, at hele behandlingsforløbet nu er afsluttet. I processen Afslut undersøgelse registreres procedurekoder og besked sendes til patientens egen læge. Hvis det også er afslutningen på hele behandlingsforløbet, registreres dette. I processen behandl patient forberedes patienten til behandling, selve behandlingen (evt. operation) gennemføres og behandlingen, samt evt. ordineret medicin dokumenteres. Sekretær eller Sygeplejerske finder en tid til patienten. Når patienten har være til undersøgelse, behandling eller kontrol og skal komme igen får patienten typisk en tid "med i hånden" når patienten går fra afdelingen. Ofte bookes der flere tider på én gang (f.eks. både behandlingstid og kontroltid). Det registreres, at de pågældende behandling har fundet sted, og resultat og konklusion gemmes ligeledes. Såfremt patienten ordineres noget medicin vil dette blive registreret. Det registreres, at de pågældende undersøgelse har fundet sted, og resultat og konklusion gemmes ligeledes. Sygeplejersken forbereder patienten til behandling, f.eks. operation. I processen Forundersøg Patient sker selve undersøgelsen af patienten. Der kan være tale om, at patienten skal flere forskellige undersøgelser, før forundersøgelsen er afsluttet. Efter undersøgelserne dokumenteres disse, sammen med evt. konklusioner, ligesom det dokumenteres hvilken medicin der evt. ordineres. Til slut vurderes og planlægges det videre behandlingsforløb, f.eks. evt. behandling/operation og kontrol. I forbindelse med patientens afslutning af besøg bliver behovet for evt. hjemtransport af patienten fastlagt. Dette afgøres bl.a. ud fra den undersøgelse/behandling patienten har gennemgået og patientens ønsker. Hvis der er behov for hjemtransport bestilles denne af sekretæren. Patienten afleverer udfyldt skema for kørselsgodtgørelse og sekretæren registrer data i kørselsgodtgørelsessystem. I processen Indkald patient bookes patienten til forundersøgelse, behandling eller kontrol. Der sendes indkaldelse til Patienten i forbindelse med den første undersøgelse, patienten vil her modtage indkaldelsen digitalt eller pr. post. Når patienten bookes til behandling eller kontrol, vil patienten oftest få en fysisk seddel med en tid på, med i hånden. Det kontrolleres at alle aktuelle procedurekoder for behandlingen er registreret. Der justeres (tilføjes eller slettes) og til slut signeres, så procedurekoderne overføres til COSMIC. Side 17 af 26

18 Navn Kontroller patient Modtag henvisning Modtag indkaldelse Modtag patient Registrer patientankomst Send epikrise Udfør behandling på patient Udlever Mødetid Undersøg patient Visiter henvisning Visiter patient Vurder og planlæg videre behandling Beskrivelse I processen Kontroller patient undersøges patienten igen som opfølgning på en behandling/operation eller en forundersøgelse. Resultat af undersøgelsen og evt. ordineret medicin dokumenteres og evt. videre forløb (behandling/operation eller nyt kontrolbesøg) vurderes og planlægges. Elektronisk henvisning af patient modtages (af Sekretær), og der assignes en modtager (Læge eller Sygeplejerske) til at foretage en visitering. Patienten modtager indkaldelsen til forundersøgelse, behandling (kan være operation) eller kontrol. Hvis tidspunktet ikke passer patienten, har han/hun mulighed for at ændre tiden. I så fald gentages processen Book patient og Indkald patient, dvs. man annullerer den bookede tid og starter forfra på processen Indkald patient ved Book Patient. I processen Modtag patient møder patienten op til Forundersøgelse, Behandling eller Kontrol, og modtages (registreres). I processen håndteres også patientens evt. behov for hjemtransport. Patientens ankomst registreres. Dette kan enten ske manuelt eller ved at patienten benytter sit sygesikringskort i en ankomstterminal. Epikrise sendes til patientens praktiserende læge (eller evt. anden afdeling, hvor patienten er henvist fra) Lægen foretager behandlingen af patienten. Det kan være medicinsk eller kirurgisk behandling (operation). Sekretær eller Sygeplejerske udlever mødekort med den bookede tid til patienten. Dette sker evt via udskrivning af en "mødetidsbon". Patienten får således sin tid til supplerende undersøgelse, behandling (evt. operation) eller kontrol "med i hånden" når han/hun forlader Øjenafdelingen. Ofte udleveres der flere tider på én gang (f.eks. både behandlingstid og kontroltid). Patienten gennemgår den planlagte undersøgelse, f.eks. trykmåling. Patienten skal muligvis gennemgå flere undersøgelser, den egentlige forundersøgelse, dvs. processen Undersøg patient gentages. Undersøgelser skal her ses bredt, en "undersøgelse" kan f.eks. være fotografering af øjnene eller drypning af øjne som forberedelse til en anden undersøgelse. Læge eller Sygeplejerske visiterer henvisningen. Det videre forløb defineres (rækkefølge og tidshorisont) og ønskede undersøgelser/prøver noteres. Behandlingsforløbet registreres. I processen Visiter patient modtages henvisning, og der sker en visitering af den. Ud fra denne vurdering vælges behandlingsforløb. Ud fra resultaterne af undersøgelserne vurderes patientens videre forløb. Det kan f.eks. være yderligere undersøgelse, operation og/eller kontrolbesøg. Hvis Patientens forløb allerede er fastlagt og booket, og Lægen ikke finder anledning til at ændre i dette, vil vurderingen ikke trigge nye aftaler Beskrivelse af konfigurationsmæssige processer Navn Administrer Øjensystem Opret / rediger skabelon Beskrivelse Denne proces er en samling af de systemadministrative funktioner, der er nødvendige for at øjensystemet kan fungere. Man kan også kalde processen for vedligeholdelse af systemets stamdata. Systemadministrator kan ændre i og tilføje nye skabeloner ud fra de behov, der opstår for svar mv. Side 18 af 26

19 Navn Opret / rediger standardfrase Opret / rediger element /betingelse i opslagstabel Opret / rediger Bruger Beskrivelse Systemadministrator kan ændre i og tilføje nye standardfraser ud fra de behov, der opstår. Systemadministrator kan ændre i og tilføje nye elementer/betingelser ud fra de behov, der opstår. Systemadministrator kan ændre i og tilføje nye Brugere og rettigheder til disse ud fra de behov, der opstår Begivenheder - triggers Navn Patient vurderet til behandling Patient vurderet til fornyet undersøgelse Patient vurderet til kontrol Øjenafdeling modtager henvisning Beskrivelse Den trigger, der sætter en øjenbehandling/øjenoperation i gang, er, at en patient efter forundersøgelse (eller kontrol) bliver vurderet til at skulle behandles. Den trigger, der sætter en fornyet undersøgelse i gang, er, at en patient efter Forundersøgelse bliver vurderet til at skal komme til en fornyet undersøgelse. Undersøgelsen kan også være et led i forberedelserne til en operation. Den trigger, der sætter en kontrol af patienten i gang, er at en patient efter en operation automatisk indkaldes til et kontrolbesøg senere. En vurdering ved et kontrolbesøg kan også initiere et nyt kontrolbesøg. Den trigger, der sætter en forundersøgelse i gang er modtagelsen af en henvisning, typisk fra en praktiserende øjenlæge. Henvisningen modtages elektronisk. Side 19 af 26

20 10. Databehov Det er nødvendigt, at der etableres en ensartet systemunderstøttelse og registreringspraksis på tværs af regionen, og at der etableres de nødvendige datasammenhænge og dermed et sammenhængende elektronisk patientforløb, så dobbeltregistrering og kopiering af data mellem systemer og medicotekniske opkoblinger minimeres Nuværende databehov (as-is) Data der i dag registreres i forbindelse med øjenundersøgelser og behandlinger, er meget forskelligartede, idet registreringerne foregår i forskellige systemer. Andre data dokumenteres struktureret, men som tidligere beskrevet i forskellige systemer Fremtidige databehov (to-be) Nedenfor gennemgås, hvilke data der er behov for at anvende i forbindelse med en eventuel anskaffelse af et øjensystem. Endvidere ses, hvor data i dag forefindes, og hvor der således er identificeret snitflader. Patientidentifikation Patientens data som cpr, navn, adresse, etc. Disse data hentes og opdateres via Regionens CPR-komponent. Organisationsdata Sygehusenes Organisation Register (SOR), der beskriver Region Syddanmarks organisationsregister. Disse data hentes og opdateres i Regionens SOR-komponent, der opdateres løbende. Patientdata Patientdata omhandler kliniske data, som er tilknyttet patienten. Disse data findes som udgangspunkt i COSMIC og skal tilgås via COMIC. I tilfælde med hvor dele af patientens data findes i et specialespecifikt system skal et minimums datasæt defineres og overføres til COSMIC Data fra apparatur Data fra realtidsopkoblinger fra medicoteknisk udstyr og apparatur Patientsamtykke Der skal gives patientsamtykke. Dette registreres i COSMIC og skal tilgås via COSMIC, eller oplysninger skal overføres. I tilfælde med specialespecifikke systemer skal det sikres at patientsamtykke er registreret korrekt. Forskningsdata På baggrund af data fra øjenafdelingerne, skal det være muligt at opsamle og lave udtræk af data, så disse kan anvendes i forskningsøjemed. 11. Applikation og integration 11.1 Nuværende applikation- og integrationssituation (as-is) Aktuelt it-understøttes afdelingerne forskelligt, OUH, anvender i dag COSMIC, til dokumentationsdelen, DIPS til at flowstyre patienterne og forskellige apparatursoftware til at tilgå målinger og grafer. SHS anvender ligeledes COSMIC (lokal platform) til dokumentation og forskellige apparatursoftware til at tilgå målinger og grafer. Fælles for de to enheder er, at de manuelt overføre relevante data fra ekstern apparatur software til COSMIC. Ligeledes anvendes COSMIC med de standardskabeloner, som initialt blev implementeret for 8 år siden og som ikke nødvendigvis understøtter afdelingen i den reelle arbejdsproces i dag. SLB anvender i dag EG CLINEA, der er et specialespecifikt øjensystem og som derfor er tilpasset øjenafdelingens arbejdsgange. EG CLINEA er integreret med C-PAS. Booking foregår i EG CLINEA, der sender booking svaret til COSMIC. EG CLINEA har en del kontekstbærende links til apparatursoftware, såkaldte dybe links og 4-5 apparatur integrationer, hvor apparaturet sender data til EG CLINEA og EG CLINEA Side 20 af 26

21 sender i enkelte tilfælde data til apparatur. EG CLINEA understøtter ligeledes ankomstregistrering og overblik over, hvor lang patienten er i forløbet på dagen (flowstyring) Integration mellem COSMIC PAS og eksisterende øjensystem Følgende integration mellem COSMIC PAS og EG CLINEA er besluttet. Tider bookes i EG CLINEA, og der sendes indkaldelsesbrev herfra. Da tidspunkt for første indkaldelsesbrev indgår i servicemål, som udtrækkes fra COSMIC, er der behov for, at denne oplysning kan findes i COSMIC PAS. COSMIC PAS EG CLINEA Henvisning Henvisning, Henvisning Henvisning Henvisning Visitér og opret forløb Forløb COSMIC forløb Forløb Indkaldelses og booking oplysninger Booking servicemål (på forløb) Booking Send indk. brev Notat m. diagnosekoder Diagnose- og procedurekoder (på forløb) Diagnose- og procedurekoder Notat m. procedurekoder Indlæggelse/ Besøg COSMIC kontakt Kontakt Epikrise servicemål (på kontakt) Send epikrise Epikriseinformationer Epikrise Figur 10 Integration til EG CLINEA 11.2 Fremtidig applikation- og integrationssituation (to-be) Det væsentlige er, at samme system anvendes til samme opgave, hvilket er i tråd med regionens it-princip. Samtidig foretages der kun integration med udgangspunkt i det fælles regionale øjensystem/øjenmodul. Det betyder, at alle sygehuse med øjenafdelinger, skal have det samme systemlandskab til håndtering af forretningsprocesser. 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, også i forhold til drift og vedligeholdelse. Det betyder, at der kun skal etableres de absolut nødvendige integrationer. Tages der udgangspunkt i patientforløb, identificerede databehov og funktionalitet, er nedenstående integrationer, ud over allerede etablerede, et absolut minimum: Integration til Regionens CPR-komponent. (Er etableret) Integration mellem øjensystem og COSMIC PAS (Er etableret) Integration til Regionens SOR-komponent (Er etableret, men skal formentlige udvides) Integration til ydelseskatalog (Er etableret) Side 21 af 26

22 Overførsel af journalnotater til COSMIC EPJ Integration til Active Directory til brugerautentifikation Integration til medicoteknisk udstyr (Er delvis etableret) 12. Teknologi og nødvendig infrastruktur Der har i denne fase ikke været fokus på teknologi og infrastruktur, dette vil hovedsageligt blive bearbejdet i anskaffelsesfasen. Der er her udelukkende gennemført nogle korte analyser og vurderinger, på de områder der generelt kan være dimensionerende for de økonomiske rammer i forbindelse med anskaffelse og efterfølgende drift af et kommende system Udveksling med medicoteknisk udstyr og 3. parts software Generelt Mængden af dataudveksling med medicoteknisk udstyr og 3. parts software er vurderet til at være meget omfangsrigt. Alle de i dag anvendte apparaturer skal også i et kommende RSD RØS system kunne integreres, så data kan udveksles mellem udstyr og RSD RØS. Største delen af de apparaturer der i dag findes på øjenafdelingen SLB, er integreret i produktet EG CLI- NEA. Det vurderes at der i dag en relativ stor komponent/apparatur sammenfald mellem de tre afdelinger. Ud fra ovenstående må det forventes at de fleste protokoller til apparatur er kendte, hvorfor en kommende leverandør vil kunne få et klart billede af apparaturlandskabet og derved arbejde med relativ lille risikomagen ved på dette område. Der er på de tre øjenafdelinger en høj udskiftnings/anskaffelses frekvens af nyt apparatur. Det forventes at der tilgår nyt apparatur ca. hvert halve år. Denne høje frekvens taler for, at der i et kommende drifts/vedligeholdelses budget skal afsættes midler til håndtering af kommende integrationer mellem apparatur og RSD RØS, endvidere skal det tages med i en kommende vedligeholdelseskontrakt Integration af medicoteknisk udstyr til COSMIC I anden sammenhæng/projekt er Cambio, leverandøren af COSMIC, blevet adspurgt hvorvidt de ser at der kommer direkte integration mellem medicoteknisk udstyr og COSMIC. Svaret på dette har været ret entydigt. Det er ikke noget de har i deres roadmap, og det er heller ikke nok de kan se kommer, da det ikke er et område de vil fokusere på. Ovenstående svar medfører, at integrationer mellem COSMIC og medicoteknisk udstyr altid vil komme til at foregå gennem 3. parts software af den ene eller anden type. Endvidere betyder det, at i det tilfælde man vælger at COSMIC skal fungere som primært øjensystem, vil man skulle gennemføre en anskaffelse af et 3. parts software til at håndtere integration mellem Medico og COSMIC. Det vil være muligt at implementere adgang til dybe links i COSMIC, på lige fod med hvad der i dag er muligt i EG CLINEA. Ud fra ovenstående taler det for, at såfremt man ønsker at anvende COSMIC som primært øjensystem, skal der udvikles integrationer til 3. parts softwaren (middleware) samt udvikling af øjenmodul i COSMIC til håndtering af processen på afdelingerne Integration af medicoteknisk udstyr til EG CLINEA EG CLINEA fungerer i dag som primært øjensystem på SLB. EG CLINEA har på nuværende tidspunkt integrationer til det apparatur der findes på øjenafdelingen. Øjenafdelingen anvender integrationer på to forskellige måder, enten som direkte levering af data fra apparatur til EG CLINEA, dvs. data der lagres med relation til patienten i EG CLINEA og kan anvendes alle Side 22 af 26

23 steder på afdelingen. Ex. Sygeplejerske gennemfører målinger under forundersøgelsen, hvorefter lægen kigger på samme data senere i forløbet andet sted på afdelingen. Den anden form for integration er den anden vej, hvor EG CLINEA leverer informationer ud i udstyret. Denne form for integration anvendes endvidere af to forskellige årsager. Enten som patientreference, hvor EG CLINEA sender reference over til apparatur, for at koble handlingen sammen med patienten (binder CPRNR og data samen). Den anden årsag er til anvendelse af tidligere indtastede/målte data, dvs. EG CLINEA leverer tidligere måleværdier over til apparatur, derved kan apparaturet indstilles ud fra tidligere indlæste værdier for den enkelte patient. Foruden de beskrevne integrationer anvender øjenafdelingen tre forskellige software, i en viewer/dataprovider (server for udstyr). Tilgangen til disse software foregår alle fra EG CLINEA, som starter applikationerne op, dvs. integration som dybe links. De steder hvor data giver mening uden for vieweren bliver de overført fra 3. parts software til EG CLINEA og kan anvendes at stede i processen. Da man i dag ikke anvender COSMIC EPJ på SLB, er der ikke udarbejdet afprøvede integrationer mellem EG CLINEA og COSMIC EPJ Storage, database og server Storage, Database og server behov i EG CLINEA. EG CLINEA backend er i dag placeret i regionens virtuelle farm på SLB, Vejle, men vil sagtens kunne drives fra en et af de to datacentre. Som EG CLINEA er designet i dag, gemmes alle informationer inkl. billeder i en Open Source, Firebird Database og på nuværende tidspunkt bruger den ca. 600 GB storage, med en datatilvækst på ca. 50 GB pr. år EG CLINEA er designet som et enkelt server setup, uden nogen former for redundans. Der tages backup et par gange i døgnet, hvilket i praksis betyder at der vil være et datatab, såfremt systemet går ned og data skal genskabes Storage, Database og server behov i et kommende RSD RØS Med udgangspunkt i tallene fra SLB og EG CLINEA, er der lavet en vurdering af hvordan det ville se ud med tre afdelinger og samme databehov og tilvækst. Nuværende EG CLINEA kapacitet x 3 svare til ca. 2 TB storage, som skal være i 2 uafhængige driftscentre, hvilket giver et etablerings storage behov på 4TB med en årlig datatilvækst på ca. 200 GB pr. år ud fra en ekstrapolation på data fra nuværende anvendelse på én afdeling. Dvs. i budget tal kan der beregnes på et setup med to produktionsmiljøer og ét test og en samlet storage kapacitet på 6 TB i alt over en fire årige periode Service Level Øjenafdelingerne skal kunne arbejde 24/7, dog kun med akutoperationer uden for daglig arbejdstid skal der på et kommende RSD RØS være en oppetid der håndterer dette. En akutoperation vil uden de store udfordringer kunne gennemføres uden adgang til et RSD RØS system. Dette vil dog medføre et administrativt efterslæb, da opdateringer og indtastningen omkring patienten, der efterfølgende skal gennemføres manuelt, når systemet igen bliver tilgængeligt. Det bør overvejes at der kigges på backend løsninger med to dublerede produktionsmiljøer, der ikke har datatab ved et evt. nedbrud af systemet. Der bør endvidere stilles et krav i et evt. kommende udbud om muligheden for fleksible databasebackup muligheder hvor der gives mulighed for at genskabe et nedbrudt system, uden halve og hele dages tab af data. Det bør om muligt tilstræbes at der anvendes databasesystemer der indgår i kundens IT-Miljø. Side 23 af 26

24 13. Arkitekturrisiko (to-be) Ud fra ovennævnte analyse er vurderingen at det er muligt inden for det eksisterende systemlandskab at anskaffe et specialespecifikt system eller udvikle COSMIC, så de dækker samtlige identificerede forretningsbehov. Relateret til COSMIC vil der altid skulle anskaffes og etableres et 3. partssystem til håndtering af medicotekniske opkoblinger. Ud fra anbefalingen er følgende risici identificeret: Vurderet risiko Niveau Imødegåelse af risiko Særdeles kompleks arkitektur Høj/lav Afhænger af strategisk systemvalg, relateret til de 2 skitserede scenarier, vil risikoelementet være forskellig. Infrastruktur Middel Eksisterende løsninger er aktuelt en del at Region Syddanmark driftscentre eller en del af den virtuelle farm. De kan driftes eksternt såvel som internt uden vurderet risiko. Medicotekniske opkoblinger Lav Det vurderes, at der i dag en relativ stor komponent/apparatur sammenfald mellem de tre afdelinger. Ud fra ovenstående må det forventes, at de fleste protokoller til apparatur er kendte, hvorfor en kommende leverandør vil kunne få et klart billede af apparaturlandskabet og derved arbejde med relativ lille risikomagen ved på dette område. Der er på de tre øjenafdelinger en høj udskiftnings/anskaffelses frekvens af nyt apparatur. Det forventes at der tilgår nyt apparatur ca. hvert halve år. Denne høje frekvens taler for, at der i et kommende drifts/vedligeholdelses budget skal afsættes midler til håndtering af kommende integrationer mellem apparatur og RSD RØS, Side 24 af 26

25 14. Bilagsoversigt Bilag 1: Scenarier for it understøttelse af øjenafdelinger Bilag 2: Oversigt over Use Case Nedenstående tabel viser hvilket use cases, der skal beskrives / er beskrevet for at understøtte de enkelte processer. Use Casene vil således efterfølgende og I et senere projekttrin blive brugt til at udlede funktionelle krav til det ønskede system. # Navn Udarbejdet Service - Visiter patient Modtag henvisning Ja 1 02 Visiter henvisning Ja 2 - Indkald patient - 1,2,3,4 03 Book patient Ja 1,2,3,4 04 Indkald patient Ja 1 - Modtag indkaldelse Modtag patient - 1,2,3,4 05 Registrer patients ankomst Ja 1,2,3,4 Håndter kørselsgodtgørelse Nej 1,2,3,4 06A+06C Forundersøg patient Ja 1 - Undersøg patient - 1,2,4 - Dokumenter undersøgelse - 1,2,4 - Dokumenter medicin - 1,2,3,4 - Vurder og planlæg videre behandling - 1,2,3,4 06B Undersøg patient (supplerende) Ja 2 - Undersøg patient Gentagelse 1,2,4 - Dokumenter undersøgelse Gentagelse 1,2,4 - Dokumenter medicin Gentagelse 1,2,3,4 - Vurder og planlæg videre behandling Gentagelse 1,2,3,4 07A+07B Behandl patient Ja 3 - Forbered patient til behandling Udfør behandling på patient Dokumenter behandling Gentagelse 1,2,3,4 - Dokumenter medicin Gentagelse 1,2,3,4 - Vurder og planlæg videre behandling Gentagelse 1,2,3,4 08 Kontroller patient Nej 4 - Undersøg patient Gentagelse 1,2,4 - Dokumenter undersøgelse Gentagelse 1,2,4 - Dokumenter medicin Gentagelse 1,2,3,4 - Vurder og planlæg videre behandling Gentagelse 1,2,3,4 09 Afslut undersøgelse Ja 1,2,3 - Håndter befordring - 1,2,3,4 - Kontroller og signer procedurekoder - 1,2,3,4 - Afslut behandlingsforløb - 1,2,3,4 - Send epikrise - 1,2,3,4 10 Afslut behandling Nej 1,2,4 - Håndter befordring Gentagelse 1,2,3,4 - Kontroller og signer procedurekoder Gentagelse 1,2,3,4 - Send epikrise Gentagelse 1,2,3,4 12 Opret / rediger fraser Nej Adm. 13 Opret / rediger opslagstabeller Nej Adm. 14 Opret / rediger patientforløb Nej Adm. 15 Opret / rediger kø funktion Nej Adm. Bilag 3: Use cases Use Cases vedlægges i særskilt i.zip fil Side 25 af 26

26 Side 26 af 26