LAKESIDE. KIH Databasen. Analyse af arkitektur, modenhed og kvalitet. Technology Readiness Levels. KIH databasen april 2015

Transkript

1 LAKESIDE KIH Databasen Analyse af arkitektur, modenhed og kvalitet Udvikling af system og støttesystemer Test, ibrugtagelse og drift TRL 8 TRL 9 TRL 7 Research på gennemførlighed Teknologiudvikling TRL 2 Teknologidemonstration TRL 3 TRL 4 TRL 5 TRL 6 Technology Readiness Levels Basal teknologi research TRL 1 KIH databasen april 2015 LAKESIDE A/S Marselisborg Havnevej 32, 1. sal DK-8000 Århus C Denmark tlf [email protected]

2 1 Ledelsesresumé Overordnede konklusioner: a. Arkitektur: Det er Lakesides vurdering, at de forretningsmæssige gevinster ved KIH Databasen i høj grad hænger sammen med en åben arkitektur med ingen eller få bindinger til proprietære snitflader og med høj grad af (international) standardisering. b. Arkitektur: Det er Lakesides vurdering, at KIH Databasen bør bringes i bedre overensstemmelse med de rammesættende referencearkitekturer for telemedicinsk infrastruktur og at to væsentlige migreringsscenarier bør overvejes i den forbindelse. Hvilken af disse scenarier der er mest optimal, afhænger af en række faktorer, som parterne bag KIH bør vægte og prioritere. c. Modenhed: Det er Lakesides vurdering, at KIH Databasen i skrivende stund (april 2015) befinder sig på TRL 6, det vil sige Functional Featurecomplete Beta, og at tre væsentlige testaktiviteter står mellem det nuværende og det anbefalede modenhedsniveau for national udrulning (TRL 9). d. Modenhed: Lakeside vurderer, at det vil være relativt omkostningstungt at bringe KIH Databasen til modenhedsniveau TRL 9. Det bør derfor overvejes, om det vil være mere fornuftigt at erhverve et standardprodukt eller modent Open Source produkt på TRL 9, for de dele af arkitekturen, som kan erstattes af sådanne. e. Kvalitet: Lakeside vurderer, at design- og teknologivalg i KIH Databasen er fornuftige, men erfarer også at systemets performance ikke er testet. Der er derfor risiko for, at produktet kan indeholde uhensigtsmæssigheder rent programmeringsmæssigt, der kan medføre manglende performance ved f.eks. langvarig belastning eller overbelastning. f. Pålidelighed: Lakeside vurderer, at en national udbredelse af KIH Databasen vil kræve ændringer i driften af denne. g. Informationssikkerhed: Lakeside vurderer, at den eksisterende informationssikkerhedsløsning ikke i tilstrækkelig grad imødekommer intentionerne i gældende dansk lovgivning. Dette udgør en barriere for videre udrulning af produktet. h. Informationssikkerhed: Videregivelsen af data fra KIH Databasen til Labdatabanken og Sundhed.dk s P-Indeks vækker bekymring, idet det er uklart, hvorvidt borgeren har givet samtykke til denne videregivelse. Lakeside her ikke fundet nogen teknisk sikring af samtykkekontrol i den nuværende løsning. i. Vedligeholdelsesegenskaber: Lakeside vurderer, at der er fornuftige muligheder for at vedligeholde den nuværende KIH Database. Der er dog mangler på dokumentationsområdet. j. Portabilitet: Lakeside vurderer på baggrund af inspektion af programkode og dokumentation og på baggrund af interviews med leverandøren, at løsningen har gode portabilitets- og tilpasningsegenskaber. k. Open Source (overordnet): Lakeside vurderer, at KIH Databasens status som open source-projekt, samt rammen det forvaltes i, tilsammen danner et godt fit til et egentligt open source økosystem. Overordnede anbefalinger: Arkitektur Ark-01 Ark-02 Ark-03 Det er en forudsætning for en lagsigtet bæredygtig informationssikkerhedsløsning i KIH Databasen, at der iværksættes en modernisering af nationale informationssikkerhedsstandarder- og løsninger. Parterne bag KIH Databasen bør med udgangspunkt i de i denne rapport skitserede migreringsscenarier afgøre, hvilket migreringsscenarie der bør iværksættes. På baggrund af valgt migreringsscenarie skal der udarbejdes et roadmap for migrering af KIH Databasen til målarkitekturen. Migre- LAKESIDE side 2 / 49

3 Ark-04 ringen skal omfatte alle nuværende integrationer hos eksterne parter. Uanset valg af migreringsscenarie bør parterne bag KIH Databasen tage initiativ til at konstituere/udpege et råd, hvor de relevante dokumenttyper kan besluttes og underlægges fornøden styring. Dette er en forudsætning for migrering til målarkitekturen. Hvem rådet skal bestå af, rådets forretningsorden etc. forholder denne rapport sig ikke til. Modenhedsanalyse ( Technology Readiness ) TRL-01 TRL-02 TRL-03 Kvalitetsanalyse Kval-01 Kval-02 Kval-03 Kval-04 Kval-05 Kval-06 Kval-07 Open Source OSS-01 OSS-02 OSS-03 OSS-04 OSS-05 OSS-06 Der bør planlægges og gennemføres en pilotdrift i samarbejde med minimum én ekstern part med anvendelse af de standardiserede snitfalder. Der bør planlægges og gennemføres grundige og strukturerede performancetests. KIH Databasen bør gennemføre et IHE connectathon som et IHE XDS repository (evt. on-demand). Der bør udarbejdes sikkerhedsanalyser herunder en Privacy Impact Assessment (PIA) hvorfra krav til informationssikkerhed uddrages. På baggrund af de udførte sikkerhedsanalyser, skal de nødvendige tekniske sikringsforanstaltninger i forhold til informationssikkerhed implementeres. NSI s sikkerhedskomponenter bør anvendes i den kommende informationssikkerhedsløsning i KIH Databasen. På sigt bør en indarbejdelse af de moderniserede sikkerhedstandarder og løsninger finde sted. Der bør udarbejdes snitfladedokumentation for PHMR snitfladen samt dokumentation af fejlsituationer og forretningsregler. Der skal udarbejdes testdokumentation (strategier, planer, rapporter). På sigt anbefales en udarbejdelse af resterende manglende dokumentation, dvs. dokumentation af tredjepartskomponenter, forbedret beskrivelse af arkitekturvalg og sikkerhedsmodel samt kravspecifikation. Der skal udarbejdes et overordnet roadmap for visionen omkring OpenTele og KIH i Open Source sammenhæng. Aktiviteterne vedrørende konsolidering af kode og dokumentation i én autoritativ kilde skal afsluttes snarest muligt. Der skal håndhæves en entydig sprogpolitik i både issue-tracking og kode-repository. Dokumentation bør udarbejdes på engelsk. Der bør gøres en indsats for at få øget aktivitetsniveauet i projektet og få flere parter til at bidrage aktivt. Der skal udarbejdes et release roadmap for projektet (mere detaljeret end det overordnede roadmap i OSS-01). LAKESIDE side 3 / 49

4 Kritikalitetsmatrix: Nice to have OSS-03 OSS-05 Ark-01 Ark-02 Ark-03 Ark-04 Need to have TRL-01 Kval-01 Kval-02 Kval-03 Kval-05 OSS-01 OSS-02 Kort sigt TRL-02 TRL-03 Kval-04 Kval-06 Kval-07 OSS-04 OSS-06 Længere sigt LAKESIDE side 4 / 49

5 Revisionshistorik Version Dato Ans. Beskrivelse JRI Disposition og råt udkast JRI Udviklingsversioner internt hos Lakeside JRI Samlede konklusioner indarbejdet. Udsendt til gennemsyn i følgegruppe og udvalgte eksterne parter JRI Migreringsscenarier indført efter drøftelser med følgegruppen JRI Final review. Udsendt til parterne JRI Fejl i anvendelse af iti-41/42/43/61 rettet. Domæneråd/Domæneudvalg erstattet med råd. LAKESIDE side 5 / 49

6 Kontaktperson Chefkonsulent Jan Riis Lakeside A/S tlf LAKESIDE side 6 / 49

7 Indholdsfortegnelse 1 Ledelsesresumé Indledning Metode og rapportens opbygning Tilblivelsesmetode Afgrænsninger Forkortelser og termer Arkitekturanalyse AS-IS arkitekturen Målarkitekturen (TO-BE) Migrering af KIH Databasen fra AS-IS til TO-BE Scenarie 1 Opsamling + Repository Scenarie 2: On-Demand repository Konklusioner og anbefalinger Modenhedsanalyse ( Technology Readiness ) Vurdering af teknologiparathed / modenhed Konklusioner og anbefalinger Kvalitetsanalyse ( SQuaRE ) Performance / Effektivitet Teknologivalg i relation til performance og skalering Ressourceforbrug og udnyttelse Konklusioner og anbefalinger Vurdering af pålidelighed Tilgængelighed Fejltolerance og rehabiliteringsevne Konklusioner og anbefalinger Vurdering af informationssikkerhed Konklusioner og anbefalinger Vurdering af vedligeholdelsesmuligheder Vurdering af portabilitet Kritikalitet af anbefalinger vedrørende kvalitet KIH Databasen i et Open Source Økosystem KIH Databasens fit til et Open Source Økosystem Overordnet vurdering Konklusioner og anbefalinger Vurdering af Community Quality Ecosystem Network Quality Kritikalitet af anbefalinger vedrørende Open Source Økosystem Samlede konklusioner og diskussion Konklusioner på arkitekturanalysen Konklusioner på modenhedsanalysen Konklusioner på kvalitetsanalysen Konklusion på KIH i et Open Source økosystem Diskussion vedrørende anskaffelse af standardprodukt Referencer LAKESIDE side 7 / 49

8 2 Indledning Med henblik på at få et solidt grundlag for prioritering i den kommende økonomiforhandling (ØA-2016) har regionernes it arkitekturråd (RITA) bedt MedCom om at iværksætte udarbejdelsen af en uvildig analyse af KIH Databasen. RITA lagde i anmodningen særlig vægt på at få afdækket, hvorledes KIH Databasen i sin nuværende form passer ind i målarkitekturen for telemedicinske løsninger (arkitekturanalyse), samt få analyseret hvilken modenhed og kvalitet KIH Databasen har i sin nuværende form. Herunder produktets dokumentationsgrad og grad af parathed til at indgå i et Open Source økosystem. RITA lagde endvidere vægt på, at analysen skulle komme med operationelle anbefalinger. Dvs. forslag til konkrete aktiviteter som kunne prioriteres og planlægges i forbindelse med økonomiforhandlingerne. Endelig har RITA efterspurgt input til, hvor vidt KIH Databasen skal undergå en modning, eller om parterne bag KIH Databasen hellere skulle bruge ressourcerne på at anskaffe og udbrede et standardsystem. Nærværende rapport udgør dokumentationen for arkitektur- og modenhedsanalysen af KIH Databasen. Det er vigtigt at indskærpe, at rapporten udelukkende forholder sig til produktet KIH Databasen. Rapporten forholder sig således ikke til, om der skal være én centralt drevet national KIH Database løsning (én opsamlingsplatform, ét arkiv og delingsrepository), eller om KIH Databasen hellere skulle være et løsere koncept bestående af flere elementer, der tilsammen udgør en national distribueret KIH Database løsning. Denne diskussion overlades til parterne bag KIH Databasen. 2.1 Metode og rapportens opbygning Rapporten består af 6 kapitler: Indledning Modenhedsanalyse Arkitekturanalyse Kvalitetsanalyse Open Source analyse Samlet konklusion Efter nærværende indledning vil rapporten i kapitlet Arkitekturanalyse analysere og vurdere KIH Database arkitekturen både i sin nuværende udformning og i relation til målarkitekturen for telemedicinske løsninger. Kapitlet analyserer og vurderer det gab, der er mellem den nuværende KIH Database arkitektur og en formodet fremtidig KIH Database arkitektur. Kapitlet fremsætter forslag til, hvilke tiltag der på et arkitektonisk plan bør iværksættes for at modne løsningen. Derefter vurderes KIH Databasens modenhed, kvalitet og parathed i forhold til at indgå i et Open Source økosystem. Til brug for disse analyser er der taget udgangspunkt i tre standardiserede evalueringsteknikker: Technology Readiness Assessment - The TRL scale is a metric for describing the maturity of a technology [TRL]. ISO/IEC 25010: Software product Quality Requirements and Evaluation [SQuaRE] QuESo - Quality Model for Open Source Software Ecosystems [QuESo] LAKESIDE side 8 / 49

9 Alle evalueringsteknikker er forberedt til at kunne evaluere meget forskellige løsninger, og det har været nødvendigt at tilpasse disse evalueringsteknikker, så de passer til en evaluering af KIH Databasen som komponent i en telemedicinsk infrastruktur. I tilpasningen er der taget udgangspunkt i hvilke aktører, der anvender KIH Databasen. F.eks. anvendersystemer, driftsteknikere, vedligeholdelsesleverandør, etc. I nedenstående tabeller er vist, hvilke dele af evalueringsteknikkerne, der er udeladt, samt hvilke aktører, Lakeside forventer vil være mest interesserede i analyseresultatet: Functional Suitability Performance efficiency Comp5 atibility Usability Reliability Security Maintainability Portability Functional/completeness Functional/correctness Functional/appropriateness Time/behaviour Resource/utilisation Capacity Co:existence Interoperability Appropriateness/recognizability Learnability Aktører Anvendersystemer x x x x x x x x x x x Dækket/i/ Dækket/i/ Drift///Administration x x x x x x x x x x x x arkitektur/ arkitektur/ Udvikling///Vedligehold x x x x x x x x afsnittet afsnittet Open/Source/Operatør x x x x x x x x x x x x x x x x Tabel 1 - Aktører og deres interesser i de forskellige analyseperspektiver for ISO/IEC 25010:2011. Søjler uden krydser dækkes ikke af rapporten Operability User/error/protection User/interface/aesthetics Accessibility Maturity Availability Fault/tolerance Recoverability Confidentiality Integrity Non:repudiation Accountability Authenticity Modularity Reusability Analysability Modifiability Testability Adaptability Installability Replaceability Platform) Quality Community) Quality Ecosystem) network)quality Aktører Anvendersystemer x x x x Dækket,af, Drift,/,Administration x x ISO/IEC, Udvikling,/,Vedligehold x x x x 25010:2011 Open,Source,Operatør x x x x Maintenance,Capacity Process,Maturity Ressource,Health Tabel 2 - Aktører og deres interesser analyseperspektiver for QuESo vurderingsmetoden. Network,Health For hvert perspektiv bliver anbefalinger fremhævet i blå bokse som illustreret her: Delkonklusion/Anbefaling (eksempel): <konklusionstekst> I hvert kapitel bliver kapitlets anbefalinger indplaceret i en kritikalitetsmatrice, som den nedenstående: LAKESIDE side 9 / 49

10 Indsatsområder Nice to have Need to have Foranstaltninger som giver værdi for aktører nu og her men som ikke er vitale for en egentlig driftsmodning Vurdering af områder inden for hvilke der bør iværksættes umiddelbare foranstaltninger for at driftsmodne KIH Databasen Kort sigt Generelle foranstaltninger som på sigt skaber merværdi for borgere og klinisk personale Afklaring af områder hvor det er nødvendigt at KIH Databasen på længere sigt konvergerer mod nationale og internationale standarder Længere sigt I slutningen af dokumentet findes de samlede konklusioner og anbefalinger samt en referenceliste. 2.2 Tilblivelsesmetode Rapporten er udarbejdet over en 6 ugers periode i februar/marts Følgende parter har givet input til rapporten gennem interviews / møder: - Regionernes It arkitekturråd (RITA) v. Henrik Hammer Jordt, Region Midtjylland - MedComs følgegruppe, bestående af repræsentanter fra MedCom, Region Hovedstaden, Region Midtjylland, Region Nord, Københavns Kommune, National Sundheds It (NSI), samt repræsentanter fra PL Forum (sammenslutning af leverandører af lægepraksissystemer). - Stiftelsen for Softwarebaserede Sundhedssystemer 4S v. Torben Bisgaard Haagh og Michael Christensen - Leverandøren af KIH Databasen, Silverbullet A/S KL har været inviteret til at give input til rapporten, men da kommunerne på nuværende tidspunkt ikke har erfaringer med at anvende KIH Databasen, har KL ikke ønsket at deltage i analysen. Rapporten er fremsendt til gennemsyn hos ovennævnte parter i udkast, hvorefter den endelige rapport er udarbejdet og fremsendt til MedCom for videre foranstaltning. Hos Lakeside har følgende personer arbejdet på rapporten: - Partner Jan Riis - Partner Bent Bilstrup - Seniorkonsulent Anders Agerholm - Seniorkonsulent Christian Gasser 2.3 Afgrænsninger - Analysen er ikke en vurdering af KIH projektet, leverandøren, kunden eller de historiske omstændigheder, der har bidraget til KIH Databasens nuværende udformning. - Analysen omhandler alene KIH Databasen og inkluderer således ikke en analyse af de omkringliggende løsninger, herunder OpenTele løsning. - Vurdering af den tekniske løsning medtager ikke Usability perspektivet fra ISO/IEC 25010:2011. LAKESIDE side 10 / 49

11 - Analysen forholder sig ikke til forretningsarkitekturen men udelukkende til KIH Databasens tekniske arkitektur og enkelte aspekter af informationsarkitekturen. - Analysens afdækning af open source-perspektivet dækker alene grundlaget og potentialet for at opbygge og vedligeholde et open source-økosystem med KIH Databasen som komponent. Analysens afdækning og vurderinger gælder således ikke den forvaltning- og operatørramme (4S), som KIH Databasen er indeholdt i. 2.4 Forkortelser og termer Term/Forkortelse API Autentifikation Autorisation Continua DGWS EPJ IHE IHE-XCA IHE-XDR IHE-XDS Integritet LoA LPS NSI NSP Patient PHMR Beskrivelse Application Programming Interface. Et programmeringsbibliotek, der stiller funktioner til rådighed for programmøren gennem et programmeringsinterface. Kobling mellem en bruger og en digital identitet, baseret på afgivelse af akkreditiver. Styring og håndtering af brugerens rettigheder til adgang til ressourcer, herunder data, tjenester og funktionalitet Continua Health Alliance is a non-profit, open industry organization of healthcare and technology companies joining together in collaboration to improve the quality of personal healthcare. Continua's mission is to establish an ecosystem of interoperable personal connected health systems. Den Gode Webservice. Elektronisk Patientjournal. En portefølje af sundhedsfaglige itsystemer og -moduler, der tilsammen udgør den daglige itværktøjskasse for bl.a. klinikere på sygehuse. Integrating the Healthcare Enterprise. IHE Cross Community Access. Et sæt IHE profiler der gør det muligt at foretage distribuerede IHE-XDS søgninger og dokumentrekvireringer. Cross-enterprise Document Reliable Interchange. Profil til udveksling af dokumenter mellem dokumentkilder og repositories. Se også IHE-XDS. IHE Cross-Enterprise Document Sharing Integration Profile. Sikring af kommunikationen, således at serviceudbyder og serviceaftager er garanteret, at beskederne ikke ændres mellem afsender og modtager. Level of Assurance. Et tal der angiver hvor "stærkt" en identitet er autentificeret. LoA refererer både til de tekniske metoder og akkreditiver, der er anvendt i autentificeringen, men også til de udstedelsesprocedurer, der omgiver akkreditiverne. Lægepraksissystem. Sektor for National Sundheds-it, Statens Serum Institut. Den Nationale Serviceplatform på sundhedsområdet. En platform med en række it-infrastrukturelementer, der gør det nemmere, billigere og mere sikkert at udveksle sundhedsdata Er en person, der gennemløber et behandlingsforløb. PHMR is a HL7 document standard describing constraints on the CDA Header and Body elements for Personal Healthcare Monitoring Report (PHMR) documents. Mostly containing analysed and raw information of data generated by personal healthcare monitoring devices such as glucometers, BP cuffs, LAKESIDE side 11 / 49

12 thermometers, weight scales, etc. Se også PIA Privatlivets fred SOAP SQL SSL Tilgængelighed Privacy Impact Assessment eller Data Protection Impact Assessment (EU). På dansk er PIA'er ofte benævnt som privatlivsimplikationsanalyse eller konsekvensvurdering for privatlivet. Beskyttelse af potentielt personhenførebare informationer. Simple Object Access Protocol. Standard for Web Service kommunikation. Structured Query Language. Et it-teknisk sprog til formulering af databaseopslag, manipulation og definition. Secure Socket Layer. En standard for sikker digital kommunikation. Sikring af en given service så brugeren har adgang til servicen under fastlagte rammer. LAKESIDE side 12 / 49

13 3 Arkitekturanalyse Parterne i sundhedsvæsenet har gennem de seneste 3-5 år udarbejdet referencearkitekturer, der sætter rammerne for infrastrukturen for telemedicinske løsninger. Nærværende kapitel vurderer mulighederne for og udfordringerne ved, at KIH Databasen kan indgå i realiseringer af disse referencearkitekturer. 3.1 AS-IS arkitekturen KIH Databasen er blevet designet og udviklet i perioden 2012 til 2014, og er i samme periode også blevet afprøvet gennem tre telemedicinske innovationsprojekter. Løsningen er en SQL-database, hvortil der udstilles en række services; nogle proprietære andre standardiserede. I begyndelsen var der fokus på at skabe et produkt til håndtering af kronikerdatasættet, men senere skiftede fokus mod, at løsningen i højere grad skulle nærme sig internationale standarder 1 og nationale referencearkitekturer 2 på området. KIH Databasen blev udvidet med disse standardsnitflader, og der blev etableret en konverteringsløsning, hvor data i databasen blev konverteret til PHMR 3 dokumenter. Den overordnede AS-IS arkitektur er illustreret i nedenstående Figur 1. Sundhedsperson PHMR OpenTele ITI-41 ( provide and register ) ITI-43 ( retrieve document set ) Borger Sundhed.dk OIOXML data Opret+Hent SQL PHMR builder ITI-42 (indeksering) KIH Databasen IHE-XDS/XDR realisering Figur 1 - Overordnet AS-IS arkitektur af KIH Databaseløsningen. Enkelte integrationer udeladt af simplificeringshensyn. Det skal bemærkes, at den nuværende OIOXML rekvireringssnitflade alene returnerer dokumenter, der er inddateret gennem den tilhørende OIOXML registreringssnitflade. Dokumenter, der er tilgået databasen gennem ITI-43 / PHMR snitfladen vil således ikke være synlige for borgeren hos eksempelvis Sundhed.dk. Bemærk endvidere at Sundhed.dk i dag er den eneste anvender af OIOXML rekvireringssnitfladen. OpenTele anvender pt. ikke KIH Databasen som arkiv. Ifølge leverandøren er årsagen til dette dels performancehensyn og dels, at OpenTele dermed kan opbevare data i et format, der er tilpasset de sundhedsfaglige anvendelser af data. Ulempen ved alene at opbevare egne data er, at data, der kommer fra andre opsam- 1 IHE-XDR, IHE-XDSXDS, HL7 PHMR 2 [REFARK_DELING] [REFARK_OPSAMLING] 3 Mere præcist den danske profil af PHMR. Se [PHMR-DK]. LAKESIDE side 13 / 49

14 lingspunkter, ikke kan indgå i sundhedspersonernes beslutningsgrundlag eller som information til borgeren. Der er i skrivende stund ingen produktionsanvendelser af IHE snitfladerne på KIH Databasen. I regi af Initiativ 1.4 [INIT-1.4] pågår der dog afprøvning af disse med anvendelse af dokumentdelingsservicen på NSP og dennes XDS registry som indekseringspunkt, og med mulighed for at tilgå KIH Databasens PHMR dokumenter gennem NSP ens dokumentdelingsservice. Som det fremgår af nedenstående Figur 2, er der yderligere integrationer fra den nuværende KIH Database til hhv. Labdatabanken (kopiering af KIH data til Labdatabanken), Sundhed.dk (integration til P-indeks hos Sundhed.dk) samt fra PHMR generatoren til NSP ens CPR stamdata (PHMR kræver oplysninger om borgeren, som ikke er i SQL databasen). Bemærk: den nævnte NSP CPR integration er kun nødvendig i forhold til konvertering af data, der kommer til KIH Databasen gennem OI- OXML snitfladerne. PHMR ITI-41 ( provide and register ) ITI-43 ( retrieve document set ) ITI-42 (indeksering) KIH Databasen Opret+Hent SQL PHMR builder CPR opslag NSP Kopi til labdatabanken P-indeks Labdatabanken Sundhed.dk Figur 2 - Yderligere systemafhængigheder mellem KIH Databasen og eksterne systemer. Videregivelsen af data fra KIH Databasen til Labdatabanken vækker bekymring, idet det er uklart, hvorvidt borgeren har givet samtykke til denne videregivelse, hvilket der ikke er nogen teknisk sikring af i den nuværende løsning. 3.2 Målarkitekturen (TO-BE) I forbindelse med nærværende analyse har MedCom etableret en følgegruppe bestående af repræsentanter fra regioner, stat og private aktører. Følgegruppen mødtes med analyseteamet ved opstarten af analyseopgaven og i den forbindelse blev det indskærpet, at målarkitekturen ikke har ændret sig siden analysen af OpenTele [OpenTeleAnalyse]. Nedenfor gengives målarkitekturen kort. Grundlæggende ønsker parterne, at KIH Databasen retter sig mod de relevante nationale referencearkitekturer, idet disse netop indrammer de væsentligste drivere, tendenser, teknologier og standarder: - Referencearkitektur for opsamling af helbredsdata hos borgeren version 1.0 [REFARK_TELE] - Referencearkitektur for deling af dokumenter og billeder version 1.0 [RE- FARK_DELING] - Referencearkitektur for informationssikkerhed, sept [REFARK_SIKKERHED] I referencearkitektur for opsamling af helbredsdata hos borgeren er det referencearkitekturens hovedanbefaling, at løsninger baserer sig på HL7 standarden (PHMR). LAKESIDE side 14 / 49

15 Derudover sætter referencearkitekturen rammer for, hvilke metoder og standarder, der bør anvendes ved deling af data. Her bliver der peget på IHE profiler (XDS, XCA, XDR), hvilket bygger broen til referencearkitekturen for deling af dokumenter og billeder. Målbilledet er skitseret i nedenstående Figur 3. Der er tale om en målarkitektur, der ligger inden for dokumentdelingsparadigmet dvs. en arkitektur, hvor data deles gennem søgning og rekvirering af selvindeholdte dokumenter. I målarkitekturen skelnes der konceptuelt mellem platforme til opsamling og platforme til arkivering og deling af dokumenter. Borger Målingskilder Lokale opsamlingsenheder Løsninger til lokal opsamling af data (apps mv.) HL7 ORU Centrale opsamlingspunkter Dataopsamling Fagsystemer Sundheds professionel IHE-XDR [iti-41] + HL7 PHMR IHE-XDS / XCA [iti-18+43] Platforme til dokumentarkivering og -deling Platform til informationsdeling Platform til informationsdeling IHE XDS IHE XDS / XCA IHE document XDS document IHE XDS / XCA document repositories document registry repositories registries Centrale sikkerhedsservices Sikker login Nationale sikk. løsninger MinLog Etc. Figur 3 En målarkitektur for telemedicinske opsamlings- og delingsløsninger. Målarkitekturen består af følgende logiske elementer (som alle forekommer i referencearkitekturen): Lokale opsamlingsenheder. De lokale opsamlingspunkter er apps og andre it-tekniske løsninger, som understøtter opsamling af målinger og andet hos borgeren. Standardiseringsmæssigt er det Continua rammeværket, der er drivende på dette område, dvs. det er grundlæggende profilering af DS/EN ISO standarderne , , og xx, der her kommer i spil ift. måleudstyr og dataopsamling. Centrale opsamlingspunkter. De centrale opsamlingspunkter samler data fra de tilknyttede lokale opsamlingspunkter på tværs af lokationer. De centrale opsamlingspunkter vil i arkitekturen LAKESIDE side 15 / 49

16 optræde som producent af dokumenter (jf. referencearkitektur for deling af dokumenter og billeder) og indekserer og deler disse dokumenter gennem tilknyttede dokumentdelingsplatforme. Denne deling af data sker gennem IHE XDR profilerne 4. Det er således i opsamlingspunkterne, at data samles og sammenstilles til egentlige IHE XDS dokumenter dokumenttyper, som parterne i domænet (affinitetsdomænet) er blevet enige om at dele data på baggrund af. De centrale opsamlingspunkter kan stille servicesnitflader til rådighed for applikationer tilknyttet netop det pågældende opsamlingspunkt. Disse services vil være mere fleksible end rekvirering af data gennem dokumentdelingsplatformen, idet de returnerede datasæt kan være tilpasset på baggrund af inputparametre til servicen. Desuden kan disse services give mulighed for højere ydelse i anvendersystemerne, idet de ikke kræver forespørgsel i indekset inden opslag og idet returdata kan være optimeret til brugsscenariet (leverer præcis de data, der er brug for, herunder kun de nødvendige opmærknings- og metadata). Serviceanvendere skal naturligvis være meget opmærksomme på, at hvis disse snitflader anvendes, så modtages der kun data fra det pågældende centrale opsamlingspunkt, hvorimod der modtages dokumenter fra alle opsamlingspunkter, hvis dokumentdelingsplatformen anvendes. Rapporten her forholder sig ikke til, om der skal være ét eller flere centrale opsamlingspunkter i relation til klinisk integreret hjemmemonitorering. Denne diskussion overlades til parterne omkring KIH. Hvis der etableres flere centrale opsamlingspunkter for KIH, vil det være muligt ved hjælp af nationale services, at udstille konsoliderede servicesnaitflader (ikke dokumentbaseret). En analyse af dette er dog også uden for scope af denne rapport. Platforme til dokumentdeling (IHE XDS / XCA realiseringer). Denne del af arkitekturen indeholder indeksering og evt. opbevaring af de opsamlede helbredsdata på dokumentform og reguleres af referencearkitektur for deling af dokumenter og billeder. Hvilke affinitetsdomæner, der konkret skal etableres, bliver ikke nærmere belyst i denne rapport. Arkitekturen er åben for en næsten vilkårlig organisering af domæner, der kan spænde fra mange realiseringer inden for den enkelte region/kommune til ét centralt domæne, der indeholder alle parters telemedicinske informationer. Rammestandarderne er her IHE XDR/XDS/XCA. Fagsystemer. Fagsystemerne består af de eksisterende og kommende it-værktøjer til sundhedspersoner. F.eks. EPJ, LPS og EOJ systemer. Igen er arkitekturen åben for, at vilkårlige aktører kan etablere fagsystemer, der kan understøtte de tilknyttede sundhedspersoners arbejdsgange ift. telemedicin. Fagsystemerne søger og rekvirerer dokumenter fra XDS løsningerne. Sikkerhedsløsninger. Løsningerne i alle øvrige komponenter skal integreres med eksisterende centrale sikkerhedsløsninger, så den nødvendige 5 informationssikkerhed etableres. Det skal bemærkes, at arkitekturen er en logisk arkitektur, så i praksis ville en løsning godt kunne bestride rollen som opsamlingspunkt og dokumentdeling på samme tid, så længe der blot er den fornødne separation og understøttelse af standarder. 3.3 Migrering af KIH Databasen fra AS-IS til TO-BE KIH Databasen har i sin nuværende form både egenskaber, der hører til centrale opsamlingspunkter og til dokumentarkivering og -deling. Parterne bag KIH Databasen ønsker, at disse egenskaber også findes i den migrerede KIH løsning, hvilket nedenstående migreringsscenarier begge imødekommer. 4 Mere specifikt den tekniske snitflade [iti-41] der deles mellem IHE-XDR og IHE-XDS. 5 Nødvendigheden bør afdækkes gennem sikkerhedsanalyser. Se mere om dette senere i rapporten. LAKESIDE side 16 / 49

17 Hvis KIH løsningen skal overholde referencearkitekturerne, bør parterne bag KIH Databasen etablere/udpege et råd, og her definere de dokumenttyper, som anvenderapplikationerne reelt har behov for i betjeningen af sundhedspersoner og borgere. Disse vil sandsynligvis være mere omfangsrige dokumenter end de nuværende enkeltmålingsdokumenter. Det vil kræve ændringer i den nuværende løsning at skabe disse nye dokumenter, ligesom det også vil kræve en migreringsaktivitet at skabe dokumenterne på baggrund af de eksisterende data i KIH Databasen. Hvem der bør være repræsenteret i rådet, hvad rådets præcise opgaver skal være, og hvorledes rådet arbejder, er uden for scope i denne rapport. En migrering af den nuværende KIH Databases arkitektur til målarkitekturen vurderes således at kræve en del udviklingsaktiviteter, hvor især teknisk sikring af informationssikkerheden i såvel dokumentdelingssammenhæng og til de proprietære OIOXML snitflader forventes at udgøre den største omkostning. Her kan det nævnes, at den tekniske sikring af dokumentdeling allerede er udviklet i NSI s nationale dokumentdelingsservices på NSP, hvorfor det bør overvejes at bringe denne i anvendelse. Derudover vil der være en række større ændringer i de tilstødende systemer, hvor det også skal afgøres, hvorvidt integrationen skal ske mod dokumentdelingsplatformen eller mod de proprietære snitflader på den centrale KIH opsamlingsplatform. Lakeside ser to mulige scenarier for migrering: Scenarie 1: KIH Databasen splittes op i en opsamlingsdel og en repository del. Scenarie 2: KIH Databasen ændres til at udstille dokumentbaserede data via et IHE- XDS on-demand repository Scenarie 1 Opsamling + Repository I dette scenarie søges den nuværende KIH Database opsplittet i to komponenter, hvor integrationen imellem disse alene sker gennem standardiserede snitflader. Opsplitningen illustreres nedenfor i Figur 4. Borger Opsamlingsservice (OIOXML) OpenTele (fx) Centrale opsamlingspunkter KIH Dataopsamling SQL database PHMR builder d a c Rekvireringsservice (OIOXML) e?" Anvendersystemer Sundhed.dk Labdatabanken Fagsystemer Sundheds professionel IHE-XDR [iti-41] + HL7 PHMR IHE-XDS / XCA [iti-18+43] Centrale sikkerhedsservices (NSP) Sikker login IHE indeks b a KIH Repository c Nationale sikk. løsninger MinLog Platform til dokumentarkivering og -deling Etc. Figur 4 - Migreringsscenarie 1: KIH Databasen splittes i et opsamlingspunkt og repository (ikke on-demand). Se uddybning af områderne a-e nedenfor. a) Opsplitning af KIH Databasen. KIH Databasen deles i en opsamlingsdel (og bør brandes med navnet KIH opsamling eller lignende) og en repository del ( KIH LAKESIDE side 17 / 49

18 repository ). Opsplitningen bør ske på kodeniveau, så komponenterne ligger i separate Open Source projekter. b) Affinity domain(s). Parterne bag KIH Databasen konstituerer/udpeger et råd, hvor de relevante dokumenttyper defineres. KIH repository tilsluttes et passende domæne-indeks. Bemærk: hvis parterne ønsker flere domæner inden for KIH konceptet, vil det kræve etablering af en IHE-XCA infrastruktur. c) Sikkerhedsservices. KIH repository snitflader og de proprietære OIOXML services på KIH opsamlingsplatformen beskyttes passende ved anvendelse af centrale sikkerhedsservices. I den forbindelse bør det overvejes at anvende NSP ens dokumentdelingsservice, der allerede har implementeret anvendelse af disse sikkerhedsservices. Såfremt dette vælges, er det vigtigt, at der ikke findes andre/alternative adgangsveje til KIH repository. Hvis der gør, skal disse alternative adgange yde den samme beskyttelse af data og privatlivshensyn. Bemærk: I forbindelse med disse ændringer er det vigtigt at få fastlagt, hvorledes informationssikkerheden sikres. Herunder hvilke informationer systemerne skal tilvejebringe om brugeren/borgeren, for at KIH komponenterne kan foretage de fornødne kontroller hos de centrale sikkerhedsservices, og hvorledes disse overføres til KIH komponenterne på en standardiseret måde. d) Dokumenter. KIH opsamlingsplatformen udvides, så de af rådet besluttede dokumenttyper skabes og leveres til KIH repository gennem standardsnitfladerne. e) Tilstødende systemer skal ændres, så dokumenter rekvireres på anfordring af en bruger/borger. Den nuværende notifikation til Sundhed.dk om hvilke patienter, der har data i KIH Databasen (P-indeks) bør enten afskaffes (såfremt performance kan sikres gennem indeksopslag) eller ved at anvende den nationale adviseringsservice. Den nuværende videregivelse af data til Labdatabanken skal ændres, så Labdatabanken i stedet rekvirerer data hos KIH repository (se også diskussion om juridiske forhold i afsnit 5.3 vedrørende informationssikkerhed). Alternativt kan parterne bag KIH Databasen beslutte, at de tilstødende systemer (eller nogle af dem) skal anvende de proprietære OIOXML snitflader. En sådan beslutning bør overvejes meget omhyggeligt. I praksis kan den forhindre eller besværliggøre en senere udvidelse af KIH konceptet til at indbefatte flere opsamlingsplatforme, hvilket ikke synes at være i tråd med målarkitekturen i referencearkitekturerne. Dette scenarie 1 udmærker sig ved den høje grad af uafhængighed mellem de to komponenter. KIH repository kan i dette scenarie udskiftes med et andet (standard) repository, som dog skal tilpasses danske forhold med hensyn til teknisk sikring af informationssikkerhed. Den høje grad af uafhængighed mellem disse komponenter samt redundansen af data bevirker, at SLA kan være forskellige på de to komponenter. LAKESIDE side 18 / 49

19 3.3.2 Scenarie 2: On-Demand repository I dette scenarie ændres de nuværende XDS snitflader til at blive XDS on-demand snitflader. I stedet for at lade opsamlingsplatformen stå for dokumentgenerering og upload af statiske dokumenter til et repository, står opsamlingsplatformen alene for indeksering. Samtidig ændres XDS snitfladerne, så dokumenterne skabes på anfordring ( on-demand ) ud fra de på kaldstidspunktet opbevarede data i SQL databasen. Scenariet er illustreret i nedenstående Figur 5. Borger Opsamlingsservice (OIOXML) Centrale opsamlingspunkter Rekvireringsservice (OIOXML) Anvendersystemer OpenTele (fx) KIH Dataopsamling SQL database c?" d Sundhed.dk Labdatabanken Fagsystemer Sundheds professionel KIH databasens logiske komponenter i scenarie 2 KIH On-demand repository komponent b IHE indeks Platform til dokumentarkivering og -deling c Register On demand, [iti-61] a IHE-XDS / XCA [iti-43] IHE-XDS / XCA [iti-18] Centrale sikkerhedsservices (NSP) Sikker login Nationale sikk. løsninger MinLog Etc. Figur 5 - Migreringsscenarie 2: Etablering af "on-demand" repository services og indeksering. Se uddybning af områderne a-d nedenfor. Det skal bemærkes, at on-demand optionen i IHE XDS stadig har status Trial Implementation hos IHE (se [ON-DEMAND1] og [ON-DEMAND2]). Det er derfor vanskelligt at vurdere, i hvor høj grad en sådan løsning vil understøtte og understøttes af markedet i fremtiden. Denne risiko bør indgå i parternes drøftelser og beslutning om migreringsscenarie. a) Etablering af on-demand service. De nuværende IHE-XDS snitflader ændres, så dokumenter fremover indekseres og rekvireres som on-demand dokumenter [iti-61]. b) Affinity domain(s). Parterne bag KIH Databasen konstituerer/udpeger et råd, hvor der de relevante dokumenttyper defineres. KIH opsamlingsplatformen tilsluttes et passende domæne-indeks ved anvendelse af register on-demand snitfladen i IHE-XDS. Bemærk: hvis parterne ønsker flere domæner inden for KIH konceptet, vil det kræve etablering af en IHE-XCA infrastruktur. c) Sikkerhedsservices. udarbejdes som beskrevet i scenarie 1. d) Tilstødende systemer tilpasses som beskrevet i scenarie 1. Dette scenarie 2 udmærker sig ved, at der ikke skabes redundante data. KIH data opbevares alene i SQL databasen, mens metadata sendes til XDS indekset. Scenarie 2 leverer altid de nyeste data, idet dokumenterne først skabes i kaldsøjeblikket. Til gengæld har scenariet ikke de samme afkoblingsegenskaber som scenarie 1. LAKESIDE side 19 / 49

20 3.4 Konklusioner og anbefalinger Konklusioner og anbefaling KIH Arkitektur: Det er Lakesides vurdering, at de forretningsmæssige gevinster ved KIH Databasen i høj grad hænger sammen med en åben arkitektur med ingen eller få bindinger til proprietære snitflader og med høj grad af (international) standardisering. Det er Lakesides konklusion, at arkitekturen i KIH Databasen kan bringes til at leve op til målarkitekturen for telemedicinske dokumentdelingsløsninger. Migreringen vil kræve en del ændringer både i KIH komplekset og hos anvendersystemer. Den største udfordring ligger i at få anvendt centrale sikkerhedsservices og at få tilsluttet KIH komplekset til et formelt affinitetsdomæne, herunder få defineret og etableret de nødvendige dokumenttyper. Lakeside ser to migreringsscenarier. Hvilket migreringsscenarie der er optimalt kræver en nærmere analyse og diskussion blandt parterne bag KIH Databasen. Hvert scenarie har fordele og ulemper og parternes vægtning af disse egenskaber vil være afgørende for udfaldet af analysen. Nogle af de egenskaber eller karakteristika, som vil være i spil i denne analyse vil være: - Ønsker parterne én samlet KIH løsning (én centralt drevet opsamlings- og delingsplatform) eller ønsker parterne muligheden for flere opsamlings- og delingsplatforme? - Ønsker parterne en komponentopdelt løsning, hvor repository-funktionalitet udskilles fra den nuværende løsning, og hvilke komponentegenskaber vægter i den sammenhæng højest (international standardisering af snitflader, mulighed for forskellige SLA er, mulighed for anskaffelse af standardprodukt, mulighed for afkobling etc.)? - Ønsker parterne sig den fleksibilitet, der følger med et on-demand repository (her ligger også diskussionen om dokumentparadigmet er fornuftigt/tilstrækkeligt til at dække parternes behov - se diskussion i afsnit 7.1). Lakeside anbefaler, at der iværksættes en åben drøftelse af migrering af KIH komplekset med udgangspunkt i de skitserede migreringsscenarier. Såfremt parterne sigter efter migreringsscenarie 1, bør parterne samtidig tage stilling til, om migreringen af repository-delen skal ske mod en tilpasset version af KIH Databasen eller om migreringen skal ske mod et standardprodukt / modent Open Source produkt. Denne diskussion berøres i kapitel 7 Samlede konklusioner. Efter beslutning om migreringsscenarie, bør parterne bag KIH Databasen udarbejde en migreringsplan sammen med eksterne anvendere af produktet og iværksætte et migreringsprojekt. Lakeside anbefaler, at migreringen, uanset hvilket migreringsscenarie der vælges, skal indeholde en beslutning om - og omlægning til - passende behovsdækkende dokumenttyper. I begge scenarier vil det være en forudsætning for en bæredygtig informationssikkerhedsløsning, at der etableres nye nationale informationssikkerhedsstandarder og at de nuværende centrale sikkerhedsløsninger tilpasses tilsvarende. Det er Lakesides vurdering, at ikke blot telemedicinsområdet, men mange andre tværgående initiativer har det samme behov, og at det haster med at få iværksat standardiserings- og udviklingsarbejdet. Området er allerede analyseret i Initiativ 3.4 Analyse af sikkerhedsstandarder og løsninger. Lakeside anbefaler, at parterne bag KIH Databasen sætter fokus på informationssikkerhedsområdet med henblik på at få dette arbejde finansieret, planlagt og igangsat. LAKESIDE side 20 / 49

21 Indsatsområder Nice to have Need to have Ark-01: Iværksættelse af modernisering af nationale informationssikkerhedsstandarder og løsninger. Ark-02: Blandt parterne omkring KIH bør der tages en fælles, åben drøftelse omkring migrering af KIH komplekset med udgangspunkt i de skitserede migreringsscenarier. Kort sigt Ark-03: Udarbejdelse af migreringsplan og iværksættelse af migreringsprojekt Ark-04: Tage initiativ til at konstituere/udpege et råd, hvor de relevante dokumenttyper kan fremlægges, defineres og behandles. Længere sigt LAKESIDE side 21 / 49

22 4 Modenhedsanalyse ( Technology Readiness ) Hos NASA og ESA opereres der med et Technology Readiness begreb, hvor der måles på hvor modent og afprøvet komponenterne til rumfartsindustrien er. Nærværende kapitel viser resultatet af en tilsvarende måling på KIH Databasen. 4.1 Vurdering af teknologiparathed / modenhed Inden nye komponenter tages i anvendelse i et domæne, hvor det kan have store konsekvenser, hvis komponenten svigter, er det vigtigt at fastslå, hvor moden komponenten er. Modenheden er et udtryk for, i hvilket omfang komponenten er funktionelt anvendelig for alle typer af brugere og har de nødvendige driftsmæssige egenskaber, så komponenten kan driftsafvikles med de påtænkte servicegarantier, samt om den bagvedliggende teknologi er tilstrækkelig afprøvet i de påtænkte omgivelser. Én måde at måle denne modenhed på, er ved at anvende Technology Readiness Assessment metoden [TRL]. Denne metode udtrykker modenheden af et produkt i et Technology Readiness Level. I nedenstående Figur 6 ses en fremstilling af modenhedstrinene i denne model, der spænder fra at løsningens principper er afdækket (TRL 1) til systemet er i fuldskala og velafprøvet drift (TRL 9). Udvikling af system og støttesystemer Test, ibrugtagelse og drift TRL 8 TRL 9 TRL 7 Research på gennemførlighed Teknologiudvikling TRL 2 Teknologidemonstration TRL 3 TRL 4 TRL 5 TRL 6 Technology Readiness Levels Basal teknologi research TRL 1 KIH databasen marts 2015 Figur 6 - Niveauerne i 'Technology Readiness Level' modellen og Lakesides vurdering af KIH Databasen pr. marts LAKESIDE side 22 / 49

23 I nedenstående tabel er niveauerne nærmere beskrevet og uddybet, og KIH Databasen er holdt op mod modellen. TRL niveau Beskrivelse KIH Databasen TRL 1. Principskitser TRL 2. Teknologi-koncept TRL 3. Eksperimentel POC TRL 4. POC valideret i laboratorie TRL 5. Komponenter validering i relevante omgivelser TRL 6. Functional Featurecomplete Beta. TRL 7. Pilotafprøvet. TRL 8. Release Candidate. TRL 9. Operationel Laveste niveau af teknologiparathed. Videnskabelig forskning begynder at blive oversat til anvendt forskning og udvikling. Eksempler kan omfatte papirundersøgelser af en teknologis grundlæggende egenskaber. Begyndende innovation. Udvikling af applikationer påbegyndes. Resultaterne ses typisk i form af analysestudier og laboratorietests. Aktiv udvikling igangsættes. Dette inkluderer analytiske og praktiske laboratorieforsøg. Brugeroplevelsesprototyper udvikles. Grundlæggende teknologikomponenter udviklet og integreret. Ad hoc integration af hw og sw. Laboratorieafprøvning af delkomponenter Integration med understøttende elementer i et simuleret driftsmiljø. Det simulerede miljø kan afvige en del fra det forventede operationelle miljø. Betatestet. Prototyper af platformen er testet med rigtige brugere i et simuleret driftsmiljø. Omfattende brugertests og vurdering af test. Pilotafprøvning. Prototyper af platformen er testet i et fuldt operationelt driftsmiljø. Omfattende test og vurdering af test. Produktionsklar (Release Candidate). Løsningen er færdigudviklet både funktionelt og non-funktionelt og virker i sin endelige form i præ-produktionsmiljøer. Omfattende test af og uddannelse på løsningen. Løsningen er fuld operationel 24/7 og klar til storskala udbredelse. KIH Databasen betragtes at være funktionelt komplet og opfylder således dette TRL niveau. X KIH Databasen er endnu ikke pilotafprøvet på de standardiserede snitflader til målarkitekturen. Dette vil være en forudsætning for at komme på TRL7. X KIH Databasen har ikke været igennem et IHE connectathon som XDS repository. Lakeside finder dette nødvendigt, førend TRL8 kan opnås. X KIH Databasen er ikke blevet grundigt trykprøvet 6 endnu, hvilket vil være en forudsætning for at opnå dette TRL niveau. 6 Tests i forhold til svartider, robusthed ved udfald af dele af infrastrukturen i flersøjlesetup, skalerbarhedsevner, ressourceudnyttelse ved langvarig høj belastning (endurancetests), egenskaber ved kortvarige og langvarige overbelastninger etc. LAKESIDE side 23 / 49

24 4.2 Konklusioner og anbefalinger Konklusioner og anbefaling Technology Readiness: Det er Lakesides vurdering, at KIH Databasen befinder sig på TRL 6, det vil sige Functional Featurecomplete BETA. Lakeside vurderer, at KIH Databasen succesfuldt skal have gennemgået tre væsentlige tests, før den kan betragtes som et modent produkt, der er klar til udrulning på nationalt plan: a) Pilotdrift med eksterne parter baseret på de standardiserede IHE XDS snitflader. Dette vil bringe KIH Databasen til TRL 7. b) Succesfuld gennemførelse af IHE connectathon som IHE XDS repository. Dette vil (sammen med a) bringe KIH Databasen til TRL 8. c) Succesfuld gennemførelse af grundige og strukturerede performancetests. Dette vil sammen med a+b bringe KIH Databasen til TRL 9. Lakeside vurderer, at det vil være relativt omkostningstungt at bringe KIH Databasen til TRL 9, og parterne bag KIH Databasen bør derfor få afdækket, om det vil være mere fordelagtigt (både tidsmæssigt og økonomisk) at anskaffe et standardprodukt, der allerede har været igennem disse tests. Lakeside anbefaler, at KIH Databasen bringes til TRL 9 inden komponenten tages i brug som national komponent i relation til Klinisk Integreret Hjemmemonitorering. Dette vil som minimum involvere ovennævnte 3 tests. Indsatsområder Need to have Nice to have TRL-01: Planlægning og gennemførelse af pilotdrift i samarbejde med minimum én ekstern part ved anvendelse af de standardiserede snitflader Kort sigt TRL-02: Planlægning og gennemførelse af grundige og strukturerede performancetests TRL-03: Gennemførelse af IHE connectathon som IHE XDS repository. Længere sigt LAKESIDE side 24 / 49

25 5 Kvalitetsanalyse ( SQuaRE ) Hvis parterne bag KIH Databasen ønsker færrest mulige overraskelser i form af nedbrud, lange svartider, it-sikkerhedsbrud eller overraskende dyre tilpasninger, er det vigtigt at produktet er af høj kvalitet. Der er mange aspekter af kvalitet, og disse berøres i dette kapitel. Dette kapitel analyserer KIH Databasen ud fra en række perspektiver fra ISO/IEC standarden Software product Quality Requirements and Evaluation (SQuaRE). SQuaRE metoden definerer 8 analyseperspektiver, der tilsammen afdækker kvaliteten af et softwareprodukt. Hvert af de 8 perspektiver er yderligere nedbrudt i en række analyseelementer. Det har været nødvendigt at tilpasse SQuaRE modellen, så modellen passer til analysen af et infrastrukturprodukt uden slutbrugervendt brugergrænseflade. Derfor analyseres kun følgende perspektiver: 1. Performance / Effektivitet 2. Pålidelighed 3. It-sikkerhed 4. Vedligeholdelsesegenskaber 5. Portabilitet De resterende perspektiver (funktionelt passende, brugervenlighed og kompatibilitet) er delvis dækket af arkitekturanalysen eller er udeladt af analysen. I nedenstående tabel ses de enkelte dele af standarden, og i hvilket omfang standardarden er anvendt i analysen. Functional Suitability Performance efficiency Comp5 atibility Usability Reliability Security Maintainability Portability Functional*completeness Functional*correctness Functional*appropriateness Dækket*i* arkitektur* afsnittet Time*behaviour Resource*utilisation Capacity Co7existence Interoperability Appropriateness*recognizability Learnability Operability User*error*protection User*interface*aesthetics Accessibility Maturity Availability Fault*tolerance Dækket*i* x x x arkitektur* x x x x x x x x x x x x x x x x afsnittet Recoverability Confidentiality Integrity Non7repudiation Accountability Authenticity Modularity Reusability Analysability Modifiability Testability Adaptability Installability Replaceability Tabel 3: Angivelse af anvendte og fravalgte dele af SQuaRE-modellen til KIHanalysen. 5.1 Performance / Effektivitet Teknologivalg i relation til performance og skalering Lakeside finder de teknologiske valg i KIH Databasen fornuftige i forhold til den forventede anvendelse og belastning til Klinisk Hjemmemonitorering på nationalt plan (i Danmark). Alle komponenter burde til en hvis grad kunne levere den fornødne performance og skalering. Skalering burde ud fra et designmæssigt synspunkt kunne ske horisontalt med nær lineært potentiale (dobbelt kapacitet ved fordobling af antallet af servere), især hvis det drejer sig om beregninger/parsning. Det er Lakesides forventning, at den største/første flaskehals vil blive SQL databasen, men selv her vil der være et godt skaleringspotentiale, idet den nuværende anvendelse af KIH Databasen ikke Lakeside bekendt fordrer lange og vidtstrakte SQL transaktioner. LAKESIDE side 25 / 49

26 I forhold til opbevaring af (større) XMLbaserede eller binære dokumenter, vil en SQL database ikke tilføre systemet særlige fordele. I nogle tilfælde tværtimod. Hvis der senere viser sig større flaskehalse i form af I/O eller transaktionsproblemer, bør det overvejes at ændre datalageret til noget mere passende. Denne type omlægninger kan være bekostelige og/eller risikable, da der ændres på nogle helt grundlæggende elementer i systemet Ressourceforbrug og udnyttelse Lakeside har ikke kunnet finde dokumentation for, at der er gennemført formel performancetest for KIH Databasen. Dette er bekræftet af leverandøren. Der er således ingen målinger, der viser, hvorledes KIH Databasen vil reagere ved langvarig belastning eller overbelastning, ligesom der heller ingen målinger er for middelsvartider eller svartidsfordeling. Lakeside kan således ikke udtale sig om ressourceforbrug eller ressourceudnyttelse i KIH Databasen Konklusioner og anbefalinger Konklusioner og anbefaling Performance: Design- og teknologivalg i KIH Databasen er fornuftige, men da der ikke er gennemført en grundig performancetest, er det uklart om den fornødne performance rent faktisk er til stede i det udviklede produkt. Der kan således være uhensigtsmæssigheder i programmeringen i produktet, der gør at produktet ikke har de performanceegenskaber der ønskes ved langvarig belastning eller ved overbelastning. Lakeside har allerede tidligere i rapporten anbefalet, at der udarbejdes og gennemføres en grundig og struktureret performancetest. 5.2 Vurdering af pålidelighed Tilgængelighed Det nuværende driftssetup af KIH Databasen byder kun på en mindre garanti for høj tilgængelighed. Det har været fuldt tilstrækkeligt til de projekter, der har anvendt KIH Databasen hidtil, men vil ikke være tilstrækkeligt til en videre udbredelse af databasen. Ønsker parterne bag KIH Databasen sig meget høj tilgængelighed og robusthed, bør der etableres flere instanser af KIH Databasen. F.eks. én i hver region eller lignende. IHE XDS gør det muligt, at have flere instanser af KIH Databasen som overfor brugeren vil fremstå som én og samme løsning Fejltolerance og rehabiliteringsevne Der er ifølge leverandøren ikke gennemført test af robusthed og rehabiliteringsevne. Lakeside har derfor intet grundlag for at udtale sig om produktets egenskaber i denne retning. LAKESIDE side 26 / 49

27 5.2.3 Konklusioner og anbefalinger Konklusioner og anbefaling pålidelighed: En national udbredelse af KIH Databasen vil efter Lakesides vurdering kræve ændringer i driften af KIH Databasen, for at opnå en fornuftig balance mellem performance, pålidelighed og robusthed. Hvis alle instanser indekserer i samme indeks vil alle dokumenter kunne findes gennem opslag i dette indeks (IHE-XDS). Hvis der etableres flere indekser (affinitetsdomæner) vil det kræve en IHE-XCA infrastruktur. 5.3 Vurdering af informationssikkerhed KIH Databasen er et it-system, der potentielt kan indeholde endog meget følsomme helbredsinformationer. Derfor er det vigtigt, at intentionerne i de danske love og bekendtgørelser efterkommes både i de omgivende processer og i de tekniske løsninger. I forhold til KIH Databasen som datadelings-komponent er det især 42a i sundhedsloven vedrørende indhentning af helbredsinformationer, der regulerer hvad der skal kontrolleres i løsningerne. De bærende elementer i denne lov er især sundhedsfaglig autorisation, virksomhedsledelsens ret til tilrettelæggelse af arbejdsfunktioner (roller/rettigheder der følger med ansættelsesforholdet), samtykke, frabedelse af indsigt, aktuel behandlingsrelation, delegering af rettigheder samt værdispring. Alle disse it-sikkerhedselementer bør, foruden den sædvanlige sikring af fornøden autentifikation, være håndteret i en moden national infrastrukturkomponent. Der henvises til [REFARK_SIK] for yderligere informationer. I nedenstående figurer (Figur 7 og Figur 8), illustreres nogle af de relativt komplekse sammenhænge i Sundhedslovens 42a mv. (kilde [REFARK_SIK]). Start Er du passende identificeret og autenticitetssikret? Ja Er du autoriseret jf. 42a stk. 1-4? Ja Nej Nej STOP Er du sekretær og yder teknisk bistand eller er du medicinstuderende, der indhenter oplysninger under en læges eller sygehusansat tandlæges ansvar? (SL 42a stk. 8+9) Delegering Nej Er du en medarbejder, der under ansvar af en læge eller sygehusansæt tandlæge, som har fået et udtrykkeligt samtykke af patienten, indhenter informationer, der er nødvendige ift. aktuel behandling? (SL 42a stk. 10) Nej STOP Ja Ja Ja Har patienten givet udtrykkeligt samtykke til at du må se de rekvirerede data? (Persondataloven 6, SL 42a stk. 6) Nej Er du/den du arbejder på vegne af, autoriseret af ledelsen til at måtte foretage indhentningen? (persondataloven, ledelsesret) Nej Ja Er patienten i aktuel behandling hos dig/den du arbejder på vegne af, og er det nødvendigt for dig at få data? Nej Ja Frabedelse af indsigt Har patienten afgivet udtrykkeligt negativt samtykke mod dig/den du arbejder på vegne af? (SL 42a stk. 7) Ja Nej Har patienten frabedt sig at de rekvirerede data kan indhentes? (SL 42a stk. 7) Nej Ja Har patienten givet samtykke til at den afdeling, du/den du arbejder på vegne af, arbejder på må få indsigt i de rekvirerede data ( 42a stk. 6) Ja Nej Ønsker du at gøre brug af værdispringsreglen? ( 42a stk. 5) Ja Nej STOP Du kan indhente informationerne såfremt sikkerhedspolitikkerne hos den dataansvarlige myndighed tillader det. Den dataansvarlige kan opstille skærpede krav til autorisation eller arbejdsfunktion. Figur 7 - "Beslutningstræ" for Sundhedslovens 42a (mfl.) LAKESIDE side 27 / 49

28 Ledelse Ledelsens tilrettelæggelse af arbejdsfunktioner (her tildeling af brugeradministrator-privilegier) Administrativ medarbejder (brugeradministrator) Delegeret Ledelsesmyndighed (tildeling af arbejdsfunktioner) Sundhedsfaglig medarbejder Delegering iht. 42a stk Medarbejder (sekretær) Delegering iht. 42a stk. 8+9 Patient Værge / forældre Anden borger Behandlingsrelation Samtykke Fuldmagt Anden borger Figur 8 - Relationer mellem forskellige 'aktører' i relation til informationssikkerhed. KIH Databasen har efter Lakesides opfattelse flere mangler på itsikkerhedsområdet. Pt. er der en række system-trust elementer indbygget i adgangen til KIH Databasen. Det betyder, at det er det kaldende systems ansvar at sikre, at brugeren er passende autentificeret, autoriseret, samtykkekontrolleret etc. Lakeside er af den opfattelse, at dette er en mindre hensigtsmæssig håndtering af it-sikkerheden, især hvis der kan være mange adgangsveje til data. F.eks. flere forskellige anvendersystemer. For sådanne infrastrukturkomponenter bør It-sikkerheden håndteres tæt på data, så den samlede datasikkerhed er ensartet høj uanset hvilken adgangsvej til data, der er anvendt. KIH Databasen bør derfor efter Lakesides vurdering udvides til at sikre/kontrollere alle ovennævnte sikkerhedsaspekter ved adgang til KIH Databasen. Lakeside anbefaler, at der skabes integrationer til NSIs nationale sikkerhedskomponenter (behandlingsrelationskomponenten, samtykkekomponenten, MinLog komponenten mv.). Inden disse udviklingsaktiviteter iværksættes anbefales det at udarbejde en sikkerhedsanalyse og politik for KIH Databasen. Denne skal analysere og fastlægge de nødvendige sikkerhedsegenskaber, der skal være opfyldt for at kunne få adgang til KIH Databasen, herunder autentifikationsstyrke (LoA), hvilke attributter, der skal stilles til rådighed for KIH Databasen samt hvilke kilder KIH Databasen finder autoritative for disse attributter. Som nævnt i kapitel 3 anbefaler Lakeside, at de nuværende nationale standarder til kommunikation af disse attributter snarest muligt moderniseres, så det sikres, at disse standarder kan sameksistere med de internationale dokumentdelingsstandarder. LAKESIDE side 28 / 49

29 5.3.1 Konklusioner og anbefalinger Konklusioner og anbefaling informationssikkerhed: Lakeside vurderer, at informationssikkerhedsløsningen i den nuværende KIH Database løsning ikke er tilstrækkelig til at opfylde intentionerne i den danske lovgivning. Lakeside anbefaler, at der udarbejdes en sikkerheds- og privatlivsimplikationsanalyse (Kval-01), hvorfra der objektivt kan stilles krav til blandt andet autentifikationsstyrke, eventuel kryptering af datalag, sikring af integritet af datalag og installerede komponenter, logningsbehov etc. På baggrund af kravene og de øvrige input fra [RE- FARK_SIK] anbefaler Lakeside, at der iværksættes aktiviteter til fornøden itunderstøttelse i løsningen (Kval-02). Lakeside anbefaler, at der skabes integrationer til NSIs nationale sikkerhedskomponenter (behandlingsrelationskomponenten, samtykkekomponenten, MinLog komponenten mv.) til sikring og ensretning af informationssikkerheden, eller at NSI s dokumentdelingsservice bringes i anvendelse (Kval-03). Endelig anbefaler Lakeside, som nævnt tidligere i rapporten, at der snarest initieres nationalt standardiseringsarbejde, der tilvejebringer de nødvendige moderniseringer i sikkerhedsstandarder og løsninger. Disse skal på lidt længere sigt indarbejdes i KIH Databasen (Kval-04). 5.4 Vurdering af vedligeholdelsesmuligheder I forhold til en vurdering af den fremtidig vedligehold og videreudvikling af KIH Databasen har Lakeside gennemgået kildekoden og den samlede dokumentation for løsningen. Kildekoden fremstår modulært opbygget, generelt letlæselig og velstruktureret. Mange centrale dele er kort men præcist dokumenteret. Lakesides eneste kritikpunkt er, at elementer af test-kode har sneget sig ind under produktions-koden. Generelt ligger KIH Databasens dokumentationsartefakter på et forholdsvis højt niveau og de overordnede beskrivelser er gode til hurtigt at give et godt overblik over hele løsningen. På centrale områder er dokumentationen dog helt fraværende. Der mangler: En kravspecifikation som løsningen kan holdes op imod En snitfladebeskrivelse for KIH Databasens eksterne PHMR snitflade Hele testområdet er ikke dokumenteret og det er dermed uklart, hvad der er blevet testet og hvordan. I nedenstående tabel er de enkelte dokumentationsartefakter nærmere vurderet. Dokumentationstype Beskrivelse KIH Databasen Overblik Dokumentationsoverblik Overblik over kildekode Forankring af dokumentation Krav Danner indgang til al relevant dokumentation. Beskriver den overordnede kodestruktur. Beskriver hvor dokumentation kan findes samt versionering af denne. OK OK OK LAKESIDE side 29 / 49

30 Kravspecifikation Arkitektur og design Arkitekturbeskrivelse Fastholder både funktionelle og non-funktionelle krav til løsningen, og bør løbende opdateres. Giver et overordnet billede af løsningens arkitektur. X Mangler Kravspecifikationen er generelt et godt sted at konsultere, hvis der er tvivl om løsningens formål. Denne bør udvikles og vedligeholdes. OK Arkitekturvalg Datamodel Snitfladebeskrivelser Begrunder de valg og fravalg der blev truffet under opbygning af løsningens arkitektur, herunder sikkerhedsmodel og evt. sikkerhedsanalyse. Beskriver såvel den logiske som den fysiske datamodel. Indeholder en detaljeret beskrivelse af de eksterne snitflader. ( ) Findes til dels i Arkitekturbeskrivelsen, men bør uddybes. F.eks. mangler en begrundelse for valget af datamodel og (SOAP) profiler for snitfladerne. OK ( ) Mangler til dels. Beskrivelsen af den eksterne OIOXML snitflade er forankret hos MedCom, men en henvisning til denne fra KIH Databasens dokumentationsartefakter mangler. Tredjeparts komponenter En beskrivelse af de anvendte tredjepartskomponenter inklusiv licens- Der mangler en snitfladebeskrivelse for den eskterne PHMR snitflade. Specielt bør valg af den anvendte (SOAP) profile tydeliggøres det er uklart hvordan f.eks. den soap-1.1-baserede DGWS spiller sammen med IHE s soap-1.2- baserede profiler. X LAKESIDE side 30 / 49

31 Systemdokumentation Forretningsregler Bygge- og installationsvejledning Driftsvejledning Kendte fejl og mangler Brugerdokumentation Brugergrænsefladedokumentation Udviklerdokumentation Guide til videreudvikling Web-designguidelines Kildekodedokumentation Test og performance Teststrategi Testplan model, samt en redegørelse for valg af komponenterne. En detaljeret beskrivelse af de implementerede forretningsregler. Beskriver hvordan løsningen bygges ud fra kildekoden og hvordan løsningen kan deployes i en driftsopsætning. Indeholder vejledninger for monitorering og backup/restore af løsningen. Fastholder kendte udeståender for løsningen. Brugervendt dokumentation af web-grænsefladen. Beskriver kode-struktur, opsætning af udviklingsmiljø mm. Fastholder hvordan et samlet grafisk udtryk er realiseret. Hvordan selve kildekoden er dokumenteret. Beskriver en overordnet strategi over hvad der testes. En realisering af teststrategien som består af en Mangler Anvendte frameworks er nævnt, men en egentlig begrundelse for valg af framework (og andre biblioteker) mangler. Licens-model er ikke angivet. X Mangler OK OK ( ) Udeståender er markeret som sådan direkte i kildekoden og kunne med fordel samles centralt, eksempelvis i løsningens issue-tracking system (som pt. er tom) OK OK Ej relevant OK X Mangler X LAKESIDE side 31 / 49

32 Testopsætning Testrapport overordnet plan over hvordan testen skal gennemføres. En detaljeret beskrivelse af opsætning af testmiljøet hvor testen gennemføres. Fastholder resultaterne af afviklingen af testen. Mangler X Mangler X Mangler Konklusioner og anbefaling vedligeholdelsesegenskaber: Lakeside vurderer, at der er fornuftige muligheder for at vedligeholde den nuværende KIH Database løsning. Den dokumentation, der er leveret til komponenten, er i fornuftig stand, koden er velstruktureret og passende modulopdelt. Der er dog nogle væsentlige mangler i dokumentationen, som bør udbedres, ligesom testkode skal fjernes fra produktionskoden. Lakeside anbefaler, at de manglende og ukomplette dokumentationselementer udbedres i følgende prioritering: Prioritet 1 PHMR snitfladebeskrivelse, forretningsregler og fejlsituationer (Kval-05) Prioritet 2 Alle testbeskrivelser, planer, rapporter mv. (Kval-06) Prioritet 3 Øvrige mangler, dvs. dokumentation af tredjepartskomponenter, forbedret beskrivelse af arkitekturvalg samt kravspecifikation (Kval-07) 5.5 Vurdering af portabilitet Kode- og dokumentationsinspektion viser, at KIH Databasen har gode egenskaber for portabilitet. Portering til en anden applikations-platform vurderes at kunne ske uden større ændringer, så længe porteringen sker inden for samme teknologiregime (Java EE, standard webcontainer). Der er ikke fundet anvendelse af proprietære API er eller lignende i løsningen. Portering til et andet operativsystem vurderes også kunne ske uden større ændringer, idet løsningen er baseret på Java, der netop har denne egenskab. Portering til en anden SQL database vurderes ligeledes at kunne ske uden større udfordringer, idet der anvendes standard SQL i løsningen. Tilpasningsmæssigt har løsningen gode egenskaber så længe de standardiserede IHE-XDS snitflader anvendes. KIH Databasen vurderes at kunne modtage en meget stor diversitet af dokumenter og ikke kun de, der modtages i dag (PHMR enkeltmålinger). LAKESIDE side 32 / 49

33 Konklusioner og anbefaling portabilitet. På baggrund af en inspektion af programkode, dokumentation og gennem interviews af leverandøren og Open Source operatøren, vurderer Lakeside, at løsningen efter alt at dømme har gode portabilitets- og tilpasningsegenskaber. Ønskes der større sikkerhed for dette, bør der gennemføres egentlige tests, hvor løsningen f.eks. porteres til et andet operativsystem (f.eks. Linux) med et andet databaseprodukt. 5.6 Kritikalitet af anbefalinger vedrørende kvalitet Indsatsområder Need to have Nice to have Kval-01: Udarbejdelse af sikkerhedsanalyser. Kval-02: Implementering af nødvendige tekniske sikringsforanstaltninger Kval-03: Anvendelse af NSI s sikkerhedskomponenter. Kval-05: Udarbejdelse af snitfladedokumentation, beskrivelser af fejlsituationer og forretningsregler Kort sigt Kval-04: Indarbejdelse af moderniserede sikkerhedsstandarder og -løsninger Kval-06: Udarbejdelse af testdokumentation Kval-07: Udarbejdelse af manglende dokumentation Længere sigt LAKESIDE side 33 / 49

34 6 KIH Databasen i et Open Source Økosystem Anvendelsen af Open Source-modeller til at understøtte etableringen og den løbende udvikling af produkter finder stadig større udbredelse. At gøre KIH Databasen tilgængelig som en del af et open source økosystem er helt i tråd med et overordnet ønske om at stimulere innovation og åbne markedet for telemedicinske løsninger. Rammen omkring KIH Databasen til at facilitere denne dannelse af et økosystem er på plads og tilstrækkelig i sin nuværende form, men aktivitetsniveauet og antallet af aktive bidragsydere er tæt på at være under kritisk masse. Med open source-modeller kan muligheden for at få indflydelse på den fremtidige udvikling i forhold til typiske kommercielle hyldevareprodukter øges. Samtidig kan der hvis Open Source produktet er veldrevet og aktivt opnås de samme kvalitetsegenskaber og samme service- og supportegenskaber som med kommercielle produkter; i nogle tilfælde endog bedre. Endvidere er selve organiseringen omkring open source attraktiv, hvis man søger uafhængighed i forhold til leverandører, og hvis det er i ens interesse at styrke etableringen af et projektfællesskab - et community - omkring produktet. Derfor er begrebet Open Source Software Ecosystems blevet introduceret, som et holistisk og overvejende forretningsorienteret perspektiv: A software ecosystem is a set of actors functioning as a unit and interacting with a shared market for software and services. A software ecosystem consists of actors such as independent software vendors (ISV), outsourcers, and customers. A software ecosystem typically is interconnected with institutions such as standardization organizations, open source software communities, research communities, and related ecosystems [Jansen, 2013]. Dette økosystem af kode, værktøjer og governance-rammer har til formål at fungere som garanti og sikring af en neutral platform for innovation og samarbejde samt bidrage til at åbne markedet og sænke indgangsbarriererne for øvrige aktører både indenfor og udenfor økosystemet. I den følgende Open Source vurdering har Lakeside taget afsæt i evalueringsframeworket QuESo 7, der baserer sig på QualOSS 8. Begge tager afsæt i ISO/IEC Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) - der er anvendt i denne rapports arkitektur- og teknologivurdering. QuESo fokuserer på 3 overordnede perspektiver og en række underliggende analyseelementer. Det første perspektiv - Platform Quality - er udeladt her, da dette er dækket af den generelle arkitektur og teknologivurdering af KIH Databasen. 7 [QuESo] 8 [QualOSS] LAKESIDE side 34 / 49

35 Platform) Quality Community) Quality Ecosystem) network)quality Aktører Anvendersystemer x x x x Dækket,af, Drift,/,Administration x x ISO/IEC, Udvikling,/,Vedligehold x x x x 25010:2011 Open,Source,Operatør x x x x Maintenance,Capacity Process,Maturity Ressource,Health Tabel 4 - Perspektiver i QuESo analyserammen. Network,Health 6.1 KIH Databasens fit til et Open Source Økosystem Ovenstående vurderingsramme bliver i det følgende anvendt i forhold til KIH Databasen. Dvs. til at vurdere hvordan KIH Databasen - organiseret som et open sourceprojekt - står rustet, hvis det fremadrettet skal kunne fungere som en integreret del af et egentligt open source økosystem. De primære kilder i forhold til at vurdere KIH Databasens fit ind i et Open Source Økosystem har været: Interviews med projektets parter og aktører (Heriblandt 4S) Tilgængelig KIH-dokumentation på 4S Wiki KIH Jira til issuetracking Kode-repository (git) på Bitbucket.org Overordnet vurdering KIH-projektets afsæt som innovationsprojekt har et sigte mod at stimulere en bred adoption af platformen ved at bruge open source som et centralt element. Vinklen på open source er ikke eksplicit fremtrædende i den overleverede projektdokumentation. Dog nævnes det allerede i ansøgningen til initiativet Klinisk Integreret Hjemmemonitorering, at projektet har 2 (sekundære) formål i at adressere og sænke barriererne for national udbredelse af resultaterne. Dermed bliver open sourcevinklen på KIH Databasen af strategisk karakter og via interviews er dette eksplicitte ønske blevet gentaget af flere aktører. Nemlig at man med dette projekt og organisering omkring det som open source, håber at kunne bidrage til at åbne et marked og sænke indgangsbarriererne for andre potentielle aktører og anvendere af hele OpenTele-platformen. Lakeside kan via research konstatere, at der er igangsat og allerede foretaget en række vigtige og grundlæggende aktiviteter for at definere projektet som et open source-projekt: Der er valgt en open source licensmodel (Apache 2.0) Den udarbejdede dokumentation er gjort tilgængelig (dog pt. overvejende på dansk) Den udarbejde kildekode er gjort tilgængelig Der er blevet udpeget en koordinator/operatør, der skal sikre kvalitet og retning på open source-projektet Lakeside er opmærksom på, at en del af disse aktiviteter er work-in-progress og koordineres under rammerne af 4S - Stiftelsen for Softwarebaserede Sundhedssystemer. Således har 4S de seneste år forvaltet rollen som koordinator for OpenTele og senest også KIH Databasen. Som nævnt i afsnit 2.3 Afgrænsninger er opgaven her ikke at vurdere denne indsats, men at vurdere i hvilken grad og omfang aktiviteterne bidrager til, at der på sigt kan skabes et bæredygtigt økosystem baseret på open source omkring KIH LAKESIDE side 35 / 49

36 Databasen. Vurderingen skal tages med et vist forbehold, idet den baserer sig på et ret beskedent aktivitetsniveau (under 4S rammen) i en kort tidsperiode. Lakeside vurderer dog, at datagrundlaget er tilstrækkeligt til at give et indtryk af potentialet i KIH Databasen som open source-komponent Konklusioner og anbefalinger Konklusioner og anbefaling Overordnet Open Source: Lakeside anbefaler, at parterne bag KIH Databasen mere eksplicit formulerer ambitioner, ønsker og krav til KIH Databasen på et mere overordnet og strategisk niveau i forhold til en aktiv rolle som Open Source komponent. Denne formulering kunne have karakter af et overordnet roadmap for visionen omkring OpenTele og KIH Databasen. En vision der kunne være med til at skærpe den nationale vinkel og lokale behov i forhold til de internationale perspektiver. (OSS-01) Lakeside anbefaler, at den planlagte konsolidering af dokumentation og kildekode fra digitaliser.dk i én autoritativ kilde (Bitbucket) fortsætter og indenfor kort tid afsluttes. Dette vil styrke overblikket, mindske forvirringen om projektets status samt øge synligheden af den koordinerende funktion (4S). Endvidere vil det støtte initiativets internationale profil, der allerede i dag bliver betonet på 4s-online.dk. (OSS-02) I forlængelse af ovenstående anbefales det at håndhæve en mere éntydig sprogpolitik i både issue-tracking (Jira) og kode-repositoriet (Bitbucket) - helst på engelsk for at øge rekrutteringsgrundlaget for projektet. (OSS-03) Vurdering af Community Quality Der er ofte en tæt sammenhæng mellem kvaliteten af et (Open Source)-produkt og det bagvedliggende udviklingsfællesskab (Community). Derfor omfatter QualOSSevalueringsmodellen i perspektivet Community Quality en række karakteristika, der kan anvendes i afdækningen og belysningen af de indre kvaliteter og den generelle bæredygtighed for et udviklingsfællesskab / community. Maintenance capacity: Dette analyseelement handler om evnen til at fællesskabet omkring projektet kan tilvejebringe eller råde over tilstrækkelige ressourcer til aktivt at vedligeholde projektet. F.eks. foretage ændringer, rette fejl, levere support og udvikler-bistand over en tidsperiode. KIH Databasen har i sin nuværende form og udgave en ret snæver kreds af anvendere, et smalt udbud af understøttede use cases, ligesom de nuværende bidragsyder i open source-projektet også er fra den primære aktørkreds omkring OpenTeleprojektet. Det er Lakesides indtryk ud fra review af dokumentationen (Wiki - og historisk: digitaliser.dk), af aktiviteterne på BitBucket (kildekode) og på projektets Jira (Issue/bugtracking), at der er et lille, men aktivt kollektiv af forfattere og udviklere på ca. 5 personer. Det er Lakesides vurdering, at på trods af et meget lille antal udviklere og bidragsydere, så er de centrale elementer for at kunne understøtte og udvide antallet af bidragsydere til stede. Den basale dokumentation er samlet og tilgængelig, kommentarer til commits, bugs og rettelser foregår altovervejende på engelsk og demonstrerer både evne og vilje til samarbejde og udveksling af relevant viden og informationer. Netop på grund af den lille skare af bidragsydere, er der ikke et stort behov for formulering af en mere klar rollefordeling (core-developer, reviewer, etc.). Dette behov vil blive mere presserende i fald projektet tiltrækker flere bidragsydere og partnere. Med valget af BitBucket (Git) og Jira som centrale samarbejdsværktøjer er rammerne dog tilvejebragt for både at kunne facilitere langt flere parter og også håndtere de forskellige roller og opgaver parterne påtager sig i projektet. LAKESIDE side 36 / 49

37 Aktivitetsniveau: Den korte historik for bidrag til kildekoden (commits i BitBucket siden ) samt håndtering af bugs og ændringsforslag (Jira entries) giver ikke et tilstrækkeligt solidt grundlag til at vurdere projektets egentlige aktivitetsniveau. Der er således ingen entries i KIH Databasens Jira illustreret i nedenstående Figur 9 og kildekoden er først for nylig flyttet og konsolideret på BitBucket. Figur 9 - Udviklingen af issues i KIH projektet siden etablering af issue tracking hos 4S. Antallet af løste issues giver normalt et godt billede af aktivitetsniveauet og reaktionshastigheden på et projekt og sender et vigtigt og kraftigt signal, der er centralt i forhold til rekruttering af parter til projektet. Derfor er det fremadrettet vigtigt at issue tracking systemet kommer i anvendelse, og at selv mindre issues registreres og meldes løst. Figur 10: Screenshot fra Bitbucket over antal commits samt branches af KIH kildekoden. Sustainability: Dette analyseelement dækker sandsynligheden for og realismen i, at et Open Source fællesskab over en længere periode er i stand til at vedligeholde og opretholde momentum i udviklingen af projektet/produkterne. F.eks. tiltrække og rekruttere nye partnere, udviklere og anvendere og skabe en balance mellem ekspertise-områder så der ikke opstår for store afhængigheder af enkeltpersoner eller partnere. Aktiviteterne omkring Opentele-platformen og selve KIH Databasen varetages af parterne bag 4S-samarbejdet. Dette sikrer på kort sigt rammerne for udvikling, LAKESIDE side 37 / 49

38 modning og en forankring af KIH-projektet blandt parterne omkring 4S. Det bidrager også til at styrke den klyngedannelse eller sammenhængskraft, der er vigtig for kvaliteten i et økosystem. På længere sigt bør man overveje, hvordan man sikrer sig mod bortfald (udløb) af sådanne ressourcer, og hvordan man bedst spreder aktiviteter og roller blandt sine sponsorer, så kontinuitet og bæredygtighed bliver sikret. Organiseringen og placeringen af projektet omkring 4S-samarbejdet er et første og vigtigt skridt i dette. Den meget korte periode, hvor kildekode og dokumentation har været tilgængelig via Bitbucket samt den historiske aktivitet på softwarebørsen (digitaliser.dk), giver et billede af et meget begrænset aktivitetsniveau. Dog har opbygningen af hjemmesiden, der er vært for projektet ( konsolideret og løftet en stor del af dokumentationen til et konsistent niveau. Projektet har oprettet en række rollebaserede kontaktpunkter (f.eks. [email protected] og [email protected]). Dette bidrager dels som en potentiel sikring mod store personafhængigheder ligesom det kommunikerer projektets rollefordeling. Process Maturity: Dette analyseelement dækker en vurdering af evnen og beredskabet som økosystemet råder over til på konsistent vis at nå udviklingsrelaterede mål ved at følge etablerede og beskrevne processer. F.eks. omkring kvalitet eller funktionalitet. Ydermere dækker dette analyseelement, om der er processer, der garanterer eller sikrer at bestemte karakteristika eller egenskaber udvikles og tilføres produktet. Det kan være i form af produkt-roadmaps, release-planlægning og håndteringen af løbende ændringer. Overordnet set er KIH Databasen kommet ind i en ramme, der har beskrevne processer og strategier for både branching af kildekoden og for håndtering af fejl og uhensigtsmæssigheder. Branching-strategien følger tæt den generelle strategi som Bitbucket har for dette og issue-håndteringen følger standard-forløbet i Jira-værktøjet. Begge dele er fremhævet og dokumenteret på den udviklervendte del af projektet ( LAKESIDE side 38 / 49

39 Figur 11: Branching strategi for 4S repositories - herunder KIH Databasen Figur 12: Proces og trin i registrering, udredning og lukning af issues/bugs i Jira Overordnet set savnes der en udbygning af dokumentationen for planlægningen af fremtidige releases (roadmap for projektet) og en proces for håndteringen af dette. Det nuværende roadmap for softwaren i 4S tegner et overordnet billede af de indsatsområder, som der er en forventning om skal adresseres i fremtiden. Den indeholder dog ingen prioritering efter hverken vigtighed eller tid, som et roadmap normalt ville gøre. Roadmappet tegner dog et godt billede af det landskab af projekter og interessenter, som KIH-projektet (og OpenTele) bevæger sig i. LAKESIDE side 39 / 49

40 Rammerne til at foreslå og diskutere features findes i form af workgroups som f.eks. PHMR Builder-komponenten benytter sig af. Rammerne og elementerne til at understøtte dette element i økosystemet er således til stede, men finder ikke anvendelse i fuldt omfang. Der er ikke formuleret en eksplicit strategi for test eller gennemførelse af tests i projektet. Dette anser Lakeside som kritisk for modenheden i Open Source økosystemet. Kildekoden indeholder klasser til både unit-, integrations- og funktionstest samt test-data. Dette er også beskrevet og dokumenteret i guiden til videreudvikling. Interviews har afdækket opmærksomheden på test-behovet og forståelse for nødvendigheden og kompleksiteten af denne opgave. Opgaven er dog ikke nødvendigvis så fremtrædende for KIH Databasen (backend), som for frontend-delen (OpenTele-klienten). Konklusioner og anbefaling Open Source Community Quality: Lakeside anbefaler, at den tilgængelige dokumentation (system-, arkitektur- og udviklerguide) udarbejdes på engelsk, så den støtter op om den øvrige sproglinje. Dette skal støtte og øge synligheden og tilgængeligheden af projektet. (OSS-04) Det anbefales, at der gøres en indsats for generelt at øge aktivitetsniveauet på projektet ved at tiltrække og inddrage flere bidragsydere. Projektet er tæt på for nuværende ikke at have kritisk masse som open source projekt. (OSS-05) Det anbefales endvidere at tage initiativ til at aktørerne omkring KIH Databasen udarbejder et release-roadmap samt formulerer en understøttende proces til at samle og kvalificere forslag til fremtidig funktionalitet og features. Dette vil styrke projektets fremadrettede profil og vil kunne styrke rekrutteringen til projektet. (OSS-06) 6.2 Ecosystem Network Quality Perspektivet Ecosystem Network Quality fra QualOSS-evalueringsmodellen fokuserer på 2 analyseelementer, der kan anvendes i afdækningen og belysningen af de strukturelle eller ydre kvaliteter omkring et udviklingsfællesskab. Disse karakteristika belyser de rammer og den kontekst, som et open source-projekt fremtræder i. Resource health: Dækker over økosystemets konkrete finansielle kapacitet. Ikke i økonomisk forstand, men som økosystemet og projektets evne til at udveksle og overdrage informationer, viden, person-ressourcer, kode, komponenter etc. i en tillidsbaseret ramme mellem projektets parter. Dette fungerer i princippet som en form for valuta, der er nødvendig, hvis økosystemet troværdigt og bæredygtigt skal kunne vokse i både størrelse og styrke. I KIH Databasens tilfælde er der nyligt sket en overdragelse fra leverandøren til en Open Source operatør (4S). Det er ikke muligt ud fra den beskedne aktivitet på projektet at afgøre kvalitet og omfang af det reelle samarbejde og udveksling af informationer/kode/etc. Det kan dog konstateres, at de konkret involverede parter anvender de opstillede værktøjer og mulighederne i dem. I nogen grad i KIH Databasen og i høj grad i de tilstødende projekter (Især OpenTele-klient). Det kan også konstateres, at der er sket en ensretning gennem etableringen af 4S og KIH Databasens placering her. Dette styrker klart perspektivet omkring resource health, da der i denne ramme er taget stilling til en række centrale aspekter f.eks. rollefordeling, dokumentation, versionering etc. Lakeside vurderer derfor, at KIH Databasen med en styrkelse af det nuværende setup på bæredygtig vis kan vokse betragtelig i både aktivitetsniveau, og ret enkelt håndtere og indoptage nye medlemmer i udviklingsfællesskabet. Det er dog uklart, hvilke vilkår der gælder for at træde ind (og ud) af selve 4S-samarbejdet. Stiftelsens forretningsvilkår er ikke umiddelbart tilgængelige på hjemmesiden, men kan rekvireres ved [email protected]. KIH Databasen har med rammen i 4S fået styrket et centralt element omkring projektets troværdighed. Ikke at det var utroværdigt før, men 4S-rammen styrker ind- LAKESIDE side 40 / 49

41 trykket af evne til partnerskabsdannelse og forståelsen for partnerskabet sammensætning (se nedenfor). Network health: Dette analyseelement beskriver økosystemet og projektets kreditværdighed. F.eks. vurderet ud fra de involverede partnernes individuelle status, deres indbyrdes interaktion, relationer, rollefordeling, evne til organisering samt den enkelte partners indflydelse eller status i sit lokale netværk. KIH Databasen har i 4S-rammen fået en organisering med nogle potentielt stærke (nationale) parter. Der er et vist sammenfald blandt partnerkredsen i forhold til resultatkontrakten men om der som netværk og økosystem er et uhensigtsmæssig overlap har ikke været til at afgøre ud fra den tilgængelige dokumentation. Forholdet og relationen bør klarlægges snarest. Figur 13: Netværkets organisering omkring KIH Databasen Det er Lakesides vurdering, at aktørerne omkring 4S sikrer KIH Databasen en høj kreditværdighed som økosystem, da netværkets officielle medlemmer repræsenterer de væsentlige aktører indenfor koordinering, udvikling og anvendelse af sundhedsit i Danmark. 4S har det erklærende formål at gøre det nemmere for kommuner og regioner m.fl. at anskaffe effektive løsninger af høj kvalitet, og gøre det nemmere for virksomheder at levere it, der passer til et moderne sundhedsvæsen. Den første del af denne målsætning er med den nuværende partnersammensætning godt repræsenteret, mens den direkte repræsentation af virksomheder ikke er til stede. Dette aspekt bør styrkes, hvis formålet med open source-økosystemet - at skubbe på udbredelsen og åbne markedet for flere spillere - skal lykkes. LAKESIDE side 41 / 49

42 6.3 Kritikalitet af anbefalinger vedrørende Open Source Økosystem Indsatsområder Nice to have Need to have OSS-03: Håndhæv en mere éntydig sprogpolitik i både issuetracking (Jira) og kode-repositoriet (Bitbucket) - helst på engelsk for at øge rekrutteringsgrundlaget for projektet. OSS-01: Udarbejde et overordnet roadmap for visionen omkring OpenTele og KIH Databasen, der eksplicit formulerer ambitioner, ønsker og krav til KIH Databasen på et overordnet og strategisk niveau. OSS-02: Afslutte den planlagte konsolidering af dokumentation og kildekode fra digitaliser.dk i én autoritativ kilde (Bitbucket og 4S tekniske Wiki) OSS-05: Det anbefales, at der gøres en indsats for generelt at øge aktivitetsniveauet på projektet ved at tiltrække og inddrage flere bidragsydere. Projektet er tæt på for nuværende ikke at have kritisk masse som open source projekt. OSS-04: Udarbejde den tilgængelige dokumentation (system-, arkitektur- og udviklerguide) på engelsk. OSS-06: Tage initiativ til at lave et release-roadmap og en understøttende proces til at samle og kvalificere fremtidig funktionalitet og features. Kort sigt Længere sigt LAKESIDE side 42 / 49

43 7 Samlede konklusioner og diskussion 7.1 Konklusioner på arkitekturanalysen Arkitekturanalysen viser, at KIH Databasen, som den fremstår i april 2015, har en fornuftig arkitektonisk struktur, og i store træk indeholder den nødvendige funktionalitet, for at kunne udgøre en national telemedicinsk infrastruktur for KIH. Der udestår integration til nationale sikkerhedsservices, så samtykke, frabedelse af indsigt, kontrol af behandlingsrelation m.v. bliver håndteret af KIH Databasen. Lakeside ser to migreringsscenarier, som parterne omkring KIH databasen bør tage udgangspunkt i, i den videre drøftelse af udvikling mod målarkitekturen. Når parterne har besluttet hvilket migreringsscenarie, der sigtes efter, skal der planlægges og iværksættes et migreringsforløb, hvor de nuværende anvendere af KIH Databasen om muligt migrerer deres anvendelse af KIH Databasen til de standardiserede snitflader. Samtidig skal der findes løsninger på de øvrige integrationer til KIH Databasen (P-indeks og Labdatabanken). Den automatiske videregivelse af data fra KIH Databasen til Labdatabanken bør underkastes en nærmere analyse, og Lakeside anbefaler at denne aktivitet er en del af en generel sikkerheds- og PIA-analyse 9, der klarlægger de juridiske forhold omkring informationssikkerheden og betingelser for adgang, videregivelse etc. Indtil denne afdækning er tilvejebragt bør det overvejes at standse videregivelse af data til Labdatabanken og Sundhed.dk. Det er Lakesides opfattelse, at standardisering af overførslen af sikkerhedsattributter og en tilhørende modernisering af de nuværende nationale sikkerhedsløsninger hos NSI, er en forudsætning for at ovennævnte sikkerhedskontroller kan foretages på en bæredygtig måde i de fælles løsninger. Det er således Lakesides opfattelse, at elementerne i Initiativ 3.4 analyse af sikkerhedsstandarder og løsninger snarest muligt skal projektsættes, så f.eks. Den Gode Web Service kan erstattes med standarder, der kan sameksistere med IHE standarderne. Implementeringen af disse nye standarder i KIH Databasen kan først ske på lidt længere sigt, men iværksættelsen af standardiseringsarbejdet for denne integration skal påbegyndes snarest. På review-mødet med KIH-følgegruppen den udspandt der sig en diskussion omkring anvendelsen af det dokumentbaserede paradigme i forhold til KIH Databasen. Af diskussionen kan man udlede en vis bekymring blandt nogle af parterne. Bekymringen går i kort form på, om et rent XDS-baseret løsningskoncept er velegnet til den type anvendelser eller applikationer, som KIH Databasen repræsenterer. Flere use cases, hvor KIH Databasen indgår, har en overvejende dynamisk karakter, hvor der sker udtræk af meget få eller snævert udvalgte måledata, og parterne ser behovet for at kunne parametrisere forespørgslerne til KIH løsningen. Use cases der læner sig langt mere naturligt op ad et servicebaseret brugsmønster, som KIH Databasen jo også understøtter. Temaet har i øvrigt løbende været genstand for uddybning i IHE-regi. Se f.eks. IHE Technical Framework White Paper An SOA View of IHE Profiles. Parterne på det omtalte følgegruppemøde ønskede, at denne usikkerhed blev trukket frem i nærværende rapport. Lakeside anbefaler hermed, at disse diskussioner fortsætter blandt parterne med henblik på at afdække, hvilke gevinster dokumentparadigmet skal bidrage med til KIH Database løsningen. Lakeside anbefaler i forlængelse af ovenstående, at parterne bag KIH Databasen iværksætter udarbejdelse af vejledninger, der kan støtte fremtidige projekter i at 9 Privacy Impact Assessment LAKESIDE side 43 / 49

44 afgøre, hvornår dokumentparadigmet er det bedste valg, hvornår der bør overveje andre integrationsparadigmer, og hvornår dokumentparadigmet ikke bør anvendes. 7.2 Konklusioner på modenhedsanalysen Modenhedsanalysen ( technology readiness ) viser, at der er et stykke vej endnu, før KIH Databasen kan betragtes som et modent og udrulningsparat produkt. Lakeside vurderer, at KIH Databasen succesfuldt skal have gennemgået tre væsentlige udviklingstrin, før den kan betragtes som et modent produkt: - Pilotdrift med eksterne parter baseret på de standardiserede IHE XDS snitflader. Dette vil bringe KIH Databasen til TRL 7. - Succesfuld gennemførelse af IHE connectathon som IHE XDS repository. Dette vil (sammen med ovenstående) bringe KIH Databasen til TRL 8. - Succesfuld gennemførelse af grundige og strukturerede performancetests. Dette vil sammen med ovenstående bringe KIH Databasen til TRL 9. Lakeside vurderer, at det vil være relativt omkostningstungt at bringe KIH Databasen til TRL Konklusioner på kvalitetsanalysen Kvalitetsanalysen viser, at design- og teknologivalg i KIH Databasen er fornuftige i forhold til performance, men da der ikke er gennemført en grundig performancetest, er det uklart om den fornødne performance rent faktisk er til stede i det udviklede produkt. Der kan således være uhensigtsmæssigheder i programmeringen af produktet, der gør, at produktet ikke har de performanceegenskaber, der ønskes ved langvarig belastning eller ved overbelastning. Der bør således udarbejdes og gennemføres en grundig og struktureret performancetest for KIH Databasen. Performancetesten bør som minimum indbefatte følgende performancerelaterede aspekter: - Svartidstests (middelværdi, 95% fraktil, 99% fraktil) - Ramp-up test (test af adfærd ved stigende intensitet i anvendelse) - Endurance test (kørsel med relativ høj intensitet over længere tid) - Stress test (kortvarig og langvarig overbelastning) - Test af failover og recoverability, hvor dele af systemkomplekset bevidst afbrydes eller andre fejl bevidst introduceres. Parterne bag KIH Databasen bør samtidig fastlægge nogle grundlæggende nonfunktionelle krav til en standardinstallation, herunder krav til svartider, skalerbarhedsegenskaber, ressourceforbrug, forventet adfærd ved overbelastning, fejlsituationer med videre. Såfremt det konstateres, at disse krav ikke opfyldes af den nuværende løsning, bør der lægges en plan for udbedring, hvor manglerne håndteres i en prioriteret rækkefølge. Analysen bekræfter, at der er et større udestående på informationssikkerhedsområdet i KIH Databasen. Dette fører til de samme konklusioner og anbefalinger som angivet i forrige afsnit. I forhold til pålidelighed viser kvalitetsanalysen, at en udrulning af KIH Databasen på nationalt plan vil kræve ændringer i driftstopologien. For at opnå en fornuftig balance mellem performance, pålidelighed og robusthed, finder Lakeside, at det bør overvejes at etablere flere geografisk adskilte instanser af KIH Databasen, f.eks. én i hver region. Det ændrer ikke på, at KIH Databasen kan betragtes som én logisk komponent, men robustheden bør efter Lakesides opfattelse sikres gennem distribueret driftsafvikling. Hvis alle instanser indekserer i samme indeks, vil alle dokumenter kunne findes gennem opslag i dette indeks (IHE-XDS). Hvis der etableres flere indekser (affinitetsdomæner) vil det kræve en IHE-XCA infrastruktur. I forhold til KIH Databasens vedligeholdelsesegenskaber finder Lakeside, at der er fornuftige muligheder for at vedligeholde den nuværende KIH Database løsning. LAKESIDE side 44 / 49

45 Den dokumentation, der er leveret sammen med komponenten, er i en fornuftig stand, koden er velstruktureret og passende modulopdelt. Der er imidlertid flere dokumentationsdele der helt mangler. Dette bør udbedres, ligesom testkode skal fjernes fra produktionskoden. Tilsvarende finder Lakeside, at KIH Databasen har gode portabilitetsegenskaber. KIH Databasen vil uden større problemer kunne migreres til en anden applikationsserver (inden for samme teknologiregime) og/eller til et andet operativsystem. Endvidere vil man kunne udskifte SQL databasen med et andet SQL databaseprodukt uden større problemer. 7.4 Konklusion på KIH i et Open Source økosystem KIH Databasens status som open source-projekt og som element i et egentligt økosystem er grundlæggende god. KIH Databasen er som komponent lagt ind i en fornuftig ramme til forvaltning og videreførelse af en open source-strategi. Dog ville det styrke det generelle indtryk af KIH Database-projektet, hvis der forelå en overordnet formulering af ambitioner, ønsker og krav på et mere overordnet og strategisk niveau. F.eks. i form af et overordnet roadmap for visionen, som KIH Databasen er en del af. Konsolideringen af dokumentation og kildekode hen mod én autoritativ kilde er fornuftig og styrker både overblik og mindsker forvirring om projektets status og placering. Denne påbegyndte konsolidering bør afsluttes hurtigst muligt. Konsolideringen ser også ud til at have haft indflydelse på sprogpolitikken i projektet, hvor arbejdssproget for udviklere er engelsk. Det er Lakesides anbefaling, at sprogpolitikken håndhæves endnu strammere for at øge den internationale profil og øge mulighederne for rekruttering af nye ressourcer og bidragsydere til projektet. Kvaliteten af det generelle Open Source Community omkring KIH Databasen vurderer Lakeside til at være et stykke under middel. Projektet er tæt på ikke at have kritisk masse blandt aktive bidragsydere, ligesom det er svært at afgøre i hvilket omfang der reelt lukkes bugs/issues i projektet. Rammerne for udviklingsfællesskabet er veletablerede ligesom værktøjerne, der stilles til rådighed for rapportering af issues/bugs og til versionering og branching, bliver brugt og brugt korrekt. Men hvor der er beskrevne processer på plads for fejlrapporteringer og branching af kodebasen, så mangler der en overordnet plan for styring af releases, hvilke features de indeholder samt hvilke tillæg til funktionaliteten de vil bidrage med. Der er i kildekoden inkluderet moduler til gennemførelse af test på forskellige niveauer samt nødvendige testdata. Lakeside anbefaler, at parterne udarbejder en test-strategi, der formulerer de generelle krav til tests for bidragsydere til projektet og evt. kommunikerer dette i en enkel test-guide sammen med den øvrige dokumentation. Lakeside finder, at KIH Database-projektets forankring i en partnerskabsmodel med 4S som operatør, ser ud til at fungere og har løftet kvaliteten af netværksdannelsen omkring Open Source-delen. Således er KIH Databasens Open Source Network Quality relativ høj: partnerskabet involverer en række betydende parter indenfor det telemedicinske felt. Anbefalingerne i denne analyse går næsten udelukkende på at maksimere udnyttet af dette. Dette kan dels ske ved at udarbejde en egentlig strategi for at udvide økosystemets klyngedannelse, og dels ved at søge at rekruttere og aktivt få inddraget flere private virksomheder i anvendelsen af økosystemets komponenter. LAKESIDE side 45 / 49

46 7.5 Diskussion vedrørende anskaffelse af standardprodukt Hvis parterne bag KIH Databasen vælger at migrere KIH Databasen mod et scenarie 1 (opsamling + repository), som beskrevet i afsnit 3.3, vil der være flere muligheder i relation til repository delen: A. Anskaffe et kommercielt produkt, der realiserer IHE-XDS standarden B. Anskaffe et Open Source produkt, der realiserer IHE-XDS standarden C. Kravspecificere en løsning, der realiserer IHE-XDS standarden, og søsætte et udviklingsprojekt D. Hybrider, f.eks. at der anskaffes et Open Source produkt, men at der videreudvikles på dette, så det bedst muligt tilpasses den telemedicinske infrastruktur Hver af disse realiseringsmuligheder har sine styrker og svagheder. Et udbredt og velafprøvet kommercielt produkt må forventes at have en højere modenhed og nogle bedre drifts- og support-egenskaber end et eget-udviklet produkt vil have fra begyndelsen. Omvendt kan kommercielle produkter stille nogle særlige krav til infrastruktur og anskaffelse af øvrige komponenter fra leverandøren. Endvidere er der selvfølgelig licensprisen, der skal med i overvejelserne. Et Open Source produkt kan være modent, velafprøvet og velsupporteret, men kan også være skrøbeligt ift. mode-fænomener. F.eks. kan eksisterende projekter/produkter lide en stille død ved at de primære udviklerressourcer flytter til nye og for dem mere interessante projekter. Til gengæld har man mulighed for at påvirke Open Source projekter til at gå i en bestemt retning, eller for den sags skyld bidrage til projektet med komponenter, der passer til egne behov. En egenudviklet løsning giver ultimativ frihed til at tilpasse løsningen, men kan være dyr at anskaffe og vil tage år om at modne. Modenhed Egenudvikling Kommercielt produkt Open Source Tilpasset Open Source I forhold til KIH repository vil det uanset hvilken anskaffelsesmodel man anvender være et krav, at produktet kan tilpasses/konfigureres, så det kommer til at håndhæve hensigten i dansk lovgivning i forhold til informationssikkerhed og privatlivssikring. I nogle tilfælde vil dette være nemt, hvis f.eks. det er muligt at indføje plug-ins der kan foretage de fornødne it-sikkerhedsmæssige kontroller og sikringer. I andre tilfælde vil det være omkostningstungt, eller endog umuligt at få indar- Figur 14 - Generel sammenhæng mellem fleksibilitet og modenhed for de forskellige anskaffelsesscenarier. Fleksibilitet LAKESIDE side 46 / 49

47 bejdet de nødvendige kontroller. Måske fordi leverandøren ikke ønsker at lave en specialudgave af sit produkt til danske forhold. På baggrund af denne analyse opfordrer Lakeside til, at der i kredsen omkring KIH Databasen initieres en diskussion af især scenarierne A) og B) med henblik på en evt. pilotafprøvning af et XDS-baseret alternativ til den nuværende KIH repository løsning. Scenarie A: Udsøge et kommercielt standardprodukt og opstille en kravsmatrix i forhold til nationale krav til informationssikkerhed og sikring af overholdelse. Udarbejdelse af en samlet, sammenlignelig pris for licens samt evt. tilpasning og plugins. Scenarie B: Hjemtagelsen af et velafprøvet Open Source-produkt. Som ovenfor: opstille kravsmatrix i forhold til nationale krav til informationssikkerhed og sikring af overholdelse. Udarbejdelse af en samlet, sammenlignelig udgift (f.eks. udviklingsog tilpasningsbistand) fra en distributør af open source-produktet. Det er her vigtigt at skelne mellem KIH Databasen som koncept og KIH Databasen som produkt. KIH Databasen som koncept vil ved anskaffelse af et andet produkt bestå, mens et KIH repository som projekt i sin nuværende form vil udgå. LAKESIDE side 47 / 49

48 8 Referencer Reference-ID Indhold/Overskrift Link / Placering [SQuaRE] [TRL] [QuESo] [REFARK_TELE] [REFARK_DELING] [REFARK_SIK] [PHMR-DK] [INIT-1.4] Systems and software Quality Requirements and Evaluation (SQuaRE) Technology Readiness Level metode. Anvendes blandt andre af NASA og ESA. QuESo: a Quality Model for Open Source Software Ecosystems Referencearkitektur for opsamling af helbredsdata hos borgeren Referencearkitektur for deling af dokumenter og billeder Referencearkitektur for informationssikkerhed. Implementation Guide for CDA Release 2.0 Personal Health Care Monitoring Report (PHMR) DK profile Data content Modning af telemedicinsk infrastruktur detail.htm?csnumber= nology_readiness_level ication/ _queso_a_quality_ Model_for_Open_Source_Software_ Ecosystems d/dk%20- %20dansk/Sundhedsdata%20og %20it/NationalSundhedsIt/Stand ardisering/referencearkitektur%20for %20opsamling%20af%20helbred sdata%20hos%20borgeren%20v%20 %201.ashx d/dk%20- %20dansk/Sundhedsdata%20og %20it/NationalSundhedsIt/Stand ardisering/referencearkitektur%20for %20deling%20af%20dokumente r%20og%20billeder%20v%20%2 01%200.ashx d/dk%20- %20dansk/Sundhedsdata%20og %20it/NationalSundhedsIt/Stand ardisering/referencearkitektur%20for %20informationssikkerhed%20v %20%201%200%20nyt%20layou t.ashx d/dk%20- %20dansk/Sundhedsdata%20og %20it/NationalSundhedsIt/Strate gi/14%20modning%20af%20tele medicinsk%20infrastruktur.ashx LAKESIDE side 48 / 49

49 [OpenTeleAnalyse] OpenTele analyserapport, version [DGWS] [QuESo] Den Gode Web Service version QuESo: a Quality Model for Open Source Software Ecosystems, Oscar Franco- Bedoya et.al., /artefact/Den+Gode+Webservic e pdf [QualOSS] [Jansen, 2013] [ON-DEMAND1] [ON-DEMAND2] The QualOSS open source assessment model measuring the performance, Soto, M. & Ciolkowski, M., 2009 Software Ecosystems: Analyzing and Managing Business Networks in the Software Industry, Jansen and Cusumano, 2013 IHE IT Infrastructure Technical Framework Supplement On-Demand Documents Trial Implementation, October 2013 XDS & XCA: On-Demand Documents Option Juni, lede- Details.jsp?reload=true&arnumber= (Bog / ebog) Documents/ITI/IHE_ITI_Suppl_On_Dem and_documents_rev1.3_ti_ pdf ftp://ftp.ihe.net/it_infrastructure/i TI_EducationalMaterials/CurrentP ublished/ihe-xds&xca-on- Demand_ pptx LAKESIDE side 49 / 49