Embed Size (px)
Citation preview
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: FMK2
Fælles Medicinkort• afspejler borgerens aktuelle medicinering, og
deles af alle parter gennem de forskellige it-systemer
APOTEKINSTITUTIONER OG
PLEJEHJEM
PRAKTISERENDE
LÆGE
VAGTLÆGE
SPECIAL LÆGE
HJEMMESYGEPLEJE
BORGER SYGEHUS
NU situationenFRA at sendedata
NU situationenFRA at sendedata
Paradigme skiftTIL af dele dataParadigme skiftTIL af dele data
APOTEKINSTITUTIONER OG
PLEJEHJEM
PRAKTISERENDE LÆGE
VAGTLÆGE
SPECIAL LÆGE
HJEMMESYGEPLEJE
BORGER SYGEHUS
3
Et forenklet billede af ”NU”
B
B
B
BB
B
B
B
B
B
B
B
B
B
B
B
Aktør A Aktør B
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 (Betaling pr. besked til leverendør)
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
Illustration af den nationale sundheds-it-infrastruktur
Journal data og servicesServiceenablede statiske registre
Organisa-tionsregistre
(SOR, yderreg.)
Kliniskesystemer (EPJ)
Klinikere Hospitals-
kliniker
Laboratorie Systemer
Laboratorie-kliniker
Omsorgs- og genoptrænings-
systemer
Kommunalt plejepersonale
Praksis-systemer
Praktiserende læge
NSPDriftsmiljø for fælles komponenter
Kommunikationsbus
Std-planer og kliniske
vejledninger
Autorisations-register
Patient/Borger (CPR)
Terminologi klassifikation
(SNOMED/SKS)
Serviceenablede dynamiske registre
National Portal (Sundhed.dk)
RøntgenSystemer
Røntgen-kliniker
Værktøjskasse
Lokale sikkerheds-
komponenter
Kode-biblioteker
Serviceenablede dynamiske registre
Administration
Sygesikringsregister
Afregnings-Databank
(SDB)
Kvalitet og forskning
Patient-register (LPR)
Centrale tilskudsre-
gister (CTR)
Klin. DB (NIP)
Canserreg., dødsårsagsr
.…
.
Borgere
Støtteservices
NPI-Viewer
Sekundær dataanvendelse
Indberetnings-services
Notat Medicinering(FMK)
Billede-diagnostik(Røntgen,
EKG, CT/MR-Scan)
Udtræk til datavarehuse
Patient Indeks (NPI)
Logning og monitorering
Nationale sikkerheds-
services
Beregnings-services(DRG)
Laboratorie-svar
Planlægning og logistik
Henvisning og rekvisition
Booking Planer
Gateway
FMK og NSP
Brug af FMK kræver
sdksdksdk
sdksdksdk sdksdksdk sdksdksdk
• Krav til systemejere ved FMK udrulning:– Alle systemer, der skal tilgå FMK,
skal tilpasses*– Alle medarbejdere, der skal anvende
FMK, skal udstyres med digital-signatur (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
7
Introduktion af Gateway
• På kanten mellem to sikkerhedsdomæner
• Domæne 1– Sikkert og lukket net– Høj perimetersikkerhed– F.eks. backend servernet– Brugere og systemer er kendt i
domænet– Typisk DGWS niveau 1,2
• Domæne 2– Sundhedsdatanet (el. lign.)– Brugere 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 )
Domæne 2(fx Styrelse )
LOKAL SYSTEM
LOKAL SYSTEM
Service
Gatew
ayService (FMK)
Service
LOKAL SYSTEM
8
Visualisering af National Serviceplatform (NSP)
• Deployering lokalt (Vaskemaskine)–drift/ opdatering nationalt
• Minimumsmodel!!!
FMKsdn
STS
LOKAL SYSTEM
NSPSOSI-GW
SOSI-DCC
FMK
FMK
LOKAL SYSTEM
LOKAL SYSTEM
Indenfor regionsnet9
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) = Behov for højt kvalitet af drift og ydelse af HELE infrastrukturen
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
NSP og SDNLAN udødelighed og nem syst.adm.
PAS EPJ
Div.
LAN udødelighed og nem syst.adm.
PAS EPJDiv.
LAN udødelighed og nem syst.adm.
PAS EPJDiv.
LAN udødelighed og nem syst.adm.
PAS
EPJ Div.
LAN udødelighed og nem syst.adm.
PASEPJ
Div.
Central ogDe-central
EPJ
NSP skal sikre
• Bedre 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
Hvorfor for en CENTRAL NSP
NSP• Undgå distribution & kopi af
interaktionsekspertise på tværsaf 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?
NSPsvarer til
omstillingen
13
Hvorfor IKKE kun én central NSP
• Central 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
konsumentRobust overfor udfald af SDN
– Lokal data: leveret hurtigere end lyset• Central kan ikke optimere sikkerhed
– For at gøre det skal NSP stå lokalt14
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
NSP: Virtualisering og Open Source Software
1) HardwareKendt så det kan drives centralt over SDN
2) VirtualiseringssoftwareSå vi fra SDSD kan konfigurere og ændre efter igangsættelse
3) Applikations servera. Så tekniske services (SOSI komponenter mm.) kan afviklesb. Så "lette" sundhedsservices som CPR check mm. kan placeres på NSP i
fremtiden
4) Kommunikations busSå svar til/fra eksterne services (som FMK) kan opbevares
16
