FMK og Infrastruktur. Et paradigmeskift for SDN Ved Esben Graven, Digital Sundhed

Transkript

1 FMK og Infrastruktur Et paradigmeskift for SDN Ved Esben Graven, Digital Sundhed 1

2 SDN på 55 sek. SDN uden indhold er som kabler uden strøm! 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 kun kende partner adresse Start ALLE-til-ALLE (en-til-en) Næste trin dele beskeder: Henvisninger Næste trin dele data online: FMK 2

3 Fælles Medicinkort afspejler borgerens aktuelle medicinering, og deles af alle parter gennem de forskellige itsystemer NU situationen FRA at sende data SPECIAL PRAKTISERE ORGER LÆ GE ND E LÆ GE VAGTLÆGE INSTITUTION ER OG PLEJEHJEM APOTEK Paradigme skift TIL af dele data SYGEHUS HJEMMESYG EPL EJE SPECIAL LÆ GE PRAKTISER EN DE LÆ GE ORGER SYGEHUS VAGTLÆGE INSTITUTION ER OG PLEJEHJEM APOTEK HJEMMESYG EP LE JE 3

4 Et forenklet billede af NU Aktør A Aktør WS kald Data skubbes mellem applikationer via EDI-meddelelser Udstrakt anvendelse af kopier af de samme data Normalt ingen fælles data-lager Der finde en lukket infrastruktur for meddelelser kaldet VANS (Value Added Service Network). Postkasser (GATEWAY) og Posthus (Central rutening + store&forward) nedbryder kompleksiteten af semantisk punkt-til-punkt forbindelser Lukket fordi kommunikationsprotokollen er PROPRITÆR og kun har to danske leverandører Krav og standarder: Netværk SDN Kommunikation Proprietære asynkrone beskeder Identifikation Partner tabel/ Organisations niveau Indhold EDI Leverance kvalitet Ingen garanti / tilkøb af individuel support Infrastruktur VANS (etaling pr. besked til leverendør)

5 FMK kort beskrevet Det Fælles Medicinkort (FMK) Målet er at alle danskere får et aktivt opdateret elektronisk medicinkort, for at højne kvaliteten af den medicinske behandling FMK er en teknisk milepæl For at vise best practice for integration af det danske sundhedsvæsen via online webservices Web-services er Ikke en browserløsning / portal-løsninger System til system kommunikation Kræver tilretning af de systemer, der skal integrere med FMK Kræver netværk, der kan håndtere sikker kommunikation = SDN Krav og standarder: Netværk SDN Kommunikation DGWS 1.01 Identifikation OCES 1/2 og SOSI-ID Indhold OIO-XML Leverance kvalitet Overvågning og support Infrastruktur National Serviceplatform 1.0 5

6 Serviceenablede statiske registre Autorisationsregister Terminologi klassifikation (SNOMED/SKS) Patient/orger (CPR) Illustration af den nationale sundheds-itinfrastruktur Organisationsregistre (SOR, yderreg.) Std-planer og kliniske vejledninger NSP Notat Patient Indeks (NPI) Journal data og services Medicinering (FMK) Støtteservices Logning og monitorering Laboratoriesvar Indberetningsservices illedediagnostik (Røntgen, EKG, CT/MR- Scan) Driftsmiljø for fælles komponenter Kommunikationsbus Henvisning og rekvisition Planlægning og logistik ooking Udtræk til datavarehuse Sekundær dataanvendelse FMK og NSP Planer Nationale sikkerhedsservices eregningsservices (DRG) Serviceenablede dynamiske registre Kvalitet og forskning Klin. D (NIP) Patientregister (LPR) Canserreg., dødsårsagsr. Administration Sygesikrings register Afregnings- Databank (SD) Centrale tilskudsregister (CTR) Gateway Værktøjskasse Lokale sikkerhedskomponenter systemer Praksissystemer Omsorgs- og genoptrænings- Røntgen Systemer Laboratorie Systemer Kliniske systemer (EPJ) National Portal (Sundhed.dk) NPI- Viewer. Kodebiblioteker Praktiserende læge Kommunalt plejepersonale Røntgenkliniker Hospitalskliniker Laboratoriekliniker orgere Klinikere

7 rug af FMK kræver Krav til systemejere ved FMK udrulning: Alle systemer, der skal tilgå FMK, skal tilpasses* Alle medarbejdere, der skal anvende FMK, skal udstyres med digitalsignatur (Læger, lægensmedhjælp) Digital signatur skal kunne anvendes fra alle arbejdspladser, der skal tilgå FMK (*)Krav til Applikationer, der skal kalde FMK: 1) kunne oprette id-kort 2) få brugeren til at signere id-kort 3 & 4) få et bruger-signeret id-kort godkendt af IDP'en 5,6 eller 7) anvende det IDP godkendte id-kort i alle kald til FMK eller andre services, der kræver identifikation sdk sdk sdk sdk 7

8 Introduktion af Gateway På kanten mellem to sikkerhedsdomæner Domæne 1 Sikkert og lukket net Høj perimetersikkerhed F.eks. backend servernet rugere og systemer er kendt i domænet Typisk DGWS niveau 1,2 Domæne 2 Sundhedsdatanet (el. lign.) rugere er ikke kendt i domænet Typisk DGWS niveau 3,4 På sigt håndteres også indadgående Pt. 2 stk. SOSI-GW og SOSI- DCC skal omkodes til lokal IT- Drift Domæne 1 (fx Region ) LOKAL SYSTEM LOKAL SYSTEM Service Gateway Domæne 2 (fx Styrelse ) Service (FMK) Service LOKAL SYSTEM 8

9 Visualisering af National Serviceplatform (NSP) Deployering lokalt (Vaskemaskine) drift/ opdatering nationalt Minimumsmodel!!! LOKAL SYSTEM STS LOKAL SYSTEM FMK NSP SOSI-GW sdn FMK FMK LOKAL SYSTEM SOSI- DCC Indenfor regionsnet 9

10 Her er vi i dag a) Lokale driftsorganisationer der er professionelle Overvågning 24x7x365½ Planer for disaster recovery Driftscenter der er dublerede Med dubleret net opkobling b) Nationale serviceudbydere Overvågning der er 24x7? Driftscenter centralt For nationale services reelt kan benyttes må b) være lige så god som a) = ehov for højt kvalitet af drift og ydelse af HELE infrastrukturen

11 NSP Arkitektur i eventyr En ring til at herske over dem alle Der skal tungt vejende ting til for at gå med til en sådan aftale Sejt kluns, magt og udødelighed eller Let admin med høj: sikkerhed, robusthed, performance og kvalitet EPJ LAN udødelighed og nem syst.adm. PAS Div. NSP og SDN Central og De-central PAS LAN udødelighed og nem syst.adm. EPJ Div. EPJ Div. LAN udødelighed og nem syst.adm. PAS LAN udødelighed og nem syst.adm. PAS EPJ Div. EPJ LAN udødelighed og nem syst.adm. PAS EPJ Div.

12 NSP skal sikre edre fleksibilitet og bedre governance Sænke tærsklen for overholdelse af krav Højne udviklingseffektiviteten Tilpasning til eksterne (standarder) Samlet national organisering med support, ansvar(sla) og længere sigtet planlægning Drift med høj ydelse og robusthed

13 Hvorfor 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

14 Hvorfor IKKE kun én central NSP Central flaskehals egrænset ydelses skalering Clustering når en mætning og er dyrt Problematiske at opretholde høje serviceniveauer Altid WAN mellem serviceproducent og konsument Robust overfor udfald af SDN Lokal data: leveret hurtigere end lyset Central kan ikke optimere sikkerhed For at gøre det skal NSP stå lokalt 14

15 National drift i tre modeller Central knude centralt drevet De-central knude centralt drevet Vi vil men mangler teknik og erfaring De-central knude de-centralt drevet

16 NSP: Virtualisering og Open Source Software 1) Hardware Kendt så det kan drives centralt over SDN 2) Virtualiseringssoftware Så vi fra SDSD kan konfigurere og ændre efter igangsættelse 3) Applikations server a. Så tekniske services (SOSI komponenter mm.) kan afvikles b. Så "lette" sundhedsservices som CPR check mm. kan placeres på NSP i fremtiden 4) Kommunikations bus Så svar til/fra eksterne services (som FMK) kan opbevares 16