SOSI projektet Evalueringsrapport Dato: 10. november 2008 Projektnavn: SOSI Ansvarlig: SERVICEORIENTERET SYSTEMINTEGRATION (SOSI) Jan Riis (Lakeside A/S) Tel. +45 2160 7252 Email: jri@lakeside.dk
Indholdsfortegnelse 1 Indledning... 5 1.1 Oversigt over forretningsmæssige gevinster... 6 1.2 Sammenfatning af resultater og erfaringer... 7 1.3 Resultater ifht. oprindeligt kommissorium... 7 2 Projektforløbet... 9 2.1 Projektopstart... 9 2.2 Krav, tilbud og kontrakter...10 2.3 Udvikling af systemer og komponenter...10 2.4 Integrationstest...11 2.5 Forberedelse af pilottest...12 2.6 Performanceproblemer...13 3 Kliniske erfaringer...15 4 Tekniske erfaringer...18 4.1 XML og Digital Signatur...18 4.2 De primære komponenter til Pilotafprøvningen...20 4.3 SOSI biblioteket support og vedligeholdelse...20 4.4 International interesse...21 4.5 Svartidsoversigt...23 4.6 Andre tekniske SOSI produkter...25 4.7 Sikkerhedsaspekter...27 4.8 Andre tekniske erfaringer...28 4.8.1 Sundhedsdatanettet... 28 4.8.2 Streaming... 29 4.8.3 Testproblematikker... 29 5 Projektledelseserfaringer...30 6 Økonomiopgørelse...32 7 Konklusion og opsummering af nøgleresultater...33 Side 2
Figurfortegnelse Figur 1 - tidslinje april 2006...10 Figur 2 - tidslinje november 2006...10 Figur 3 - tidslinje juli 2007...11 Figur 4 - tidslinje maj 2008...12 Figur 5 - Skærmbillede af løsningen fra lægernes system i Esbjerg...16 Figur 6 - alle parter valgte at anvende SOSI biblioteket...19 Figur 7 - En drifts- og supportoperatør blev foreslået og etableret af Digital Sundhed...21 Figur 8 - eksempel på skaleringsgraf fra Chronos...22 Figur 9 - eksempel på svartidsgraf under skalering...22 Figur 10 - Integrationslinjer ved skalering af klientsystemer og tjenesteudbydere...26 Figur 11 - Integrationsbilledet efter implementering af SOSI-GW...27 Side 3
Forkortelser SDSD Sammenhængende Digital Sundhed i Danmark FMK Projektet "Det Fælles Medicin Kort" SOSI Service Orienteret System Integration OCES Offentlige Certifikater til Elektronisk Service EPJ Elektronisk Patient Journal LMS Lægemiddelstyrelsen PEM Den Personlige Elektroniske Medicinprofil EPM Elektronisk Patient Medicinering EMS Enstrenget Medicinerings System KL Kommunernes Landsforening XML extendable Markup Language QoS Quality of Service NIST National Intitute of Standards and Technology IAM Identity and Access Management SOSI-GW SOSI Gateway SOSI-DCC SOSI DeCoupling Component RSD Region Syddanmark RHS Region Hovedstaden ITST IT- og Telestyrelsen SOAP Simple Object Access Protocol DGWS Den Gode Web Service SVS Sydvestjysk Sygehus i Esbjerg Side 4
1 Indledning Nærværende dokument har til formål at forankre de væsentligste erfaringer fra SOSI projektet og relatere disse til nuværende og planlagte aktiviteter i regi af Digital Sundhed og andre offentlige parter. Der er i SOSI projektets levetid oparbejdet erfaringer på mange områder, tekniske, kliniske, organisatoriske, arkitekturelle osv. Mange af disse erfaringer er allerede nu blevet indarbejdet i initierede eller planlagte initiativer i regi af Digital Sundhed (SDSD), men er for en ordens skyld også dokumenteret i nærværende rapport. Side 5 Dokumentet er udfærdiget, så det ikke retter sig specielt mod en bestemt læserskare. Dokumentet burde således give udbytte for såvel ledersegmentet i digitaliseringsenheder, IT-projektledere, såvel som for IT teknikere, der har interesse for det felt, som SOSI projektet har beskæftiget sig med. Til dokumentet ligger der dog nogle mere tekniske bilag, der kan være svært tilgængelige for ikke-teknikere. Specielt vigtige erfaringer er fremhævet i gråtonede bokse således: Erfaring 11 (eksempel) Læger kan til nød acceptere svartider på 4-6 sekunder ved rekvirering af eksterne kliniske informationer. Overstiger svartiden denne tærskel, vil lægerne ikke tage løsningen i brug. Forkortelsen SOSI er et akronym for ServiceOrienteret SystemIntegration og var et projekt, der havde til formål at etablere nogle fælles krav til udveksling af digital information indenfor sundhedsområdet (se bilag 1 [SO- SI-kommisorium]). Kravene skulle dels rette sig mod syntaktiske standarder og dels mod styring af idriftsatte digitale tjenester. Kravene skulle baseres på nationale og internationale standarder, profiler og erfaringer. I næste afsnit sammenfattes erfaringerne og hvilke initiativer de i givet fald videreføres i hos Digital Sundhed. SOSI projektet og de resultater, der er realiseret gennem SOSI projektet, har på mange måder været banebrydende og foran sin tid. Dels har projektet beskæftiget sig med teknologier og standarder, der først nu er ved at blive profileret på fællesoffentligt niveau i Danmark. SOSI projekter er således en form for "proof of concept" af kommende nationale standarder. Dels er Open Source og governancestrukturer omkring Open Source blevet anvendt og operationaliseret i hidtil uset grad i SOSI projektet. At være så langt fremme teknologisk har naturligvis øget risikoprofilen i projektet, men styregruppen, projektledelsen og de tilknyttede arkitekter har under hele forløbet været opmærksomme på dette, og har til stadighed evalueret og kompenseret for dette forhold, blandt andet vha. værktøjsunderstøttelse og abstraktion. Derfor er projektet og de parter der anvender projektets produkter i en meget robust situation, hvor evt. ændringer eller tilføjelser, vil få færrest mulige konsekvenser for disse. Sundhedssektoren i Danmark er nu
blandt de førende på verdensplan mht. integrationsteknologier - og det vel at mærke integrationsteknologier der er afprøvet. Side 6 1.1 Oversigt over forretningsmæssige gevinster SOSI er én af grundstenene i en national SOA strategi. SOSI danner grundlag for "Fælles MedicinKort" (FMK) SOSI projektet har vist, at det er muligt at integrere systemer på tværs af sundhedssektoren på en sikker måde, og som baner vejen for at skabe sammenhæng i sundhedssektorens IT systemer. Ikke blot ved at præsentere informationer fra andre systemer, som man f.eks. gør i Sundhed.dk, men ved at give sikker systemteknisk adgang til data. Dette skaber helt nye muligheder for at forbedre den sundhedsprofessionelles IT værktøjer og derved opnå bedre kvalitet i behandlingen af patienter. SOSI projektet har været medvirkende til, at sundhedsområdet i Danmark nu er helt fremme på verdensplan i relation til IT integrationsteknologier og de omgivende governancestrukturer. Som et konkret eksempel på ovenstående, er resultaterne fra SOSI projektet direkte anvendt i FMK projektet. Uden SOSI projektet ville det ikke have kunnet lade sig gøre at sætte ensartede krav til integrationsmekanismer mellem FMK og kommende nationale tjenester. SOSI høster gevinsten af Digital Signatur SOSI projektet har vist, at digital signatur (OCES) også kan anvendes i system til system integration. Dermed er SOSI med til at høste gevinsterne ved at indføre Digital Signatur (OCES) som sikkerhedsmekanisme. SOSI er et eksempel på trinvis udvikling SOSI projektet er et eksempel på trinvis udvikling af en national IT infrastruktur, der skaber sammenhæng mellem systemer, og dermed giver autoriserede sundhedsprofessionelle mulighed for at få adgang til nødvendige og relevante informationer. Dette er naturligvis til gavn for patienten (bedre behandlingsmuligheder), men også til gavn for samfundsøkonomien, f.eks. ved at læger kan genanvende andres resultater i stedet for (som nu) at bestille nye tilsvarende laboratorieprøver, når en patient kommer i behandling et nyt sted. SOSI viser gevinsten af Open Source I SOSI projektet er der udviklet en række Open Source softwarekomponenter, som har vist sig at gøre det væsentligt nemmere og dermed væsentligt billigere for parterne at udnytte de nye muligheder. Oven i dette giver Open Source den frihed og fleksibilitet, som vi fra Digital Sundheds side ønsker af denne type nationale komponenter.
1.2 Sammenfatning af resultater og erfaringer SOSI projektet har helt eller delvist været med til at skabe flg. hovedresultater: Side 7 Resultat Nuværende ansvar Status "Den Gode Web Service" Digital Sundhed version 1.0.1 SOSI identityprovider Digital Sundhed hos operatør SOSI programmeringskomponent Digital Sundhed hos operatør (seal) Sikkerhedsvejledning Digital Sundhed hos operatør SOSI gateway Digital Sundhed hos operatør SOSI afkoblingskomponent Digital Sundhed hos operatør Performanceværktøj Open Source samfundet Frigivet (Chronos) Operatøren Digital Sundhed Iværksat Pilotafprøvning på SVS RSD / LMS i drift 1.3 Resultater ifht. oprindeligt kommissorium Før SOSI projektet blev initieret, var "projektet" tænkt som en arbejdsgruppe 1, der havde flg. formål: Arbejdsgruppen skal forholde sig til en række eksisterende web-service baserede snitflader (til NIP-IT løsningen, SEI, Sundhed.dk, PEM, TDC sikker web-service til udstedelse og administration af digitale certifikater etc.) og eksisterende eller påbegyndte integrationer til disse landsdækkende snitfalder. Arbejdsgruppen skal vurdere fordele og ulemper ved forskellige standarder (SAML, WS-security etc.) med henblik på system-til-system integration indenfor sundhedsvæsenet baseret på den eksisterende infrastruktur for Sundhed.dk og OCES digitale certifikater. Dette vil indebære at arbejdsgruppen skal diskutere forskellige sikkerhedsløsninger der tager udgangspunkt i tickets og Single sign-on. "Gruppens arbejde skal resultere i en række af fælles krav for integration mellem parter i sundhedsvæsenet. Kravene bør bl.a. forholde sig til syntaktiske og semantiske formater, dokumentation af services, behovet for et centralt service register over services der gør det muligt at fremsøge relevante udbydere, at få viden om services indhold samt hvordan de kaldes og vedligeholdes. Krav til beskrivelse 1 "Arbejdsgruppen om web-service baseret system-til-system kommunikation herunder sikkerhedsløsninger baseret på billetter og single sign on"
af serviceniveau for services (QoS), krav til styringsprocesser (change management etc.), tjenester der understøtter ovenstående (eks. kommunikation mellem serviceudbyder og serviceaftager)." Side 8 De understregede passager er oprindelige mål i projektet og nedenstående tabel viser, i hvilket omfang SOSI projektet har opnået disse mål. Mål "projektet skal forholde sig til en række eksisterende web-service baserede snitflader" "... vurdere fordele og ulemper ved forskellige standarder" "... skal diskutere forskellige sikkerhedsløsninger der tager udgangspunkt i tickets og Single signon" "... fælles krav" (til serviceudbydere) krav til "... syntaktiske og semantiske formater, dokumentation" skal analysere "... behovet for et centralt service register over services" skal analysere krav til "QoS" skal stille krav til "... styringsprocesser" og tilhørende "tjenester" Opfyldelse Projektet har gjort sig bekendt med en række eksisterende web service snitflader, men specielt PEM snitfladen har været i fokus i projektet. Det er der brugt en del tid på i projektet. Der er lagt speciel vægt på disse vurderinger i artiklen til IDTrust symposiet [SOSIIDTrust]. Som ovenfor. Se bilag 4 DGWS indeholder netop syntaktiske og semantiske krav til dele beskedformat. Projektet har vurderet, at det ikke pt. er nødvendigt i integrationen mellem decentrale og centrale tjenester på sundhedsområdet. Der har i høj grad været fokus på Quality of Service aspekter i projektet. Dette var også et af hovedbudskaberne i artiklen til IDTrust symposiet [SO- SIIDTrust]. SOSI projektet har været medvirkende til at Digital Sundhed har indført en drifts-operatør af nationale komponenter og tjenester (se [Operatøren]). SOSI projektet har med andre ord til fulde opnået de mål, man satte sig i det oprindelige kommissorium. Som nærværende rapport vil vise, har projektet opnået meget mere end det
2 Projektforløbet Side 9 2.1 Projektopstart Projektets kommissorium blev skrevet og godkendt i sommeren 2005 og projektet blev initieret i efteråret 2005. Opdraget kom oprindeligt fra Ribe og Københavns Amt, og projektet var sanktioneret af Amtsrådsforeningens EPJ arkitekturgruppe. Ribe Amt påtog sig formandskabet og projektledelsen i projektet. Oprindeligt var projektets kommissorium ret begrænset, men det viste sig hurtigt at problemområdet dels havde interesse blandt en større skare af interessenter og dermed fik projektet også relativ stor politisk bevågenhed. Projektet gik derfor fra at være meget overskueligt med en tidsramme på ca. 6 måneder til at være et projekt, hvor det ikke blot handlede om at stille fælles krav, men også at profilere internationale standarder, afprøve disse i produktionssystemer mv. Det viste sig hurtigt i begyndelsen af projektet, at Sign-On problematikken var af stor vigtighed for amterne. Amterne ønskede en løsning, hvor man med ét sign-on kunne få adgang til alle nødvendige digitale tjenester på nationalt niveau 2. På den anden side, skulle dette sign-on dog være sikkert nok til, at tjenesteudbydere (f.eks. Lægemiddelstyrelsen) kunne oppebære deres data- og registeransvar, jf. gældende love og bekendtgørelser. Derfor faldt valget på Digital Signatur, hvilket dels tilførte projektet yderligere risici, men også øgede projektets potentiale. Da pilotafprøvningen af standarder mv. skulle afprøves mod Lægemiddelstyrelsens (LMS) Personlige Elektroniske Medicinprofil (PEM) var det vigtigt for projektet at få Lægemiddelstyrelsen involveret i projektet og projektets styregruppe. Lægemiddelstyrelsen kunne dog ikke gå ind i et projekt før der var et bredere mandat bag projektet. Konkret betød det, at projektet skulle have mandat fra alle amter og fra KL. Dette opnåede projektet gennem dialog i IT Temagruppen hos Amtsrådsforeningen samt ved at lade KL indtræde i en følgegruppe. Herefter trådte LMS ind i projektet. Erfaring 1 Når offentlige styrelser skal deltage aktivt i et projektaktiviteter, er det vigtigt at projektet fra begyndelsen har et bredt mandat. Et sådant mandat kan f.eks. opnås gennem dialog og beslutninger i allerede etablerede fora med bred tilslutning fra de organisationer, der skal give mandatet, eller ved at lade vigtige interessenter indtræde i følgegrupper. 2 Dette må ikke forveksles med initiativer der pågår i Sign-On projektet, hvor der nu bygges videre på SOSI så der også skabes sammenhæng til regionernes interne Sign-On mekanismer samt patientkontekstbevarelse.
2.2 Krav, tilbud og kontrakter Projektet har oplevet adskillige skred i tidsplanen. Det vil føre for vidt at beskrive dem alle her, men de vigtigste gennemgås og illustreres tidslinjer. Side 10 Figur 1 - tidslinje april 2006 Figur 2 - tidslinje november 2006 Af de to første tidslinjer fremgår det relativt klart, at projektet i første omgang blev forsinket af, at kontraktforhandlingerne trak ud (ca. 5 måneder). Det viste sig at tage længere tid end forventet at få forudsætningerne for kontrakterne og de konkrete kontrakter på plads i de tre delprojekter: PEM udvidelse hos LMS EMS udvidelse i Ribe Amt og EPM udvidelse i Københavns Amt. Årsagen til dette var primært forskellige tilgange til kontraktforhandlinger i delprojekterne og nogle ret hårde forhandlinger specielt på PEM delprojektet, der var den absolut mest bekostelige af de tre delprojekter 3. 2.3 Udvikling af systemer og komponenter Udviklingsforløbet blev kun marginalt forsinket, da først denne fase gik i gang. Udvikling af bibliotekerne (SOSI-Seal) og SOSI-IdP'en forløb helt planmæssigt, og udviklingen af EMS, EPM og PEM udvidelserne gik også 3 Dertil skal dog bemærkes, at disse dele er blevet genanvendt i FMK løsningen.
efter planen. Dog løb projektet ind i alvorlige udfordringer i slutningen af PEM udviklingen, idet infrastrukturen omkring Receptserver løsningen viste sig at have driftsproblemer, hvilket gjorde at såvel LMS som deres leverandør måtte prioritere Receptserverløsningen op. Dette standsede i praksis færdiggørelsen af PEM delprojektet og forsinkede projektet med adskillige måneder (4-5 måneder). Nogenlunde samtidigt viste det sig at Københavns Amt ikke kunne gennemføre pilotafprøvningen, idet det ikke var realistisk at få synkroniseret SOSI udviklingsplanen med amtets planer for udvikling af det kliniske system løsningen skulle indarbejdes i (EPM 2.0). Side 11 Erfaring 2 Det kræver meget stort commitment fra alle parter i et projekt at sikre, at andre projekter eller initiativer ikke prioriteres højere og dermed får negativ indflydelse på tidsplanen i projektet. Styregruppen skal være meget stærkt besat for at kunne imødegå sådanne eksterne trusler for et projekt. Hvis projektet udsættes for udsættelser pga. andre initiativer, er det vigtigt at være i meget tæt dialog med det andet initiativ samt at inddrage styregruppen i problemstillingen øjeblikkeligt. 2.4 Integrationstest I juni 2007 lykkedes det for projektet at få gennemført en integrationstest, der i testsystemer viste, at der kunne kommunikeres mellem alle involverede IT systemer (se bilag 2 [IntegrationsTestPlan] og bilag 3 [Integrations- TestRapport]). Figur 3 - tidslinje juli 2007 Der var stadig på dette tidspunkt problemer med at få adgang til LMS PEM testsystemet, men leverandøren stillede et udviklingstestmiljø til rådighed, som blev transporteret til driftscentret i Esbjerg, hvorved det blev muligt at integrationsteste løsningen.
Erfaring 3 Det var altafgørende for fremdriften i SOSI projektet at have et godt, åbent og respektbaseret forhold mellem projektledelsen og leverandører af de forskellige løsninger i projektet. Alle tegn på "skyttegravskrig" skal imødegås øjeblikkeligt med dialog og åben problemløsning. Side 12 Eneste usikkerhed var derefter opkoblingen til PEM systemet via sundhedsdatanettet. Denne usikkerhed måtte projektet vente yderligere 5 måneder for at aftestet idet projektet først i 17. december 2007 fik adgang til det endelige PEM system i produktionsmiljøet. På dette tidspunkt var PEM delprojektleverancen i forhold til dette projekt forsinket med ca. 14 måneder. Store dele af denne forsinkelse endte med at blive ventetid. Erfaring 4 Ventetid i projekter vil altid belaste projektet økonomisk. Projekter der er på "stand by" mister dog også hurtigt momentum politisk/strategisk og følgevirkninger kan således opstå på mange fronter. Vi har endvidere erfaret, at et projekt, der er "stand-by", kan være trægt at få op i samme tempo, som da man midlertidigt standsede projektet. Erfaring 5 I projekter, hvor der er risiko for store tidsforskydelser pga. ventetid, er det en klar fordel at have timebaserede kontrakter med tilknyttede ressourcer, f.eks. konsulenter. Hvis ressourcerne kan overflyttes til andre relevante aktiviteter, vil ventetid kun i mindre grad belaste projektets økonomi. 2.5 Forberedelse af pilottest Efter integrationstesten og idriftssættelsen af PEM delprojektet i december 2007 gik projektet nu over i pilottestfasen. Figur 4 - tidslinje maj 2008 Testen blev planlagt i de sidste måneder i 2007, og der blev indgået aftaler med klinikchef overlæge Kristian K. Thomsen på afdeling 242 (kardiologisk sengeafsnit) på Sydvestjysk Sygehus i Esbjerg. Afdelingen stillede alle sine læger til rådighed mht. afprøvning. SOSI pilotløsningen krævede dog
at en række organisatoriske og IT infrastrukturelementer var på plads på sygehuset, herunder: Digital signatur skulle bestilles i regionen (herunder indsamling af CPR numre). Digital signatur skulle være tilgængelig fra såvel klinikken som fra lægernes kontorer Lægerne skulle specialautoriseres til løsningen hos superbrugere. Herunder skulle lægernes autorisations-id'er indsamles og registreres. Side 13 I SOSI projektet blev der brugt en del tid på at få disse forudsætninger på plads. Specielt har vi erfaret, at projektets formodning om status sjældent var samstemmende med virkeligheden. Dels fordi der enten var flere problemstillinger gemt i at få etableret en forudsætning, eller fordi andre ting var vigtigere end en pilotafprøvning, og derfor blev nedprioriteret - en naturlig reaktion for IT afdelinger, der er meget ressourcemæssigt trængt. Erfaring 6 Det er meget vigtig at planlægge en pilottest grundigt og sørge for at inddrage interessenter tidligt, herunder søge personligt kontakt med de involverede parter, f.eks. gennem et kick-off møde og jævnlige besøg hos de involverede. Tekniske forudsætninger skal sættes i værk et godt stykke tid inden pilottesten iværksættes og i den forbindelse skal der jævnligt følges op på fremdrift og status. 2.6 Performanceproblemer Testen blev skudt i gang i marts 2008, og det var aftalen, at alle læger skulle bruge løsningen til ca. 1. maj 2008, hvorefter projektet skulle evalueres og lukkes. Ved en stikprøvekontrol viste det sig dog, at løsningen ikke blev brugt, og der viste sig at være flere årsager til dette: Digital Signatur virkede slet ikke på de kliniske arbejdspladser og kun få steder på lægernes kontorer Svartiderne på systemet var meget dårlige. Så dårlige at lægerne ikke kunne bruge løsningen. Erfaring 7 Når løsninger sættes i drift hos meget travle personalegrupper, hvor ITløsningen ikke er et primært værktøj i personalets arbejdsdag, må det ikke forventes at få tilbagemeldinger på fejl eller mangler. Ofte vil personalet blot undlade at bruge løsningen og fortsætte med det daglige arbejde. I SOSI projektet har det været nødvendigt aktivt at opsøge erfaringer fra hospitalet ved at besøge klinikere og driftsteknikere på hospitalet. Projektet fremlagde fire aktiviteter, der ville forbedre brugernes oplevelse af løsningen. Disse aktiviteter blev alle iværksat og en ny løsning blev an-
nonceret for lægerne i oktober 2008. Lægerne gik herefter i gang med at anvende løsningen. Det har senere vist sig, at løsningen ikke bliver brugt i så høj grad, som vi havde forventet, men dog tilstrækkeligt til at vi tør evaluere på projektets løsninger. Dette hænger sammen med at løsningen kun anvendes i tilfælde af usikkerhed omkring patientens medicinering. Løsningen ville blive anvendt mere intensivt såfremt den blev indført ved modtagelse af patienten. Side 14 Erfaring 8 I planlægning af en pilottest er afgørende vigtigt at sørge for, at løsningen tages i brug af personalegrupper og i nogle arbejdssituationer, der i fornødent omfang giver testens målinger den fornødne statistiske signifikans. Det er med andre ord vigtigt at planlægge hvilke use-cases testen præcist skal anvendes i, validere disse use-cases sammen med det kliniske personale, og sørge for commitment blandt de involverede testere. En aftale om at "tage løsningen i brug blandt alle læger på en afdelingen" kan lyde meget fornuftig, men i praksis kan det vise sig at give meget få målinger, fordi de brugsscenarier, løsningen vælges at blive anvendt i, er sjældne.
3 Kliniske erfaringer Den kliniske løsning blev oprindeligt designet med input fra klinikere fra såvel Københavns Amt som Ribe Amt. Det stod relativt hurtigt klart at såfremt alle gevinster ved adgang til Medicinprofilen skulle høstes, var det nødvendigt at foretage en "dyb" integration mellem klinikernes nuværende kliniske IT-arbejdskaber og Lægemiddelstyrelsens medicinprofil. Dette ville muliggøre semi-automatisk overførsel af medicininformationer fra Medicinprofilen til medicinmodulet i lægens IT værktøj, hvilket sparer lægen for genindtastning og muliggør "intelligens" i løsningen, idet medicinmodulet kan hjælpe lægen ved f.eks. at præsentere mulige substitutionslægemidler mv. Side 15 Erfaring 9 Pilottesten har bekræftet at System-til-system integration giver meget større værdi for brugerne end blot at kunne vise informationer, idet det giver mulighed for at foretage semi-automatisk overførelse af data, giver langt bedre støttemuligheder mv. Erfaring 10 Den konkrete løsning (adgang til medicinprofilen) har givet værdi til lægerne - specielt i tvivlstilfælde. Dette understøtter kvalitetsdelen af business-casen for FMK projektet. Som nævnt i afsnittet "2.6 Performanceproblemer" oplevede lægerne meget dårlige responstider på opslag i Medicinprofilen. Årsagen til dette redegøres der for senere i dokumentet, men erfaringen var at læger selvfølgelig gerne vil have informationerne øjeblikkeligt, men at de kan acceptere vigtige informationer er til rådighed inden for ca. 4-6 sekunder. Overstiger svartiden generelt denne værdi, vil lægerne gå bort fra at anvende løsningen. Erfaring 11 Læger kan til nød acceptere svartider på 4-6 sekunder ved rekvirering af eksterne kliniske informationer. Overstiger svartiden denne tærskel, vil lægerne ikke tage løsningen i brug. En anden vigtig erfaring i det kliniske forløb var lægernes modtagelse af digital signatur. Umiddelbart var modtagelsen god, men det det undrede klinikerne, at de tilsyneladende nu skulle til at huske endnu et password (de bruger ikke i forvejen digital signatur). Erfaring 12 Sundhedsprofessionelle brugere af IT løsninger ønsker som udgangspunkt kun at skulle huske ét sæt akkreditiver (brugernavn + password). De involverede parter i SOSI projektet har efterspurgt en løsning, hvor Digital Signatur anvendes som log-in mekanisme til alle deres kliniske systemer.
Nedenfor ses et skærmbillede baseret på fiktive data, der viser hvorledes løsningen ser ud for lægerne i Esbjerg. Side 16 Figur 5 - Skærmbillede af løsningen fra lægernes system i Esbjerg De to vigtigste dele af skærmen er dem med hvid baggrund, hvor det til venstre viser, hvad patienten har afhentet på apoteket og det til højre viser, hvad den praktiserende læge har ordineret på recept. Mængden (antallet af linjer i hver skærm) er ikke helt realistisk. I realiteten er der meget ofte mange flere ordinationer. Når hjerteafdelingen henter medicinprofiler for virkelige patienter er der nogle gange flere end 100 linjer (dvs. 100 ordinationer og mere end 100 udleveringer på recept). Der er med andre ord ikke tale om få data, der bliver overført. Nogle af disse informationer er naturligvis historiske, og kun delvist relevante for medicinoverblikket på hospitalet, men de bliver hentet alligevel 4. Såfremt lægen trykker på den "blå tekst" i vinduet, overføres de væsentligste ordinationsinformationer til EPJ systemets ordineringsarbejdsgang. Ordinationen i medicinprofilen bliver således ikke automatisk kopieret, men bliver brugt til at igangsætte en ny ordination i lægens system. Denne semiautomatik er nødvendig, idet lægen i nogle tilfælde skal substituere lægemidlet med et billigere lægemiddel eller justere på andre dele af ordinationen. Pga. datagundlagets kvalitet, er det i nærværende løsning kun i begrænset omfang muligt at overføre data automatisk til den nye ordination, 4 I FMK projektet har der været meget debat om historiske data, og lægerne i dette projekt har i al væsentlighed valgt at kun aktuelle data skal overføres.
idet flere af de vigtige ordinationsinformationer er angivet i "fri tekst" og dermed mangler struktur og klassifikation 5. Side 17 Erfaring 13 Det kom bag på projektets arkitekter, at der var tale om så store mængder data, der blev kommunikeret. De store datamængder har kun i ringe grad været årsag til de ovenfor nævnte svartidsproblemer. 5 Dette er ligeledes imødegået i FMK projektet.
4 Tekniske erfaringer SOSI projektet er i hovedsagen et teknisk projekt. Det primære formål med projektet har været at skabe tekniske standarder og profiler samt afprøve disse i en realistisk sammenhæng. Derfor er der også mange tekniske erfaringer i denne rapport. Læsere uden særlig teknisk baggrund kan evt. vælge at springe over dette kapitel. Side 18 4.1 XML og Digital Signatur Én af de første erfaringer vi gjorde os i projektet var, at netop kombinationen af system-til-system integration og digital signatur er et meget komplekst område. I system-til-system integration vil der i mange tilfælde være tale om systemer programmeret i forskellige programmeringssprog, der taler sammen, og netop dette faktum stiller nogle krav til, hvilke standarder man kan benytte, idet disse som minimum skal være understøttet af de mest udbredte programmeringssprog. Moderne system-til-system integration baserer sig på XML der udmærker sig ved at være et tekstbaseret "sprog", hvor det samme stykke data kan repræsenteres en lille smule forskelligt, uden at parterne involveret i kommunikationen bliver i tvivl om, hvad meningen er med beskeden. Dette kolliderer imidlertid med digital signatur, som er ekstremt stringent med den præcise repræsentation af informationerne. Digital signatur synes at egne sig bedre til digital information (baseret på bits) frem for tekstbaseret information. Erfaring 14 Digital signatur i XML er komplekst. I SOSI projektet er der brugt meget tid på fejlsøgning som følge af digitale signaturer, der pludselig ikke var valide, pga. små tekstuelle ændringer introduceret af nogle af rammeværkerne. Kompleksiteten af XML og digital signatur blev anset som værende en meget høj tærskel for leverandører at skulle overstige ved anvendelse af de etablerede standarder og profiler. Det blev derfor besluttet at udvikle et bibliotek (se [SOSI-komponenterne]) samt nogle referenceanvendelser af biblioteket. I begyndelsen kunne en vis skepsis fornemmes blandt de leverandører, der skulle anvende biblioteket. Projektet gjorde sig dog stor umage for at bevise sundheden og robustheden af det udviklede bibliotek, blandt andet gennem meget høj testdækning (>80%) automatiserede performancetest (se bilag 4 [Seal-afleveringsnotat] for eksempler) mm. Den 7/6-2007 blev der indkaldt til et teknisk evalueringsmøde (se referat i bilag 5 [Teknisk-evaluering]).
Erfaring 15 I notatet står der flg. opsummering fra leverandørerne på SOSI bilbioteket (seal): "SOSI biblioteket er en vigtig komponent der i høj grad letter og simplificerer integrationen af systemer i forbindelse med anvendelsen af DGWS (Den Gode Web-Service). Der er ikke noget umiddelbart alternativ til SOSI-biblioteket, og at skulle implementere DWGS i alle systemer uden et bibliotek vil være meget tungt og risikofyldt." Side 19 En.NET udgave af biblioteket er også skabt i regi af MedCom (nu overdraget til Digital Sundhed) og de største programmeringssprog i sundhedssektoren er derved biblioteksunderstøttet. I takt med at de valgte standarder bliver mere modne og bedre adopteret internationalt, vil der sikkert komme bedre support for standarderne i kerne-bibliotekerne i de forskellige programmeringssprog. Det ser vi allerede en tendens til nu på.net platformen. Anvendelse af biblioteker giver nogle rigtig gode arkitektoniske egenskaber, hvilket vi også har nydt godt af undervejs i projektet. Det kan ikke undgås at skulle foretage enkelte rettelser i de profilerede standarder hen ad vejen, men da alle parter har anvendt bibliotekerne, har vi kunnet implementere disse rettelser ét sted, og dermed opgraderet til nye versioner blot ved at frigive en ny version af et bibliotek. Erfaring 16 Det har vist sig overordentligt nyttigt at have et bibliotek med tilhørende referenceimplementationer som abstraktionslag i alle komponenter i projektet. Rettelser i til profilerede standarder kan herved rettes ét sted og udsendes centralt til alle leverandører. Leverandørerne skal således kun ændre minimalt i eksisterende programkode. Figur 6 - alle parter valgte at anvende SOSI biblioteket
4.2 De primære komponenter til Pilotafprøvningen De nødvendige rettelser og nyudviklede komponenter blev kravspecificeret (se [SOSI-IdP-kravspecifikation], [SOSI-EPJ-kravspecifikation] og [SOSI- LMS-kravspecifikation]), der blev indhentet tilbud og kontrakter blev udfærdiget. Der er en række krav, der er fælles for de fleste kravspecifikationer. Disse er forankret i bilag 4 [KravTilNationaleKomponenter]. Erfaring 17 Projektet har haft gode erfaringer med udfærdigelse af minikravspecifikation med en række fælles krav til logning, Quality-of_Service (QoS) mv. Side 20 Kravspecifikationerne i projektet har været minikravspecifikationer, der har specificeret de væsentligste funktionelle og non-funktionelle krav til delprojekterne. Vi har dog i det store hele fået præcist de resultater, vi gerne ville have i projektet, hvilket vi har opnået ved dialog med leverandørerne og deres ægte ønske om at levere et produkt, som brugerne kunne få værdi af. 4.3 SOSI biblioteket - support og vedligeholdelse Som nævnt ovenfor valgte alle parter i projektet at anvende det bibliotek, som projektet stillede til rådighed. Biblioteket har vist sig også at være nyttigt for andre projekter og komponenter. I takt med at flere og flere begyndte at anvende biblioteket blev det i stigende grad vigtigt at omgive biblioteket med governancestrukturer, så f.eks. support og vedligeholdelse kom i faste rammer. Til det formål blev der iværksat en række tiltag: SOSI biblioteket blev lagt på IT- og Telestyrelsens Open Source komponentbibliotek (se [SealSoftwareBørsen]) Der blev etableret et fejlhåndteringssystem (se [SealBugTracking]) Der blev etableret en hjemmeside med kontaktinformationer til suportfunktionen (se [SealSupport]), herunder fælles email adresse support@sosi.dk Erfaring 18 Projektet har haft rigtig erfaringer med at etablere et "single-point-ofcontact", idet leverandørernes teknikere dermed ikke er i tvivl om, hvor der skal rettes henvendelse ved behov for support på SOSI komponenterne. Som det vil fremgå senere blev komponentporteføljen senere udvidet med flere komponenter, hvilket gjorde supportordningen endnu mere nødvendig og nyttig. Da denne support ordning var knyttet til SOSI projektet, og derfor i al væsentlighed en midlertidig ordning, blev det af flere omgange drøftet i styregruppen, hvorledes vi i forbindelse med projektets afslutning kunne forankre support og vedligeholdelse af komponenterne. Inspireret af tilsvarende problemstillinger blev Digital Sundhed foreslået at etablere en Operatør-ordning, der som primært ansvarsområde har at levere
1st level support samt at sikre kontinuerte kontrakter med leverandører af support og vedligeholdelse af alle komponenter i porteføljen. Vedlagt i bilag 5 ([Operatøren]) findes et oplæg fra Digital Sundhed til sådan en ordning, der blev fremlagt for bestyrelsen i Digital Sundhed, og som blev godkendt og senere etableret (se [OperatørWeb]). For en dybere introduktion til Operatørens ansvarsomområder se [OperatørNotat]. Side 21 Figur 1 Figur 7 - En drifts- og supportoperatør blev foreslået og etableret af Digital Sundhed Alle SOSI komponenter er nu overdraget til Operatøren der sikrer den fremadrettede support, vedligeholdelse og koordinering. 4.4 International interesse Der har på flere punkter været nogen international interesse omkring SOSI projektet. I forbindelse med udvikling af SOSI biblioteket, blev der udviklet en performancekomponent - Chronos, se [ChronosWeb]) - som hver nat automatisk kunne performanceteste biblioteket. Et projekt i Holland fandt performancekomponenten på IT- og Telestyrelsens softwarebørs og gik i dialog med udviklerne bag komponenten omkring nogle enkelte tilføjelser og generaliseringer. Komponenten blev ligeledes adopteret af NORDEA i deres elektroniske tinglysningsprojekt, og NORDEA har efterfølgende sponsoreret nogle af de tilføjelser og generaliseringer, som også de kunne have gavn af. Disse tilføjelser og generaliseringer gjorde det muligt at få optaget komponenten på én af d væsentligste internationale Open Source komponenttjenester (CodeHaus), og komponenten har således fået sit eget liv på det internationale Open Source marked. Nedenfor ses et par eksempler på grafer fra Chronos komponenten, hvoraf man kan se, at SOSI biblioteket skalerer fint lineært (med konstante svartider) indtil overbelastningspunktet, hvorefter der opstår en sund mætning af systemet ved overbelastning.
Side 22 Figur 8 - eksempel på skaleringsgraf fra Chronos Figur 9 - eksempel på svartidsgraf under skalering Erfaring 19 Open Source komponenter, der bliver eksponeret på internettet og som har en god kvalitet, har gode chancer for at blive opdaget af andre (internationale) parter. Sørger man for at modne komponenterne tilstrækkeligt, kan disse ende med at få international anerkendelse og begynde at "leve deres eget liv", hvor andre parter bidrager aktivt til komponentens udvikling og support, hvorefter man for alvor kan høste gevinsterne ved Open Source. I november 2007 indleverede SOSI projektet et forslag til en artikel på symposium "IDTrust 2008" ([IDTrust2008]) og anmodede om optagelse på symposiet. Artiklen (se [SOSIIDTrust]) blev optaget og projektet blev inviteret til at præsentere artiklen og deltage i en paneldebat på symposiet hos NIST i Washington DC i marts 2008.
Erfaring 20 Hvis et projekt generelt beskæftiger sig med internationale standarder og i særdeleshed hvis der er tale om praktisk anvendelse af disse standarder, er der gode muligheder for at få erfaringerne eksponeret, og dermed valideret og perspektiveret på internationale konferencer. Side 23 Efterfølgende blev projektet inviteret til Gartners IAM Summit 2008 i London [IAM], hvor der igen var stor interesse for projektets resultater og specielt hvilke perspektiver der er i videreførelse af disse resultater på nationalt plan. 4.5 Svartidsoversigt Da SOSI-løsningen i Harmoni/EMS blev taget i brug på Kardiologisk Afdeling på SVS var der først uacceptabelt lange svartider. Dels tog id-kort udstedelse set fra EPJen af mere end 30 sekunder, dels tog det afhængigt af mængden af data mellem 5 og 30 sekunder at vise data fra PEM. Set fra brugerens synspunkt er det ikke muligt at skelne om tiden bliver brugt til id-kort udstedelse eller visning af PEM-data, og brugerne måtte derfor vente op til et minut, før de kunne se data fra Medicinprofilen ved deres første kald. For at nedbringe svartiderne blev der efterfølgende iværksat en række aktiviteter men fokus på enten id-kort udstedelsen eller visning af PEM data. Id-kort udstedelse før optimering En analyse at tidsforbruget hos STSen som tog udgangspunkt i 66 målinger taget over 22 dage viste, at STSen i gennemsnit brugte 1884 ms til at udstede et id-kort (med et minimum på 477 ms og et maksimum på 7864 ms). Analysen affødte en række performance forbedringer omkring pooling og caching af ressourcer i STSen som blev sat i drift i august 2008. Størstedelen af tidsforbruget i id-kort udstedelsen skyldtes dog en uhensigtsmæssighed i samspil af et XML bibliotek (som SOSI biblioteket afhænger af) med T4 applikationsserver clusteret som Harmoni afvikles på. Applikationsserverleverandøren leverede efterfølgende en ny release af deres applikationsserver som løste problemet. Id-kort udstedelse efter optimering De seneste målinger fra Harmoni som er taget over en måneds tid viser nu fine svartider for id-kort udstedelsen: Gennemsnit Minimum Maksimum 1356 ms 1140 ms 1485 ms
Tidligere målinger har vist at tiden brugt i Sundhedsdatanettet for en id-kort udstedelse er meget konstant og ligger på omkring 200 ms. Side 24 Visning af PEM data I SOSI løsningen i Harmoni/EMS vises der både receptkøb og egen læges lægemiddelordinationer for den pågældende patient. I Harmoni/EMS blev receptdata og ordinationer i første omgang hentet i to på hinanden følgende webservice kald en efterfølgende parallelisering af disse kalde nedbragte svartiderne til omkring det halve. Nedenstående figur viser svartidsfordelingen målt fra Harmoni/EMS med 27 målinger. Selvom der er et begrænset antal målinger ses tydeligt at der er store udsving i svartiden i forhold til antal af recept køb og ordinationer. En detaljeret analyse af svartiderne med målinger fra både Harmoni/EMS og PEM viste at der var stor forskel i tiden brugt på Sundhedsdatanetforbindelsen mellem de to systemer. Nedenstående grafer viser hvor meget tid der bruges i hhv. Harmoni/EMS og PEM til at sende/modtage beskeder i forhold til deres størrelse. Målingerne er foretaget i de respektive testmiljøer; der blev anvendt fem forskellige beskeder, dvs. beskeder med samme 'antal' er helt identiske.
Side 25 Der er på nuværende tidspunkt ikke lykkedes at finde den præcise årsag til de observerede udsving i netværket, men LMS arbejder på dette sammen med deres driftsleverandør. 4.6 Andre tekniske SOSI produkter I slutningen af SOSI projektet blev FMK projektet etableret og en række nye udfordringer kom frem i lyset. I SOSI projektet var det f.eks. ét EPJ system, der skulle integreres med én tjenesteudbyder. Dette ville nu blive skaleret op til mange klientsystemer i hver region, der skulle integreres med de nye FMK services. Da FMK har valgt at benytte SOSI "billetudstederen", skulle hvert klientsystem endvidere også integreres med denne billetmekaniske. I takt med at der kommer flere nationale services vil integrationsbilledet komme til at se således ud (kun én type system for én region er vist):
Side 26 Figur 10 - Integrationslinjer ved skalering af klientsystemer og tjenesteudbydere Det fremgår ret tydeligt, at det bliver ret dyrt at integrere alle disse systemer med nationale tjenester. Under visse sikkerhedsforudsætninger vil det kunne lade sig gøre at reducere kraftigt på disse mange integrationer, og dette afstedkom et forslag til SOSI-Gateway komponenten (se overordnet specifikation her [SOSI-GW]). Komponenten blev sponsoreret af Danske Regioner (med udlæg fra Region Syddanmark) og stod færdig ca. 1/2-2008. Se afleveringsrapport i bilag 6 [SOSI-GW-aflevering] samt evt. performancetestrapport i [SOSI-GW-perftest]. Komponenten er overdraget til Operatøren. Integrationsbilledet ser således ud, efter implementering af SOSI-GW (stjerner viser, hvor SOSI seal biblioteket bliver anvendt, eller forventes anvendt (SEI)):
Side 27 Figur 11 - Integrationsbilledet efter implementering af SOSI-GW I Region Syddanmark afdækkede man endnu et behov i relation til FMK projektet. Regionen ønskede ikke at få bundet sine systemer meget hårdt til FMK tjenesterne, så f.eks. en utilgængelig FMK tjeneste ville standse arbejdsgangene på hospitalerne i regionen. Dette gav anledning til SOSI afkoblingskomponenten (DeCoupling Component - DCC, se beskrivelse i [SOSI-DCC]). Komponenten viste sig også at være interessant for RHS, hvorefter Danske Regioner gik ind og overtog komponenten, herunder sponseringen. Afleveringsrapporten for SOSI-DCC findes i bilag 7 [SOSI- DCC-aflevering] og komponenten er overdraget til Operatøren. Chronos komponenten er gennemgået og nævnt ovenfor. Afleveringsrapporten for denne komponent findes i bilag 8 [Chronos-aflevering]. Erfaring 21 Projektet har haft rigtig gode erfaringer med små og overskuelige "knopskydningsprojekter" i Open Source, hvor vi dels har fået etableret nogle meget nyttige komponenter og dels har kunnet sikre, at disse på bedste måde var i sammenhæng med eksisterende komponenter. 4.7 Sikkerhedsaspekter Som grundlag for sikkerhedskonceptet i SOSI er der valgt en model, som på den ene side sikrer personens identitet på så betryggende vis, at tjenesteudbydere kan føle sig sikker, og dermed kan leve op til love og bekendtgø-
relser som gælder for tjenesteudbydere, og på den anden side ikke stiller store krav til de decentrale parter om f.eks. revision. Projektet har bedt Cryptomathic [cryptomathic] om at lave en sikkerhedsredegørelse [sikkerhedsredegørelse] for DGWS profilen. Sikkerhedsredegørelsen påpegede enkelte ting, som ikke umiddelbart er et problem i SOSI konfigurationen, men som potentielt og generelt skal overvejes ved implementering af SOSI sikkerhedsløsningen. Det væsentligste ankepunkt i sikkerhedsvejledningen er manglen på såkaldt "message authentication/integrity". Denne problemstilling er imødegået i de kommende fællesoffentlige profiler på området, som Digital Sundhed er i dialog med ITST omkring. For en diskussion af sikkerhedsrapporten i relation til SOSI projektet se [sikkerhedsnotat]. Side 28 Erfaring 22 Vi har haft meget gode erfaringer med at inddrage sikkerhedseksperter i arbejdet omkring sikkerhedsarkitektur og review af samme og udarbejdelse af fagtekniske vejledninger. SOSI sikkerhedsmekanismerne kræver, at tjenesteudbydere tager stilling til en række sikkerhedsmæssige aspekter, inden en ny tjeneste publiceres. Som hjælp til at foretage disse valg har projektet gennem Signaturgruppen [signaturgruppen] udarbejdet en sikkerhedsvejledning, som kan ses i bilag 9 [sikkerhedsvejledning]. 4.8 Andre tekniske erfaringer Dette afsnit redegør for en række andre tekniske erfaringer vi har gjort os i projektet. 4.8.1 Sundhedsdatanettet En del af sikkerheden i SOSI varetages af et sikkert transportlag. I SOSI projektets pilotafprøvning udgøres transportlaget af sundhedsdatanettet, hvilket også er den fremadrettede anbefaling for nationale tjenester på sundhedsområdet. Erfaring 23 Under forberedelsen til integrationstesten i SOSI projektet blev der brugt en del energi i at få tilvejebragt de nødvendige aftaler på sundhedsdatanettet, samt at forfølge forskellige mulige fejlkilder og fejlkonfigurationer. Etablering af sundhedsdatanetforbindelser mv. skal derfor iværksættes i god tid og med kyndige ressourcer ved hånden. Der findes en del ekspertise omkring sundhedsdatanettet, men det er ikke altid lige nemt at finde frem til den. I forbindelse med regionaliseringen og deraf følgende temporære uklarheder om roller og ansvar, var det svært at finde de rette ressourcer, der kunne hjælpe med sundhedsdatanetopsætning i regionen. Der var dog god hjælp at finde hos personer der tidligere havde haft ansvaret for sundhedsdatanettet i amtet. Mht. knudepunktet er der god
hjælp at hente hos MedCom og den nuværende Operatør af sundhedsdatanettet (UNI-C). Side 29 4.8.2 Streaming Da SOSI-GW blev udviklet, var der en del drøftelser omkring streaming teknologier. Som normalt for SOAP beskeder, som SOSI baserer sig på, er beskeder i den nuværende version af DGWS delt op i en header, der indeholder information om beskeden og den bruger, der lægger navn til beskeden, og så selve beskeden (body). DGWS regulerer pt. alene headeren og det er derfor kun nødvendigt at læse denne header, når f.eks. brugerinformation skal verificeres. Dette muliggør anvendelse af streamingtekonologier som i høj grad kan være med til at speede parsningsprocesser mv. op. Erfaring 24 SOSI-GW har haft rigtig gode erfaringer med streaming af DGWS beskeder. Dette har dog kun kunnet lade sig gøre, pga. den måde hvorpå vi har adskilt header og body i den nuværende version af DGWS. Havde vi introduceret f.eks. message authentication, havde vi fået udfordringer med nogle af de internationale standarder og ikke mindst de værktøjer, der understøtter disse. Problemet er ikke uoverstigeligt, og der arbejdes også internationalt på at forbedre standarder og værktøjer til bedre at kunne indgå i streaming sammenhæng. 4.8.3 Testproblematikker SOSI projektet har haft en række udfordringer med test af sammenhæng mellem digital signatur og de dannede profiler. Der findes ikke testcertifikater i OCES produktionsmiljøet, hvilket betyder, at man skal have en "rigtig bruger", dvs. konkret i SOSI projektets tilfælde en ansat i Region Syddanmark til at stille op og medvirke til tests i produktionssammenhæng. Vælger man her en superbruger, er denne typisk ikke en autoriseret kliniker, og må derfor ikke uden videre få adgang til kliniske produktionsdata. Vælger man en læge, risikerer man at få afslag, idet disse (med rette) prioriterer tid at behandle patienter frem for at teste IT systemer. Erfaring 25 Test af digital signatur i produktionsmiljøer kan være vanskellig og kræver en del planlægning. Resultatet bliver nemt, at man ikke kan teste det egentlige system, før det er kommet i produktion/drift.
5 Projektledelseserfaringer Projektet blev etableret som et PRINCE2 projekt allerede tilbage i 2005. Der er dog flere tilfælde af fravigelser fra PRINCE2 metoden - også nogle, hvor en mere formel opfyldelse af PRINCE2 ville have kunnet gavne projektet. Side 30 Erfaring 26 Før PRINCE2 metoden anvendes til at initiere et projekt, er det vigtigt at de vigtigste PRINCE2 elementer er til stede i projektet. Specielt er det vigtigt at have en business case at styre projektet efter, og at styregruppen konfigureres jf. PRINCE2. Erfaring 27 Projektet har haft stor gavn af at opdele projektorganisationen i forskellige arbejdsgrupper. Hvis disse arbejdsgrupper arbejder parallelt, er det dog vigtigt at de fornødne ressourcer tilføres projektet. Et godt eksempel på, at projektet ikke helt tog styregruppens sammensætning alvorligt var da styregruppeformanden (der både bar rollen styregruppeformand og seniorbruger i Region Syddanmark) skiftede job fra Region Syddanmark til Digital Sundhed. Derved mistede projektet sin seniorbruger og kontaktpunkt ind i Region Syddanmark. Dette har givet mange udfordringer mht. commitment, fokus og kommunikation med regionen på alle niveauer. Erfaring 28 Hvis nogle af de vigtige roller i et PRINCE2 projekts styregruppe ændres/mistes, skal disse roller øjeblikkeligt erstattes af nye medlemmer i styregruppen. Som det fremgår af tidligere erfaringer i denne rapport har projektet haft svært ved at bevare et stort momentum i forbindelse med implementeringen af SOSI løsningen i klinikken i Esbjerg. Dels har projektet oplevet relativt komplekse tekniske udfordringer og dels har vi oplevet, at det var svært at få travle læger til at adoptere løsningen. Erfaring 29 Det ville have hjulpet projektet umådeligt meget at styregruppen været bemandet med en seniorbruger med ansvar for at sikre kvaliteten i den tekniske og kliniske implementering i Region Syddanmark kombineret med en lokal ildsjæl, der kunne have taget sig af alle de praktiske opgaver samt sørget for en meget tæt opfølgning.
Erfaring 30 Projektet har igennem hele forløbet anvendt en risikolog som ét af styringsredskaberne i projektet. Dette har vist sig at være meget nyttigt og givet mulighed for at handle proaktivt. Side 31 Som "projektarkiv" har projektet anvendt TWiki (se [TWiki]). TWiki er et webbaseret "groupware" værktøj, der både har udgjort det som et dokumentstyringsredskab, kommunikationsredskab, versionsstyringssystem og hjemmeside for både projektet, arbejdsgrupperne, styregruppen, supportordningen og alle komponenterne (se [SOSIDK]). Erfaring 31 Projektet har ekstremt gode erfaringer med TWiki som projektværktøj. Intet værktøj er dog bedre end dets anvendelse og en risiko ved eksponerede projektinformationer er jo, at disse bliver forældede og ikke bliver opdateret. Det har vi set en række eksempler på i SOSI projektet. Erfaring 32 Projektet har fået gode tilbagemeldinger på at udsende hyppige statusnoter. I projektet har vi forankret disse statusbeskeder på TWiki. Erfaring 33 Vi har fået gode tilbagemeldinger på at være ærlige omkring evt. tvivlstilfælde eller alternative muligheder. I begyndelsen af projektet udarbejde vi på TWiki en "djævlens advokat" side, hvor vi nævnte alle de udsagn om alternative løsninger vi enten selv kunne finde på, eller som vi havde hørt andre ytre, og dernæst argumentere for, hvorfor vi ikke valgte den vej [DjævlensAdvokat]. Erfaring 34 Projektet har haft stor glæde af at kunne drøfte problemer og mulige løsninger med udviklere fra de forskellige leverandører. Det kræver naturligvis at projektet internt har nogle tekniske ressourcer (gerne med samme baggrund som udviklerne), men har projektet det, kan mange problemer og mulige konfrontationer forhindres ad denne vej.