Hvordan OSS er m ed til at sikre

Transkript

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

2 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):??? 2

3 Digital Sammenhæng kræver Interoperabilitet mellem Organisationer IT-systemer Organisationsudfordringen er den største m en ikke dagens em ne 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 3

4 Skaf noget IT! Der er 3 muligheder Selv udvikle Software fra ny Fuld kontrol og fuld risiko Lang modning Høj kontrol 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) Lav kontrol Kort modning 4

5 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!!) 5

6 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) 6

7 Kort tid til brug 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/selvudviklet 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 7

8 Idealer for sammenhæng 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 Semantisk Standard er Science Fiction AI lever 8

9 Sammenhæng med Open Standard = Interoperabilitet Bløde Standarder er åben for fortolkning Karakter af guideline (god til revision) Typisk for IT Interoperabiliteten (værdien) forsvinder sundhed 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 9

10 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 10

11 SVÆR Standarderne på nem måde 1. Standard gennem open source API er / Kodebiblioteker til Java og.net Seal, supporteret, dokumenteret og afholdte kurser Undervisning sæ nker yderligere 2. 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 3. Komponenter på open source National ServicePlatform Caching af Interaktions data, Digital-ID mm. Afvikle komponenter LET 11

12 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 NSP

13 Sådan vælges OSS! Try before buy (Altid) 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/ Adm inistration Deployering (Engangs / Hot / Cold) Referencer (BRUG DEM) Det er også godt at det er Open Source!! 13

14 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 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) 14

15 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!). Versionskontrol og publiceringskanal: 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: Arkitektur: Vi anvender snart 15

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