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

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. +45 21607252 www.lakeside.dk info@lakeside.dk

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

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

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

Revisionshistorik Version Dato Ans. Beskrivelse 0.1 2015-02-28 JRI Disposition og råt udkast. 0.2-0.7 2015-03-23 JRI Udviklingsversioner internt hos Lakeside 0.81 2015-03-24 JRI Samlede konklusioner indarbejdet. Udsendt til gennemsyn i følgegruppe og udvalgte eksterne parter. 0.9-0.94 2015-04-14 JRI Migreringsscenarier indført efter drøftelser med følgegruppen. 1.0 2015-04-15 JRI Final review. Udsendt til parterne. 1.1 2015-04-15 JRI Fejl i anvendelse af iti-41/42/43/61 rettet. Domæneråd/Domæneudvalg erstattet med råd. LAKESIDE side 5 / 49

Kontaktperson Chefkonsulent Jan Riis Lakeside A/S jri@lakeside.dk tlf. +45 2160 7252 LAKESIDE side 6 / 49

Indholdsfortegnelse 1 Ledelsesresumé... 2 2 Indledning... 8 2.1 Metode og rapportens opbygning... 8 2.2 Tilblivelsesmetode... 10 2.3 Afgrænsninger... 10 2.4 Forkortelser og termer... 11 3 Arkitekturanalyse... 13 3.1 AS-IS arkitekturen... 13 3.2 Målarkitekturen (TO-BE)... 14 3.3 Migrering af KIH Databasen fra AS-IS til TO-BE... 16 3.3.1 Scenarie 1 Opsamling + Repository... 17 3.3.2 Scenarie 2: On-Demand repository... 19 3.4 Konklusioner og anbefalinger... 20 4 Modenhedsanalyse ( Technology Readiness )... 22 4.1 Vurdering af teknologiparathed / modenhed... 22 4.2 Konklusioner og anbefalinger... 24 5 Kvalitetsanalyse ( SQuaRE )... 25 5.1 Performance / Effektivitet... 25 5.1.1 Teknologivalg i relation til performance og skalering... 25 5.1.2 Ressourceforbrug og udnyttelse... 26 5.1.3 Konklusioner og anbefalinger... 26 5.2 Vurdering af pålidelighed... 26 5.2.1 Tilgængelighed... 26 5.2.2 Fejltolerance og rehabiliteringsevne... 26 5.2.3 Konklusioner og anbefalinger... 27 5.3 Vurdering af informationssikkerhed... 27 5.3.1 Konklusioner og anbefalinger... 29 5.4 Vurdering af vedligeholdelsesmuligheder... 29 5.5 Vurdering af portabilitet... 32 5.6 Kritikalitet af anbefalinger vedrørende kvalitet... 33 6 KIH Databasen i et Open Source Økosystem... 34 6.1 KIH Databasens fit til et Open Source Økosystem... 35 6.1.1 Overordnet vurdering... 35 6.1.2 Konklusioner og anbefalinger... 36 6.1.3 Vurdering af Community Quality... 36 6.2 Ecosystem Network Quality... 40 6.3 Kritikalitet af anbefalinger vedrørende Open Source Økosystem... 42 7 Samlede konklusioner og diskussion... 43 7.1 Konklusioner på arkitekturanalysen... 43 7.2 Konklusioner på modenhedsanalysen... 44 7.3 Konklusioner på kvalitetsanalysen... 44 7.4 Konklusion på KIH i et Open Source økosystem... 45 7.5 Diskussion vedrørende anskaffelse af standardprodukt... 46 8 Referencer... 48 LAKESIDE side 7 / 49

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:2011 - Software product Quality Requirements and Evaluation [SQuaRE] QuESo - Quality Model for Open Source Software Ecosystems [QuESo] LAKESIDE side 8 / 49

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

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 2015. 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

- 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

thermometers, weight scales, etc. Se også http://www.medcom.dk/wm112683&searchword=phmr 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

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

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. 2013. [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

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 11073-101, 11073-20601, og 11073-104xx, 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

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

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. 3.3.1 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

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

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

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

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

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 2015. LAKESIDE side 22 / 49

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

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

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 25010.2 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 5.1.1 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