National Service Platform for Sundhedssektoren. Odense, d 28. Maj 2009 Ved Esben P. Graven, Digital sundhed (SDSD)

Transkript

1 National Service Platform for Sundhedssektoren Odense, d 28. Maj 2009 Ved Esben P. Graven, Digital sundhed (SDSD)

2 Nuværende SOA-infrastruktur Hovedparten af kommunikationen baseres på internet (til knude og tilbage) Services lever i lokale driftsmiljøer Autentifikation ( sign-on ) skal ske mange gange (kan ikke optimeres på tværs af serviceudbydere) Der var ikke en fælles måde at håndtere identitet. Brugerstyring og adgangskontrol mangler stadig

3 SDN fra Beskeder til Services Service udbyder (FMK) Udgangspunktet er internettet hvor alle kan se alle de kender Usikkert, Isoleret, Uovervåget SDN samler over en Knude (rod inden i) Central overvågning og kontrol for ROUTERE og edifact beskeder Klienter skal kende servere for Service Service forbruger (Medicinmodul) For web services klienter skal kende alle server destinationer Governance byrde blot forværret som vist i højre side Vi ønsker NSP skal gøre for services som VANS gør for beskeder

4 Sammenhæng gennem Reference arkitektur NSP er et kerne element i denne Tekniske standarder Det vi gerne vil starte med at lette tilgangen til Indholdsmæssige standarder Pt. Ikke i scope for NSP

5 Web Services reference arkitektur Terminologi klassifikation SNOMED/SKS Patient/Borg er (CPR) Yder- + autorisations register Organisationsregister (SOR) Std-planer og kliniske vejledninger Patient Indeks (NPI) Sekundær dataanvendelse Udtræk til datavarehuse Logning og monitorering Beregningsservices (DRG) Tværgående services og støtteservices Sikkerhed Notat Journal data og services Medicinering (FMK) Forretningsinfrastruktur (Statiske registre) Personale og roller Indberetningsservices Laboratoriesvar Billedediagnostik (Røntgen, EKG, CT/MR-Scan) Registre (dynamiske) Klin. DB (NIP) Patientregister (LPR) Sygesikrings register Afregnings- Databank (SDB) Centrale tilskudsregister (CTR) Canserreg., dødsårsagsr. Patobank NSP Fælles Services (Data og funktionalitet udstilles) Kommunikationsbus Apoteks Systemer Omsorgs- og genoptræningssystemer Røntgen Systemer Laboratorie Systemer Kliniske systemer (EPJ) Praksissystemer Kommunikation via sundhedsdatanettet Portalrammeværk (Sundhed.dk) Apoteker Anvendelse Kommunalt plejepersonale Røntgenkliniker Hospitalskliniker Laboratoriekliniker 5 Praktiserende læge Sundhedsperson, Borgeren

6 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 fler gange 3. Komponenter på open source National ServicePlatform Caching af Interaktions data, Digital-ID mm. Afvikle komponenter LET

7 Support og drift aspekter Kodebiblioteker (OSS = ingen support Fejl!!) Findes ikke i driftbilledet. Ideelt uden bindinger til DB, MQ, M.fl. Afslører programmet der bruger dem en fejl -> nogen skal kunne rette Who do you call? ServiceDesk s bug-busters (dem på kontrakten) Statiske biblkioteker kræver gen-compilering Komponenter Skal deployeres Afhængigheder til DB, MQ m.fl. Behøver ikke re-compilering men Fejl skal stadig Fix es Vise kvalitet (Standard test-harniks) Ingen STANDARD platform (MS/Unix etc. ) Gå til ServiceDesk -Passeres start =Indbetal 0 kr.

8 National drift(er)??? Start Drift Start Drift Standard Platform National Deployering National Drift Support (ja ja den kender vi) Overvågning Drift (= ServiceDesk en skifter boksen) Decentral og Central NSP

9 Vi starter med FMK Deployering lokalt drift/ opdatering nationalt LOKALE SYSTEMER STS LOKALE SYSTEMER FMK NSP SOSI-GW sdn FMK FMK LOKALE SYSTEMER SOSI- DCC Indenfor Regions net

10 Nationalt Service Platform og driftsmiljø Ensartet miljø giver mulighed for fælles udvikling af komponenter Bl.a. gateway-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.

11 NSP som driftsmiljø Klarere ansvarsdeling Nationalt tages ansvar helt ud til el-måleren garanteret driftseffektivitet m.v. af nationale services Der indgås SLA mellem serviceudbydere og nationalt niveau samt nationalt niveau og serviceaftagere Det kan måles om den enkelte service overholder SLA Servicecentre (Regioner, KMD, lægepraksisleverandører, ) tager ansvar for at systemer kan fungere for den enkelte arbejdsplads, såfremt de nationale services overholder SLA

12 Mål for en CENTRAL NSP NSP Undgå distribution & kopi af interaktionsekspertise på tværs af organisationer Skab et FÆLLES syn på services (dokumentation, interfaces etc). Sænk kompleksitet, (Spaghetti isolateres I NSP) så pålidelighed vokser og administration styrkes Isoler fejl (tydeliggør hvem der løser problemet). Centraliseret styring af forretningsprocesser, der går på tværs af flere organisationer Sammenligning med telefonen, Er det bedst at: Forbinde din telefon til omstillingen? eller Trække et kabel til alle dem du potentielt skal tale med? NSP svarer til omstillingen

13 Hvorfor IKKE én central NSP Flaskehals Begrænset ydelses skalering Clustering når en mætning og er dyrt Problematiske at opretholde høje serviceniveauer Altid WAN mellem serviceproducent og konsument Kan ikke optimere sikkerhed Står ikke lokalt

14 Referencearkitektur for NSP ESB mønstre Internal ESB Traditionel EAI Global ESB Central regulerende ESB gateway Sikkerheds element Federated ESB Central uden flaskehals Brokered ESB Central mere fri

15 NSP Varedeklaration Et sikkert transportsystem, som kan forbinde et stort antal løst koblede IT-løsninger, således at disse automatisk kan anvende hinandens services og data FMK Meddelelseshåndtering Sikker transport Routing/ transformering Sikkerhed Autentifikation af brugere Rolle/rettighedsstyring og autorisation Fortrolighed, firewalls Overvågning Monitorering Logning Konfigurering Katalogtjeneste Publicering Understøttelse af vedligeholdelsesprocesser Proceshåndtering Orkestrering/Workflow Event håndtering og advisering

16 Vision for NSP Fra: ingen garantier, lukket sikkerhed og minimal start indsats og begrænset overvågning Til: drift garanti, åben og lukket sikkerhed, end2end overvågning ( SLA )(SLA )( SLA ) IDAG: 1 forbindelse dækker 3 forskellige service aftaler, uden NSP & central overvågning NSP ( SLA ) VISION: 1 forbindelse, 1 service aftale, central overrvågning (synlig lokalt), NSP Lokal kopi NSP

17 Vision for Sundhedsdatanettet Udvidet fysisk og ansvarsmæssigt