Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

DEN NATIONALE SERVICEPLATFORM (NSP) TEMAMØDE OM SUNDHEDSDATANETTET 26. Oktober 2015 Rikke Saltoft Andersen (NSI), Henrik Rikard (CapGemini), Ivan Lund.

Lignende præsentationer


Præsentationer af emnet: "DEN NATIONALE SERVICEPLATFORM (NSP) TEMAMØDE OM SUNDHEDSDATANETTET 26. Oktober 2015 Rikke Saltoft Andersen (NSI), Henrik Rikard (CapGemini), Ivan Lund."— Præsentationens transcript:

1 DEN NATIONALE SERVICEPLATFORM (NSP) TEMAMØDE OM SUNDHEDSDATANETTET 26. Oktober 2015 Rikke Saltoft Andersen (NSI), Henrik Rikard (CapGemini), Ivan Lund Pedersen, (NSI)

2 HVAD ER NSP? 2 Anvender- systemer Leverandør NSP Service udbydere ServiceaftaleTilslutningsaftale ServicemålForretningsservice Ét nationalt koncept! Én adgang til mange services Én sikkerhedsmodel Én overvågning Én indgang til driftsstatus og trafiktælling: www.NSPOP.dk Én National Servicedesk -> 2nd. Line Én åbningstid -> 24/7/365

3 Hvorfor NSP ? Leverandører af services og stamdata Aftagere af services og stamdata Leverandører af services og stamdata Aftagere af services og stamdata NSP

4 DISTRIBUERET MODEL Reg.Nord dNSP Reg.Midt dNSP Reg.Syd dNSP Reg.H dNSP Reg.Sj. dNSP cNSP kommuner Sundhed. dk NSP back office

5 TILGÆNGELIGE SERVICES Services og registre der er i drift (grønne) og de services der endnu ikke er tilgængelige på NSP (grå) Sundhedsdatanettet NSP National Serviceplatform Ministeriet for Sundhed og Forebyggelse Økonomi- og Indenrigs ministeriet Kirkeministeriet FMK DDV ECPR Regi ster CPR Fødsels indberetning Regioner Kommuner Stat Private Aftagere FORRETNINGS SERVICES STØTTESERVICES Afkobling (DCC) Opsamling (GOS) Dokumentdeling (DDS) Samtykke Security Token Service (STS) Bemyndigelse Advisering (NAS) Token Cache (GW) Behandlings- relation (BRS) MinLog Testmiljøer Vaccinations- register (DDV) Fælles medicinkort (FMK) Bivirknings- indberetning (BIV) Fødselsind- beretning (FIBS) Stamdata (STM) Erstatnings-CPR- nummer (ECPR) Regi ster ….….

6 TRAFIK PÅ NSP Månedsvis udvikling – antal kald til NSP instanser: >30 mio. (juni 2015) NSP: Høj oppetid! (SLA ift. tilgængelighed 99,8%) 20132024 2015 mar-dec.Q1Q2Q3Q4Q1Q2 99,9999,9299,9799,9100

7 REVIEW AF NSP Styrker v. NSP Ros for vellykket SOA-arkitektur, høj grad af modificerbarhed og skalerbarhed Fornuftige arkitektur og teknologivalg - fit for purpose anno 2015, god robusthed Solidt sikkerhedsmæssigt set up for udstedelse af SOSI-ID-kort- (teknologi og processer: Best Practice) Driftssikker infrastruktur – høje oppetider, få servicedesk sager Ros for velfungerende multipart-leverandør-samarb. Udviklingsområder Gateway skal gen-vurderes mhp. at sikre max-skaleringsbehov Opdateringsbehov: Standarden Den Gode Webservice – som bl.a. NSP baserer sig på Dokumentationen skal forbedres: sikre opdatering, teknisk retvisende og forståelig information samt tilgodese interessent-overblik (www.nspop.dk). Governance forbedres: øge gennemsigtighed, interessent-inddragelse, flerårige bevillinger & roadmap, business relation management-rollen opprioriteres

8 Nationale service – Teknisk Tilslutning (NSP) v/ Henrik Rikard, NSI Operatør, Capgemini 26. Oktober 2015 Hvordan kommer man på Test og Produktion? Adgangskontrol, Certifikater og nødvendige aftaler? Hvem henvender man sig til vedr. adgang?

9 Mit udgangspunkt! Erfaren tekniker Drift vs. Udvikling Support- og overvågning vs. test 9

10 © Capgemini Sogeti NSP Operatør Komponent leverandører Ejer Service udbydere: Økonomi- og erhvervs- ministeriet Sundheds- og ældre ministeriet Kirke- mini- steriet Service aftagere: Regioner LPS’er Kommuner Privat- hospitaler NSP Leverandør / applikationssupport NSP Driftsleverandør/ 24/7 Servicedesk 10

11 11 Tekniske krav til at anvende (services via) NSP i produktion er: 1.Du har adgang til en klient (et program) via et system, som kan få forbindelse til NSP, for eksempel en EPJ-klient (region) eller en EOJ-klient (kommune) 2.Din organisation har netværks adgang til Sundhedsdatanettet (SDN) 3.Din organisation anvender OCES-certifikater til at identificere og give adgang til system og for nogle services også brugere 4.For adgang til TEST gælder samme krav som til PROD, med undtagelse af krav om anvendelse af (SDN), og krav om anvendelse af specielle TEST certifikater udstedt af NETS. Links til NSPOP Som Anvender: AnvenderAnvender Som Leverandør: LeverandørLeverandør Fælles Testmiljøer: Test miljøerTest miljøer Hvordan kommer man på NSP?

12 12 Adgangskontrol til Services: Til brug for adgangskontrol anvendes OCES-certifikat level 3 (Virksomheds- og Funktionscertifikater). Der anvendes whitelistning til adgangskontrol til services og blacklistning af adgang via CRL’er udstedt af NETS. Aftaletype beskrivelse og Aftaleoversigt: AftaletyperAftaletyper AftaleoversigtAftaleoversigt Adgang til Testsystemer: Anmodning om Test Anmodning om Test "Kom godt i gang guider” "Kom godt i gang guider” Online Testmiljøer NSP+In+A+BoxOnline TestmiljøerNSP+In+A+Box Bestilling af adgang til services i Produktion: Bestilling til PROD Bestilling til PROD Ny Aftaleoversigt (kræver login) : Aftaleoversigt Aftaleoversigt Whitelistning, Certifikater og Aftaleoversigt?

13 Ét nationalt koncept! 13 Kunde Eks. Region Leverandør NSP Service udbydere Eks. FMK ServiceaftaleTilslutningsaftale ServicemålForretningsservice

14 14 Hvem henvender man sig til? Ved alle henvendelser vedr. adgang til NSP platformen er der kun 1 indgang, og det er oprettelse af supportsag her: Servicedesk – indberetning

15 MODNING AF SAMTYKKE OG DOKUMENTDELINGS SERVICES 26. Oktober 2015 Præsentation på SDN temadag Ivan Pedersen NSI

16 HOVEDPUNKTER FOR DE NÆSTE 15-20 MINUTTER Baggrund for services og modningen af dem Præsentation af Samtykke og Dokument delings service Modningsprojektet -Hovedaktiviteter -Muligheder for deltagelse Spørgsmål

17 HVORFOR DOKUMENTDELING OG SAMTYKKE SERVICES PÅ NSP’EN? En forudsætning for at kunne overkomme og følge anbefalingerne fra reference arkitekturerne

18

19 ARGUMENTER ”BAG” DE TO REF. ARKITEKTURER (1) It-anvendelsen i sundhedsvæsenet er ved at flytte sig fra den enkelte parts anvendelse af egne data til anvendelse af data opsamlet ved forskellige parter i væsenet. Sikkerhedsmodellen for anvendelse af data på tværs af parter er ikke blot summen af parternes sikkerhedsmodeller. Forskelle i sikkerhedsmodeller gør det vanskeligt at skabe sammenhængende løsninger. Informationssikkerhed og Privacy er ikke blevet mindre aktuelt de sidste 2 år!

20 ARGUMENTER ”BAG” DE TO REF. ARKITEKTURER (2)

21 ARGUMENTER ”BAG” DE TO REF. ARKITEKTURER (3) Sundhedspersoner med samme arbejdsfunktion og relation til patienten får adgang til de samme data (uafhængigt af behandlingssted) Den viden borgeren har om eget behandlingsforløb og den personlige interesse borgeren har i at påvirke informationsstrømmen og sikre berettiget adgang til personlige oplysninger udnyttes

22 ANBEFALINGER OG KONSEKVENS AF REF. ARK. FOR DELING AF BILLEDER OG DOKUMENTER Referencearkitekturens hovedanbefaling: -at man arkitekturmæssigt baserer sig på IHE standarder og profiler, som sikrer, at referencearkitekturen også kan indgå i en international sammenhæng. -På det nationale plan indebærer det, at der på nationalt plan etableres to domæner: et statsligt og et fælles regionalt, som på sigt kan suppleres med et fælles kommunalt. -I det lokale perspektiv skal det være muligt at opbygge sine egne domæner, f.eks. inden for en region, men såfremt man ønsker at kunne udstille dokumenter og billeder herfra, skal man kobles op på et af de nationale domæner og leve op til de nationale standarder, der er fastlagt for disse. Konsekvens: -at der kan etableres dokumentlagre på tværs af sundhedsvæsenet, hvor det med anvendelse af fælles standardiserede metadata bliver muligt at fremsøge dokumenter på tværs af systemer og organisationer, uden at der skal være en tæt kobling (integration) mellem de it-løsninger, der anvendes af brugerne. -Referencearkitekturen gør det muligt løbende at gøre data fra eksisterende systemer tilgængelige som dokumenter med tilhørende metadata. Et eksisterende system kan således bringes i overensstemmelse med referencearkitekturen uden en grundlæggende ændring af selve systemet.

23 ANBEFALINGER FRA REFERENCE ARKITEKTUREN FOR INFORMATIONS SIKKERHED (SEPT. 2013) At der arbejdes efter en sikkerhedsmodel, der såvel tillader fælles sikkerhedsløsninger ved betroet tredjepart, som individuelle sikkerhedsløsninger mellem parter, der gensidigt har tillid til hinanden At tillid parterne imellem baseres på aftaler, som lever op til en række fastsatte krav / standarder At der styres ud fra standardiseret information om: -borgere og sundhedspersoner, organisatoriske enheder, ansættelsesforhold og arbejdsfunktioner, autenticitetsstyrke (sikkerhed for fastslået identitet af brugere og systemer), styrke for evidens af behandlingsrelation, Samtykke, Begrundelser for brug af værdispringsregel m.v. Referencearkitekturen peger på at ensrette de sikkerhedsmodeller, der arbejdes med i dag – ikke at beskrive helt nye og alternative sikkerhedsmodeller. Nogle af principperne række dog længere. Dette skulle gerne åbne muligheden for på sigt at flytte sig over i nyere sikkerhedsmodeller efterhånden som disse modnes og der findes praktiske implementeringer af dem.

24 ”FAMILIEN” AF SIKKERHEDS OG DELINGS SERVICES PÅ NATIONALE SERVICE PLATFORM I forsøget på at skabe en fælles og ensartet sikkerhedsmodel samt lette ibrugtagningen af dokumentdeling er følgende servicefamilie ”opfundet”: -Dokumentdelings service (DDS) =en proxy XDS service varetager ”gabet” mellem internationale XDS profiler og specifkke danske krav Gør det nemmere at implementere markedets XDS produkter -Samtykke service (SS) = borgerens styring af data videregivelses Giver patienten et værktøj til at styre videregivelse af data til fagprofessionelle – en lovmæssig ret Mulighed for at foretage værdispring – en lovmæssig ret -MinLog service (ML) = gennemsigtighed i opslag på data en fælles mulighed for at kommunikere logoplysninger -Behandlings relations service (BRS) = en hjælp til logopfølgning Fokus på mistænkelige opslag Færre ressourcer på logopfølgningen

25 SIKKERHEDS FAMILIEN OG DOKUMENTDELING NSP Opf. Min-Log NSP Database (kopi) Samtykke STS BRS DDS service [ITI-18][ITI-43][ITI-61] ”Servicefamilien” kan nås direkte eller via Dokumentdelingsservice

26 HVORFOR MODNING AF DOKUMENTDELING OG SAMTYKKE SERVICES? Samtykke og Dokumentdelings service er gamle! -Udviklet i 2012 som led i NPI projektet ud fra krav/anbefalinger fra referencearkitekturer, samtidigt med MinLog og BRS services. -Bestået 3 tekniske afprøvninger 2012 NPI demo projektet (Columna, Miba, Sårjournalen) 2013 End2End projektet sammen med Alexandra instituttet (Columna, Net4Care, MS-repository, OpenTele) 2014 Initiativ 1.4 spor 2 adgang fra fagsystem til KIH (KIH-DB,SDK, CSC) Men der mangler stor skala test og TRL dokumentation Nu efterspørger 3 konkrete projekter disse services til idriftsættelse sommer 2016 -Telemedicin modning, Sundhedsjournal 2.0 og FMK

27 TECHNOLOGY READINESS LEVELS

28 DOKUMENT DELINGS SERVICE virkemåde

29 IHE XDS AKTØR-INTERAKTION (ITI-41) ITI-42 ITI-43 (RAD-69) ITI-43 ITI-18 ITI-61 (ITI-41) DDS på NSP

30 X- DBKIH-DB Sikkerhedsservices (STS, BRS, GOS, SamT, Mlog.) DDS Services Indeks 43+ 61/42+ 43++ Anvender 2 Lokalt Servicelag Lokalt Servicelag Fælles nationalt domæne Anvender systemer ”Modtager” af data Infrastruktur – NSP, XDS reg. Kilder. ”Data- producenter” Signaturforklaring: 2. 18++ - IHE XDS profilen ”Registry Stored Query” tilpasset den gode webservice + HSUID 3. 43++ - IHE XDS profilen ”Retrieve Document set” der er tilpasset ”Den gode webservice”, HSUID og integreret med opslag og filtrering vha. sikkerhedsservices på NSP 4. 43+ - IHE XDS profilen ” Retrieve Document set” der er tilpasset ”Den gode webservice” 1. 61/42+ - Fælles service som håndterer upload af metadata vha. IHE XDS profilen ”Registre on- demand Document Entry” og IHE XDS profilen ”Registre Document Set”. Begge overholder den gode webservice. Anvender 1 18++

31 DOKUMENT DELINGS SERVICES SET FRA EN ANVENDER NSP Dokumentdelingsservices (Proxy) Dokumentdelingsservices (Proxy) ITI-18++ IHE XDS FindDocument med DGWS og HSUID XDS Consumer Anvender PHMR PDF ITI-43++ IHE XDS Retrieve Document med Samtykkekontrol, DGWS og HSUID META DATA MODEL

32 KRAV TIL EN ANVENDER DGWS 1.0.1 -SOSI ID kort på niveau 4 -[Kan undtagelsesvist whitelistes til niveau 3] Healthcare Service User Identification (HSUID) Header: -Nødvendige oplysninger for at: Verificere behandlingsrelation Verificere samtykke Logge i borgerens log -Omfatter blandt andet: CPR på bruger CPR på ansvarlig bruger Autorisationsid på ansvarlig bruger Binær data til/fra web-services (MTOM)

33 HJÆLPEBIBLIOTEKER FRA NSI Hjælpebiblioteker i Java og C#: -For dokumentanvendere (link) Håndterer: -DWGS -HSUID -XDS snitfladen -MTOM -SOAP version Men kræver stadig de samme informationer!

34 SAMTYKKE SERVICE virkemåde

35 BAGGRUND FOR SAMTYKKE SERVICE Sundhedsloven indeholder bestemmelser om, at borgeren har ret til at frabede sig indhentning eller videregivelse af oplysninger. I relation til elektronisk indhentning af patientoplysninger skal patienten være orienteret om sin ret til at frabede sig indhentning, men der er ikke krav om, at man ved den konkrete indhentning skal udbede sig patientens samtykke. I bemærkningerne til loven er det angivet, at denne ret ved nye it- løsninger skal understøttes elektronisk, dvs. at patienten selv eller en sundhedsperson på patientens vegne skal kunne markere, hvilke oplysninger, man frabeder sig indsigt i.

36 DEN HELT SIMPLE VERSION Samtykke servicen fungerer som ”dørmand” for ”omverdenens” adgang til data. Samtykke servicen skal ses af kilderne som en hjælpe til at overholde lovens intentioner og som en måde at uddelegere kildens dataansvar. Hvem må se? (fagpers. & org.) Hvad må vises? (perioder, org.) Patientens samtykker + eller – Og varighed

37 SAMTYKKE ADMINISTRATION ConsentRegistrationsGet – Returnerer alle samtykkeregistreringer for en borger. ConsentAdd – Opretter et nyt samtykke for en borger. ConsentModify – Ændrer et samtykke for en borger. Samtykket/ændringer er angivet som for nye samtykker. ConsentRevoke – Trækker et samtykke tilbage, så det ikke længere er gyldigt.

38 SAMTYKKE VERIFIKATION ConsentForUserCheck – Returnerer det generelle samtykkeforhold for en bruger i forhold til en borger; om brugeren må se alt eller intet om borgeren. ConsentForDataCheck – Returner de specifikke samtykkeforhold for en bruger og konkrete oplysninger i forhold til en borger; om brugeren må se disse konkrete oplysninger om borgeren. ConsentForForeignersCheck – Returner om udenlandske sundhedsprofessionelle har adgang til Patient Summary og Electronic Prescription for borgeren gennem epSos

39 SAMTYKKE VERIFIKATION FOR PRIVATPERSON/BORGER Samtykkeverifikationsservicen følger følgende beslutningsgraf for at afgøre en borgers/sundhedspersons adgang til data

40 SAMTYKKE VERIFIKATION FOR SUNDHEDS PROFESSIONEL Samtykkeverifikationsservicen følger følgende beslutningsgraf for at afgøre en borgers/ sundhedspersons adgang til data

41 DEN HELT SIMPLE VERSION Hvem må se? (fagpers. & org.) Hvad må vises? (perioder, org.) Patientens samtykker + eller – Og varighed WHOITEM tabel CONSENTITEM tabel WHATITEM tabel

42 CONSENTITEM TABEL DATA I ET SAMTYKKE FeltTypeAnvendelse citizenCprStreng Identiteten på den borger (cpr-nummer) samtykket vedrører, skal være defineret consentTypeHeltal Typen af samtykket, 0=negativt, øvrige=positivt, skal være defineret whatItemFremmed nøgleReference til whatItem tabellen. Null = alt whoItemFremmed nøgleReference til whoItem tabellen. Null = alle validFromTidsstempel Tidspunktet fra hvilket samtykket er/var gældende, skal være defineret. Gemmes som UTC-tidsstempel. validToTidsstempel Tidspunktet indtil hvilket samtykket er/var gældende. Null = intet udløbstidspunkt. Gemmes som UTC-tidsstempel. creationTimestampTidsstempel Tidspunktet hvor samtykket blev oprettet. Gemmes som UTC-tidsstempel. creatingSystemNameStreng Navnet på det system, igennem hvilket samtykket blev oprettet (som angivet i HSUID-headeren kortet ved webservice-kaldet til samtykke service) createdByStreng Identiteten på den bruger, som oprettede samtykket (som angivet i HSUID-headeren ved webservice-kaldet til samtykke service) modifyTimestampTidsstempel Tidspunktet hvor samtykket senest blev ændret. Gemmes som UTC-tidsstempel. modifyingSystemNameStreng Navnet på det system, igennem hvilket samtykket senest blev ændret (som angivet i HSUID-headeren kortet ved webservice-kaldet til samtykke service) modifiedByStreng Identiteten på den bruger, som senest ændrede samtykket (som angivet i HSUID-headeren ved webservice-kaldet til samtykke service)

43 WHATITEM TABELLEN - HVILKE DATA OMFATTER SAMTYKKET? FeltTypeAnvendelse organizationIdentifierStreng Identiteten af den afdeling (SOR-koden) fra hvilken oplysningerne er omfattet af samtykket. Null = alle afdelinger IncludeSubOrgsTRUE/ FALSE Angiver om samtykket udelukkende gælder for den angivne afdeling (FALSE) eller om samtykket gælder for alle afdelinger, som hierarkisk er underordnet den angivne afdeling (TRUE) referralStartTidsstempel Angiver tidspunktet fra hvilket oplysninger fra den angivne afdeling (evt. med underafdelinger) er omfattet af samtykket, skal være defineret. Null = intet afgrænsende starttidspunkt. Gemmes som UTC-tidsstempel. referralEndTidsstempel Angiver tidspunktet indtil hvilket oplysninger fra den angivne afdeling (evt. med underafdelinger) er omfattet af samtykket, skal være defineret. Null = intet afgrænsende sluttidspunkt. Gemmes som UTC-tidsstempel.

44 WHOITEM TABELLEN - HVEM MÅ ELLER MÅ IKKE SE? FeltTypeAnvendelse healthProfessionalCprStreng Identiteten på den sundhedsperson (cpr-nummer) samtykket gives til (positivt samtykke) eller gives imod (negativt samtykke). null = alle sundhedspersoner organizationIdentifierStreng Identiteten af den afdeling (SOR-koden) samtykket gives til (positivt samtykke). Null = alle afdelinger IncludeSubOrgsTRUE/ FALSE Angiver om samtykket udelukkende gives til den angivne afdeling (FALSE) eller om samtykket gives til alle afdelinger, som hierarkisk er underordnet den angivne afdeling (TRUE) foreignHealthProfessio nals TRUE/ FALSE Angiver at der er givet samtykke til at epSos kan videregive sundhedsoplysninger til udenlandske sundhedsprofessionelle. Hvilke informationer, som videregives, fastlægges af epSos.

45 DE FORVENTEDE PATIENTTYPER Forventede patienttyper: 1.Den ubevidste og udbekymrede gennemsnits dansker der ikke tænker over sikkerhed og som derfor ikke opretter nogen samtykker (”alle må se alt” ) 2.Den permanent meget bekymrede patient som ønsker at spærrer for alt (”universel nægtet videregivelse af data”) 3.Den bekymrede som ønsker at dele NOGET til NOGLE i en PERIODE Han har et generelt negativt samtykke liggende, men åbner for nogle data i afgrænsede perioder til udvalgte enheder/personer fx ifm. en henvisning eller indlæggelse (”punktvis videregivelse af data”) 4.Den ubekymrede patient som har et par hemmeligheder fx ønsker at skjule Hun opretter et negativt samtykke rettet mod en bestemt organisation og et bestemt periode (”punktvis nægtet videregivelse af data”) 5.Den ubekymrede patient som ønsker at skærme for indblik i sine data fra bestemte personer/afdelinger fx patientens eksmand må ikke se (”punktvis nægtet organisatorisk indblik”) Samtykke servicen kan understøtte alle 5 patient scenarier inkl. værdispring MEN Samtykke servicen kan ikke skjule bestemte typer af data eller data fra bestemte kilder (som den er designet nu) fx: -Lab. Svar ud fra upac koder eller notater ud fra diagnoser etc. eller -Spærring af alt fra e-journal

46 MODNINGSPROJEKTET

47 MODNING AF INFRASTRUKTUR Som led i ØA2016 er det aftalt at Medcom og NSI skal gennemføre et modningsprojekt frem til sommer 2016. Modningsprojektet er et såkaldt ”forudsætningsprojekt” i det samlede Program for nationale udbredelse af telemedicinsk hjemmemonitorering til borgere med KOL. (Landdelsprogrammerne) Aftalen beskrives i 5 spor: -Modning af standarderne -Modning af NSP services – Dokumentdeling, Samtykke, MinLog, BRS service bringes op på TRL5 til TRL8 -Modning af KIH databasen On-demand XDS snitflade PHMR med spørgeskemaer Sikkerhedsanalyse ift. brug af NSP services Driftklargøring ift. Dokumentation, log og statistik -Integrationer, brugertest, pilot -Modning af Open-tele

48 FASER SPOR I MODNINGSPROJEKTET Fase 1 - Initiering Fase 2 - Udvikling og tests Spor 1 - Nationale arkitekturopgaver Spor 2 - Use Cases og analyser Spor 3 - KIH Udviklingsaktiviteter Spor 4 - Forberedelse af pilotdrift Spor 5 - Performancetests Spor 6 - KIH Driftsmiljøer Spor 7 - Samtykke GUI (SDK) Spor 8 - Indeks udbud Spor 9 - Connectathon Fase 3 - Pilotdrift Fase 4 - Projektafslutning

49 HVORNÅR RAMMER PROJEKTET JER? -MEST LEVERANDØRER Første bølge af integrationer og brugetest for anvendersystemer – januar/februar 2016 -Aftaler forventes indgået i december 2015 -Hold jer ikke tilbage Anden bølge af integrationer og brugetest for anvendersystemer – marts – maj 2016 -Aftaler forventes indgået i februar 2016

50 SPØRGSMÅL ?


Download ppt "DEN NATIONALE SERVICEPLATFORM (NSP) TEMAMØDE OM SUNDHEDSDATANETTET 26. Oktober 2015 Rikke Saltoft Andersen (NSI), Henrik Rikard (CapGemini), Ivan Lund."

Lignende præsentationer


Annoncer fra Google