Skal sikre en aktiv national koordinering af Sundheds‐it
‐
Skal bidrage til sammenhængende og effektive it‐løsninger på
sundhedsområdet
National Sundheds‐it
NSI
Sundhedsvæsenet Koncernen
Økonomi aftaler
Bestyrelse for sundheds‐it
Operations styregruppe
Departement chef/ISM
NSI
Sundhedsvæsenet Koncernen
Regioner/
Sygehuse
Praktiserende læger
Kommuner
Tandlæger
Privathospitaler
Forsvaret
Speciallæger
Vagtlæger
mm.
Seruminstituttet
Lægemiddel‐
styrelsen
Sundheds‐
styrelsen
Patientombud
Sundheds‐
ministeriet
NSI Registre
Sundhedsservices
Fælles Medicinkort
PEM/CTR/
Receptserver Vaccinations‐
register
Nationalt Patientindeks Epsos
SEI
National Infrastruktur
SEB
Sundhedsvæsenets organisations‐
register (SOR) National
serviceplatform
Landspatient‐
register
Dødsårsags‐
register
Andre registre
NSP 2.0
National Service Platform
‐ Ny vin i gammel flaske
en platform til webservice kommunikation
en platform til datadistribution
Sundhedsdatanettet 2.0 (2010)
Den hellige gral
Kontrol (over infrastrukturen og it‐generelt)
Mindre bøvl (eller nem‐SOA) Hurtigere respons
Stabil i toppen, fleksibel i bunden
Internet+VPN MPLS
Lokalt netværk (2008) Fag‐
system
Fag‐
system
Fag‐
system
Fag‐
system
Fag‐
system Nationale ServicePlatform 2.0 (2011)
Identitets kort Lagring (kopi data) Routning og mapning
Nam Nam jordbær‐creme
under‐
støtter
National arkitektur og
standarder på sundhedsområdet Sundhedsvæsnets
forretningsmål
understøtter
ramme for
Sundheds‐IT udvikling & drift
understøtter overholder
Internationale
& nationale referencer
Standarder Arkitektur
Løsningsarkitektur System = NSP
følger
ramme for Ud‐
peger
Standarder er grundlag for NSP
Fremadrettet mere fastsætte standarder(krav) frem for at bidrage med infrastruktur, der letter overholdelse af standarderne
forestå udmøntning af konkrete tværgående
sundheds‐it initiativer efter aftale (udvikle på NSP
☺)
Standarder alene kan give sikkerhed, men IKKE SLA garanti
Løsnings arkitektur Arkitektur
Anvendelse Teknologi Grundlag
G1 G2
T1 T2 T3 T4
A1 A2 A3 A4 A5 A6
L2 L3
understøtter
L1 L1 L1
HVOR GENERISK ER ARKITEKTUREN SPECIFIK GENEREL
Standarder Klassifikation Profiler
Data std.
Snitflade std.
Arkitektur
Referencearkitektu rer for bestemte områder
Referencemodeller Procesbeskrivelse (inkl. use‐cases) Tjenestekatalog
Ud‐
peger
HER
NSI rapport og std. katalog
For at skabe overblik over den ”nye” arbejdsform
Rapport der positionere standarder og fremhæver
behov for arkitektur – i høring pt. (se www.nsi.dk)
Formål og interessenter
Kataloget skal understøtte NSI med at koordinere den samlede standardiseringsindsats – herunder sikre sammenhæng i standarder (give overblik)
Kataloget skal understøtte de parter som udarbejder og vedligeholder standarder
(tydeliggøre afhængigheder af andre standarder)
Kataloget skal understøtte systemejere og leverandører med at skabe sammenhængende systemer (angive hvilke
standarder der er gældende på hvilke områder)
Kataloget skal synliggøre områdets grad af standardisering overfor borgere, politikere, Rigsrevisionen med flere
Hvad indeholder kataloget nu
16 referencemodeller 41 klassifikationer 36 rammestandarder / profiler
318 snitfladestandarder / specifikationer (bl.a.
blanketter) 22 andet
(vejledninger etc.) I alt 433 produkter
Referencearkitektur for NSP
Er en logisk arkitektur med 4 hovedkategorier:
‐ Dataregistrering (med klassifikationer)
‐ Forretning
‐ Indberetning
‐ Støtte
Fundamentet er etableret:
FMK services og Platform Vi mangler
data‐arkitektur og services for resten af
verden
NSP1.0 = Der er anlagt veje, el‐forsyning og kloarkering, men kun bygget ét hus. Får vi en by? – Det håber vi = NSP2.0!
NSP: Indbygget ROBUSTHED
NSP bygget med 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
12
Løsningsarkitektur hvor robusthed er ”by design”
Alt hardware er dubleret
Alt software er dubleret på tværs af hardware og kan klare sig alene
NSP
Søjle 1
Søjle
… n Søjle
Load balancer App. serv.
App. serv.
Database Database
Disk Disk Netværk Netværk
Diverse monitorerings og log‐komponenter
NSP: Central vs. Distribueret
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
Central kan ikke optimere sikkerhed
For at gøre det skal NSP stå lokalt
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 konsument
Robust overfor udfald af SDN
Lokal data: leveret hurtigere end lyset
13
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
2 omstillinger:
En i firmaet En til landet
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
NSP udvidelse
Et infrastrukturprojekt under NSI
Etablerer version 1.2, 1.5 og 2.0 af NSP’en Etablerer central(e) NSP(’er)
Dosis SOR TAKST
YDER
AUT
REF HOST
LPR
NSP 2.0
Koncept og Platform
SSR
CPR SIK DoDi
Behandlingsrelation (1) Behandlingsrelation (1) Opfølgning (Spor 2) Opfølgning (Spor 2)
Notar Notar
SOSI‐STS SOSI‐STS
Stamdata Stamdata
NSP‐roadmap
Den nationale serviceplatform er ikke statisk og den vil hele tiden blive opdateret med nye
services.
For at give overblik over hvilke services der
allerede er realiseret og hvilke services man kan forvente at blive tilbudt på den nationale
serviceplatform (NSP) de næste ca. 12 måneder, findes der et NSP‐roadmap.
Til NSP‐roadmap findes der et NSP‐
servicekatalog, der indeholder Produktkort, som
kan bruges til reference og opslag.
NSP Produkter / Services
NSP Programplan
2009 2010 2011 2012
v1 V1.2 V1.5 V2 V2.1
OIO-IDWS 1.0 OIO-XML
OIO-WSDL
SAML 2.0
WSDL XML/XSD WS-Trust
XML Signature
WS-Security WS-
Addressing
Danish specifications International specifications
OIOIDWS for Healthcare
Liberty Alliance XML Encryption
Liberty Basic SOAP
Binding
SOAP 1.1 HTTP(S)
OCES X509
Standarder på NSP
Mange ”niveauer” af standarder
Identifikation/Autenticitetssikring SOSI mod DGWS 1.0.1 (ANBEFALET)
”Sessioner” og ”Rettigheder” er på vej OIO‐IDWS‐H (OBSERVERES)
Kontekstdeling HL7 CCOW (OBS.)
Release 3.0
NSP på vej i skyerne
Almindelige skyer (Cloud computing) er ikke mere robuste end det internettet, der når
”derop”!
Virtualiseres på lokal hardware, som trækker på skyen: Her vil netudfald, kun resultere i en ydelses nedgang!
Målet for NSP på sigt!
Eftertanke: Alle vil have én..
…forskellig Serviceplatform Kombit
Samme mål som NSI om fleksibilitet og kvalitet
Går efter kommerciel løsning. Vil kunne køb support
Finansministeriet
Lancerer ønsker om robusthed under titlen ”Datafordeler”
Forventer ”Cloud” løser robusthed ved udflytning af eksisterende systemer.
Ingen konsolidering/ensretning/arkitektur.
Politi
Ønsker af konsolidere flere forskellige driftsplatforme
I venteposition pt.
Konklusion
God open source infrastruktur, sælger ikke sig selv!
Behov for tung DOKUMENTATION: Rapporter, Manualer, arkitektur og driftdokumentation.
