Hvordan OSS er med til at sikre sammenhæng og digitalisering i sundhedssektoren Ved Esben P. Graven, Senior it arkitekt Digital sundhed (SDSD) Spørgsmål til: esg@sdsd.dk

SammenhængendeDigital Sundhed i Danmark Fælles eje mellem stat, regioner og kommuner Opskrift (lad det simre et par år) 5 x Arkitekter og 1 x Sikkerhed ansvarlig 8 x Sekretariatets folk 6 x Indholdsmæssig standardisering 10 x Projektorganisation Retter på menuen (Projekter i gang) Fælles MedicinKort (FMK): open source National ServicePlatform (NSP): open source Nationalt Patient Index (NPI): ???

Digital Sammenhæng kræver Interoperabilitet mellem Organisationer IT-systemer Organisationsudfordringen er den største …men ikke dagens emne IT udfordringen er den mest synlige Åbenhed eller Verdensherredømme Standarder (Open eller Lukket) Protokoller  Indholdsmæssig  ”Standard” programmer (OSS eller Købt) Kræver kendt data grundlag og fælles processer

Skaf noget IT! Der er 3 muligheder Selv udvikle Software fra ny Fuld kontrol og fuld risiko Købe udvikling af software (mindre kontrol større risiko) Open Source Software Hurtig Start og mellem risiko med mellem pris Videreudvikling kan være åben eller lukket Købe Færdig Software Hurtig start og mellem risiko med høj pris Udvikl/Tilpas kommer bagefter a-la makroer Motivation for OSS på Sundhedsområdet Mange små aktører, ikke råd til ”stor” SAML 2.0 HW Lettere at skifte leverandør (Gennemsigtighed i kodebasen) Lang modning Høj kontrol Lav kontrol Kort modning

Sammenhæng gennem tilpasning Organisationen Den klassiske BPR pointe Tilpas ikke software til en uoptimal process Optimer først processen, er dog ikke altid mulig! “Politiske” interesser frem for tekniske OSS/købe løsning kan ofte “skære” igennem Ved køb ses den i regnskabet “øjeblikkelig” Den eksisterende portefølje Software kan være ”Åben” på mange måder: Interfaces, Data(DB) og Kode(=OSS eller min Min! MIN!!) ¸ +

Kvalitet og test Open Source og Køb: Testgruppen kan være “hele verden” vs. vores firma Undersøg om der er ordentlig mulighed for rapportering af fejl (gerne nyhedsgruppe/bbs) Byg Selv (Open Source ): Den mangelfulde modultest (Den blinde vinkel… Arrgh Diciplin) Test af ekstremerne og samtlige permutationer over anvendelse (CC)

Kort tid til brug Det er ikke godt, blot fordi det er Open Source !! Open Source Software er udviklet og klar til brug (Hvis aktivt community) med den hastighed IT/markedet har i dag er det ofte nok til, at fordelen ved indførsel er væk før udviklingen er afsluttet! Det tager altid “længre tid” før ny/selv-udviklet software er driftmoden! Er der råd til at fejlbehæftet kode rammer brugerne? Renommé, Kompensations pris! OSS og Købe software kan have samme skavanker som byg selv, check referencer A == A

Idealer for sammenhæng Semantisk Standard er Science Fiction Instant soft Plug and play Standarder er “Bulldozerne” Det generiske XML interface findes ikke!!! ….så sats på integrationskode Open source Vi kan være heldig at ”udviklingen kører selv” Mange problematikker som byg selv, men med jump-start! Grader af Open Alle må og kan bruge det Det er gratis (i modsætning til DS484 ) Alle kan bidrage (ændre det) Wikipedia For standard?? Dynamisk vs. Statisk ”Performance sucks” Optimeret dynamik kræver høj kompetence AI lever

Sammenhæng med Open Standard = Interoperabilitet Typisk for sundhed Bløde Standarder er åben for fortolkning Karakter af guideline (god til revision) IT Interoperabiliteten (værdien) forsvinder Hårde åbne standarder For sammenhæng bliver det sekundært om software er: Selvbygget, Open eller Købt Det er omfattende at lave og kode de hårde standardiseringer (profiler) SDSD’s eksempel er ”Den Gode WebService” DGWS. Der er mange aspekter at beskrive hvis dokumentationen skal være fyldestgørende Der er MANGE klienter, der betaler en stor til mellem sum

DGWS – anvendte standarder SÅDAN: Open Source mindske tærsklen for Open Standards som sikre sammenhæng i Sundhedssektoren Løber hurtigt op i flere hundrede siders dokumentation … dyrt at kode fra bunden

Standarderne på nem måde SVÆR Standard gennem open source API’er / Kodebiblioteker til Java og .Net ”Seal”, supporteret, dokumenteret og afholdte kurser  Undervisning sænker yderligere API’er ind i open source Gateway SOSI Komponenter Applikationer kalder WS med uid+pwd Gateway bruger Seal Lokal tilpasning vælter ”kodes engang bruges flere gange” Komponenter på open source National ServicePlatform Caching af Interaktions data, Digital-ID mm. Afvikle komponenter LET

Nationalt ServicePlatform og driftsmiljø Ensartet miljø – giver mulighed for fælles udvikling af komponenter Flersidet sikkerhedsmodel Eksisterende aftalesystem Fælles brugerstyring over digitale identiteter Frihedsgrader – komponenter kan ”leve” centralt og decentralt Mulighed for at implementere tværgående aspekter i alle services Sikkerhedsmæssigt etc., ”Service-toppen” / ”Min log” Synkron-asynkron afkobling, etc. Klarere ansvarsdeling Det kan måles om den enkelte service overholder SLA NSP

Sådan vælges OSS! Try before ”buy” (Altid) Kriterier: Pilotprojekt Sørg for at testerne har rette skillset Kriterier: OS platforme (Operativ system) Teknologi basis (Kendt Sprog: Perl, Java, C# ikke MUMS, Bonk) Værktøj: API(ind), Makroer(inde), og ”Exits”(ud) Hvor levende er udviklingen? Support for Betaling? (Lokalt?) Databaser Skalerbarhed Robusthed Styring/Administration Deployering (Engangs / Hot / Cold) Referencer (BRUG DEM) Det er også godt at det er Open Source !!

Sådan udvikles open source Adskiller sig ikke væsentligt fra andre udviklingsprojekter blot underlagt andre licensbetingelser (Vigtig valg) Vi (leverandør) skal huske at vi skal ”slippe grebet” på et tidspunkt. Evnen til at overdrage softwareudvikling Kræver ”godt håndværk” (”intuitiv kode”) Grundig dokumentation Gode metrikker (”build miljøer”, høj testdækning, performancetest) publiceret (se www.sosi.dk) Overdragning kan afprøves lad en 3. part vurdere byrden ved at overtage projektet ved projektafslutning Aktiv brugerskare Vi har hele sundhedssektoren som kunder (specielt lægepraksissystemlev., EPJ-lev, Styrelser som serviceudbydere)

Sådan udvikler vi (Checklisten) Aktive udviklere (3. parts leverandører, der styres af Driftsoperatøren, Fælleskab er bedre men svær på teknik) En aktiv organisation til at klare det formelle (SDSD etableret Driftsoperatør) OSS licens: Vi kører en dual licens (Vælg med omhu!). http://arkitektur.sdsd.dk/twiki/bin/view/Operator/ArkitekturKompOSSLicens Versionskontrol og publiceringskanal: www.softwarebørsen.dk Subversion (SVN) og kan udstille binære filer Kvalitetskontrol: Operatøren sætter pt. continuous integration værktøj med kodekvalitetsmålinger (code coverage, mm.) op og foretager code reviews. Leverandørerne udvikler testcases og gennemfører tests i forbindelse med leverancer. Dokumentation Teknisk: www.softwarebørsen.dk Arkitektur: Vi anvender snart www.digitalisér.dk

Vision for SundhedsServices Open (Source) Services kræver lukket (garanti) infrastruktur Cirklen sluttet til projekterne på 2. slide