Oplæg til National Kroniker Infrastruktur

Transkript

1 Oplæg til National Kroniker Infrastruktur Oplæg til teknik-gruppen i forbindelse med Fælles Kroniker Data MedCom og NSI Baggrund Der er startet en del kronikerprojekter i Danmark de fleste stadig på forsøgsbasis. I efteråret 2011 skulle Region Nordjylland have startet fuldskala kronikerprojekt med deltagelse af KOL patienter til realisering af RSI s pejlemærke vedr. et storskala kronikerprojekt 1. Planen var oprindeligt, at Region Nordjyllands kronikerprojekt skulle have afprøvet MedCom s Kroniker Datasæt (KD) version 0 og i samarbejde med RSI have afstukket rammerne for en national Kronikerplatform eller -knudepunkt. Projektet skulle ikke være ansvarligt for at bygge den nationale platform, men være med til at afstikke retningen, således at ikke alle kronikerprojekter fremover blev nødt til at etablere sin egen platform, som det vil være svært senere at konsolidere til én samlet platform. Tidsplanen for Region Nordjyllands projekt er imidlertid skredet, så det p.t. først skal være færdigt med udgangen af Og arbejdet med at definere en national Kronikerplatform så også ud til i hvert fald midlertidigt at være gået i stå. Da MedCom er en central spiller i alle igangværende kronikerprojekter og samtidig har erfaring med tværsektoralt samarbejde og infrastruktur besluttede MedCom i første omgang at gøre sig nogle overordnede tanker om en National Kroniker Infrastruktur, som nuværende og specielt fremtidige kronikerprojekter kunne koble sig på. Senest har Ministeriet for Sundhed og Forebyggelse offentliggjort igangsætning af projektet "Klinisk Integreret Hjemmemonitorering". Projektet indeholder 5 kliniske delprojekter, et teknisk delprojekt og et delprojekt vedr. evaluering. Ledelsen af det samlede projekt samt det tekniske delprojekt varetages af MedCom som en del af MedCom8-programmet 2. Nærværende oplæg bygger videre på det indledende arbejde, som blev lavet sammen med RSI og Region Nordjylland, og er MedCom og NSI s fælles skitse til en National Kroniker Infrastruktur. Forudsætninger 1 Se IT/RSI/Pejlem%C3%A6rker/~/media/RSI%20status/rsi%20portef%C3%B8lje%20juni%202011%20www.ashx 2 Se *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 1

2 Dette oplæg bygger på en række forudsætninger: Forudsætning Indgangen for borgere til den Nationale Kroniker Infrastruktur bliver sundhed.dk Den Nationale Kroniker Infrastruktur er databærende, men data skal så vidt muligt ligge hos sin ejer Den Nationale Kroniker Infrastruktur kommer til at omfatte såvel en databærende del som en udstiller af Services Den Nationale Kroniker Infrastruktur udstiller en Web Service, som kan levere hele Kroniker Datasættet (KD) Den Nationale Kroniker Infrastruktur udstiller fra starten andre interfaces end Web Services Den Nationale Kroniker Infrastruktur bliver landsdækkende Beskrivelse Indgangen for den enkelte borger til at se kroniker overblikket bliver sundhed.dk, som ligeledes bliver stedet, hvor borgerne skal indtaste supplerende oplysninger som f.eks. stamdata og dagbogsnotater En stor del af informationerne, som er defineret i Kroniker Datasættet (KD), eksisterer allerede i forskellige systemer, hvor dataejerskabet hører til (se Nationale Service Data). Disse data skal i videst muligt omfang forblive i deres respektive systemer, men kunne hentes på anfordring fra den Nationale Kroniker Infrastruktur. Da de eksisterende systemer er knyttet til de enkelte sektorer, og den National Kroniker Infrastruktur er tværsektoral, har andre oplysninger i dag (se øvrige KD Data) ikke noget naturligt sted at bo og vil derfor komme til at leve på selve den Nationale Kroniker Infrastruktur. Det drejer sig bl.a. om måledata og borgernes dagbogsnotater Såvel egne som andres data skal stilles til rådighed som Services Den Nationale Kroniker Infrastruktur vil udstille en Web Service, som kan sammenstille og returnere det fulde Kroniker Datasæt. Der vil være andre Services, som returnerer delmængder af det fulde Kroniker Datasæt Web Services vil formentlig blive den Nationale Kroniker Infrastrukturs foretrukne måde at udstille Services, men andre muligheder vil også komme på tale. Det vil f.eks. være tale om understøttelse af MedCom meddelelser for at sikre en glidende overgang for eksisterende systemer Den Nationale Kroniker Infrastruktur vil, når den er etableret, være den fælles platform for alle kronikerprojekter *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 2

3 Forudsætning Den Nationale Kroniker Infrastruktur bygger videre på nationale tiltag såsom den Nationale Service Platform (NSP) Den Nationale Kroniker Infrastruktur skal kunne sameksistere med såvel midlertidige løsninger, der bygges i de første kronikerprojekter, som samlede købeløsninger Beskrivelse NSP en indeholder elementer, som vil blive genbrugt i den Nationale Kroniker Infrastruktur herunder muligheden for at udstille Services, distribuere data (DoDi 3 ) og kommunikere via Sundhedsdatanettet (SDN). De eksisterende meddelelser er meget udbredte og stabile, så de vil komme til at co-eksistere i en periode Når den Nationale Kroniker Infrastruktur først er etableret, forventes den at blive brugt i alle fremtidige kronikerprojekter. Men da der allerede er (pilot) projekter på vej, som er nødt til at etablere deres egne platforme, og der findes private købeløsninger på markedet, som ligeledes afprøves (f.eks. i Region Syddanmark og Nordjylland), skal den Nationale Kroniker Infrastruktur kunne integreres til disse for at opfylde ambitionen om at kunne levere alle kronikerdata Tabel 1. Forudsætninger Den nationale Kroniker Infrastruktur Kroniker Datasættet (KD) En central funktionalitet for Den Nationale Kroniker Infrastruktur er, at den skal være i stand til at returnere det fulde Kroniker Datasæt (KD). Kroniker Datasættet består af følgende 15 data segmenter, hvor en del data skal hentes fra eksterne kilder: 3 Dataopsamlings- og Distributionsplatform. Et element i NSP infrastrukturen, der gør det muligt at opsamle og distribuere data til alle landets NSP instanser. Se bl.a. *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 3

4 CPR Service Yderregister LPR / Sundhedsjournalen DAK-E Labportal FMK / PEM C1 C2 C3 C4 C5 C6 Kronikerplatform Services Data C7 C8 Monitoreringsdata Figur 1. KronikerIndekset og eksterne kilder Data segment 1. Borgerens stamdata med borgerens og praktiserende læges navn, adresse og telefon Beskrivelse Hentes automatisk fra CPR- (C1) og Yderregisteret (C2) 2. Egen læges navn, adresse og telefon Hentes automatisk fra Yderregisteret (C2) 3. Pårørendes navn, adresse og telefon Indtastes af borgeren og lagres i KronikerIndekset (se senere) 4. Borgerens samtykke til at give adgang til kroniker data for kommune, læge og sygehus 5. Borgerens dagbog med egne oplevelser med sygdommen Indtastes af borgeren og lagres i KronikerIndekset (se senere) Indtastes af borgeren og lagres i KronikerIndekset (se senere) *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 4

5 Data segment 6. Praktiserende læges udredning med diagnose, sygehistorie, stratificering og henvisninger til sundheds- og forebyggelses tilbud. Mange patienter vil have flere kronikerdiagnoser (comorbilitet) 7. Kommune- og sygehuskontaktpersoner 8. Relevante diagnoser fra sygehuse og praksis 9. Relevante lab-svar fra sygehuse og praksis Beskrivelse Diagnoser og sygehistorie m.v. hentes automatisk fra DAK-E (C4). Henvisninger vil være registreret i KronikerIndekset (C7) (modtaget fra det lægefaglige system gennem en Service eller MedCom henvisning) Registreres i KronikerIndekset (se senere) Diagnoser hentes automatisk fra LPR (C3) og fra DAK-E (C4). Kronikerdiagnoser kan også være kommet til KronikerIndekset fra hospitaler og lægepraksissystemer som MedCom henvisninger Laboratoriesvar hentes automatisk fra Labportalen (C5) 10. Aktuel medicinering (FMK/PEM) Ordineret og udleveret medicin hentes automatisk fra FMK (C6) 11. Relevante SKL noter fra sygehus, kommune og almen praksis 12. Borgerens kalender der indeholder dato og tidspunkt for kommende lægebesøg, ambulatoriebesøg samt sundhedsfremme og forebyggelses tilbud 13. Booking af behandlings-, forebyggelses og rehabiliteringsydelser 14. Monitorerings data af f.eks. vægt, blodsukker, BT og spirometri og fremtidige data om funktionsniveau ifm. kommunal rehabilitering 15. Borgerens personlige mål for den fremtidige rehabilitering SKL noter er lagret i KronikerIndekset (C7) og er kommet via en Service eller som MedCom korrespondance meddelelser Borgerens kalender ligger i KronikerIndekset. Data fødes ud fra borgerens indtastninger på sundhed.dk og fra MedCom booking meddelelser Bestillinger ved udveksling af MedCom booking meddelelser og lagres i KronikerIndekset Monitoreringsdata lagres i KronikerIndekset (C7), eller de kan evt. hentes på anfordring fra diverse kronikerløsninger (SharedCare) via en standard snitflade (C8) Indtastes af borgeren og lagres i KronikerIndekset (se senere) Tabel 2. Kroniker Datasættets datasegmenter MedComs Kroniker Datasæt (KD) kan deles i tre dele: 1. NS Data er de data der hentes on-line fra de seks nationale services CPR, YNR, FMK, LPR, DAKe og LAB. De tre førstnævnte af disse services er i drift i dag, mens de sidstnævnte tre er på vej *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 5

6 2. KD MONI (hjemmemonitoreringsdata) planlægges første gang etableret ifm. de kommende KIH-projekter 4 3. KD EGNE er de resterende data i det fælles Kroniker Datasæt, dvs. borgerens egne data (pårørende, samtykke), SKL notater og kalender. Disse data lagres ingen steder i dag, men skal fremover ligge i KronikerIndekset KronikerIndeks og Infrastruktur Som det fremgår af ovenstående, skal den fremtidige infrastruktur for KronikerIndekset bestå af både en Data- og en Servicedel. Og NSI s infrastruktur med NSP og DoDi samt Sundhedsdatanettet spiller en stor rolle i forbindelse med at få alle delene til at spille sammen samt at distribuere og stille data til rådighed. Det giver således mening at snakke om en samlet National Kroniker Infrastruktur, som består af selve KronikerIndekset med sin Data- og Servicedel samt NSI s og MedComs (eksisterende) infrastruktur elementer: Figur 2. Den Nationale Kroniker Infrastruktur Af ovenstående figur fremgår, at selve KronikerIndekset dels består af en (endnu ikke defineret) Servicedel (ESB 5 ), som udstiller forskellige Services og dels af en Datadel (DB). Datadelen består 4 Klinisk Integreret Hjemmemonitorering 5 En Enterprise Service Bus er en integrationsplatform, som sikrer afkobling og stiller Services til rådighed. En ESB understøtter typisk gængse standarder (som f.eks. Web Services) og såvel synkron som asynkron kommunikation (via køer). Se bl.a. *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 6

7 af selve Data opdelt i monitoreringsdata (MONI - Data segment 15) og øvrige data, som ikke findes som nationale data (EGNE - Data segment 3, 4, 5, 7, 11, 12, 13 og 15). Den fulde infrastruktur består således ud over af KronikerIndekset af NSP en, forskellige nationale Services samt af Sundhedsdatanettet. Det fælles Kroniker Datasæt publiceres som en samlet Service vist med KD på figuren samt et ikke nærmere specificeret antal Services, som kan returnere delmængder af det samlede Kroniker Datasæt.. Servicedelen i KronikerIndekset skal udstille en række Services for udstilling og opdatering af de kronikerdata, som findes på datadelen. Oplægget for den kommende Nationale Kroniker Infrastruktur bygger på, hvad der allerede eksisterer af offentlig infrastruktur. Danske Regioner og RSI peger på Region Sjællands XDS baserede Billedindeks som kandidat til den databærende platform, men der udestår en nærmere analyse af de samlede krav, der skal stilles til KronikerIndekset. Udstilling af Services er en oplagt opgave for en form for Enterprise Service Bus (ESB), som kan udstille Services på en standardiseret måde og både understøtter synkron og asynkron kommunikation. Den Nationale Service Platform (NSP) indeholder en del af de elementer, der skal til for at løse Servicedelen, så nærværende oplæg til en arkitektur for en National Kroniker Infrastruktur bygger på NSP og Sundhedsdatanettet (SDN), som allerede er en del af den infrastruktur, som binder regioner og kommuner sammen. Oplæg til arkitektur med udgangspunkt i NSI og NSP Borgerregistrerede kronikerdata fra segmenter, som ifølge det foregående skal ligge i KronikerIndekset (EGNE), skal fødes via sundhed.dk, som også tænkes som portalen, hvor borgerne på linie med øvrige sundhedsoplysninger skal kunne se hele kroniker overblikket. Nedenstående figur viser, hvorledes oplysningerne kommer til KronikerIndekset. *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 7

8 Figur 3. Opdatering af Kronikerdata 1. Opdateringer sker via Sundhed.dk, hvis registreringen sker af en borger ellers via hhv. sygehussystemer (EPJ og PAS m.fl.), lægepraksis systemer eller kommuners elektroniske omsorgsjournal systemer (EOJ) 2. Sundhed.dk eller det faglige system kalder en opdaterings service på NSP en 3. Den kaldte Service på NSP er blot en proxy, som viderestiller kaldet til KronikerIndeksets Servicedel 4. Denne Service opdaterer kronikerdata i databasen (EGNE) Når kronikerdata f.eks. det fulde Kroniker Datasæt skal læses, foregår det som på nedenstående figur: *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 8

9 Figur 4. Læsning af kronikerdata 1. En borger eller en sundhedsperson ønsker at se kronikerdata 2. Sundhed.dk eller det faglige system kalder en Service på den lokale NSP 3. Denne Service henter selv alle de kronikerdata, som findes i den lokale database på NSP en (f.eks. CPR og YNR) 4. Øvrige oplysningerne hentes ved at kalde videre til Services i KronikerIndekset 5. Disse Services læser såvel monitorerings- som egne Kronikerdata fra Datadelen 6. Endelig kalder Servicen på NSP en den interne NS (Nationale Services), som indsamler de Nationale Service Data eksternt fra FMK, DAKe, LAB og LPR evt. ved brug af NPI 6 Integration til andre kronikerplatforme Igangværende kronikerprojekter vil være nødt til at bygge egne platforme, indtil der bliver leveret en national platform, alle projekter kan benytte. Men når den Nationale Kroniker Infrastruktur bliver etableret, bør den være i stand til at levere det samlede kroniker overblik indeholdende oplysninger fra alle eksisterende løsninger uanset om de er implementeret på den Nationale Kroniker Infrastruktur, er bygget som midlertidige løsninger, eller om de indkøbt som stand-alone systemer. 6 NPI: Det Nationale Patient Indeks, som p.t. er i NSI udbud *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 9

10 Derfor skal der bygges interfaces, så stand-alone løsninger enten kan levere data til den Nationale kroniker Infrastruktur på lige fod med andre fødesystemer, eller der skal bygges funktionalitet på den Nationale Kroniker Infrastruktur, så platformen kan indsamle oplysninger udefra. Region Nordjylland kan f.eks. være nødt til at etablere sin egen kronikerplatform til deres fuldskala KOL kronikerprojekt, og Region Syddanmark er ved at indkøbe en løsning til deres diabetiker kronikerprojekt.. Billedet kunne med forbehold komme til at se således ud: Region Nord Kronikerplatform Region Syd Figur 5. Integration til andre kronikerplatforme I det tænkte eksempel afleverer Region Nordjyllands løsning sine data til den Nationale Kroniker Infrastruktur ved at kalde en eller flere opdaterings Services på denne. Region Sydjyllands løsning udstiller en eller flere Services, så den Nationale Kroniker Infrastruktur selv kan hente monitoreringsdata m.v. Hvis den sidste model vælges, er det vigtigt, at der defineres en fælles snitflade, som de eksterne systemer skal implementere (i dette eksempel Region Sydjyllands indkøbte løsning), således at der ikke skal implementeres alle mulige integrationer til forskellige systemer. Lagring af kronikerdata i de lokale NSP er ved brug af DoDi I den skitserede løsning er der lagt op til, at Kronikerdata enten ligger i KronikerIndekset (MONI og EGNE), eller de hentes på anfordring ved kald af de Nationale Services. Der er endnu ikke lavet nogle målinger, men man kunne forestille sig, at det kunne være nødvendigt at cache visse Kronikerdata tæt på anvendelsen for at opnå en bedre performance i form af hurtigere svartider og mindre netværksbelastning. Man kunne bl.a. forestille sig følgende: Kronikerdata (EGNE og/eller MONI) kunne caches for opnåelse af hurtigere svartider Det kunne overvejes f.eks. hver nat at danne og cache det fulde Kroniker Datasæt for alle kronikere for at have (hurtig) adgang til nogenlunde opdaterede oplysninger i tilfælde af, at Nationale Services eller selve KronikerIndekset skulle være utilgængelige *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 10

11 Data kan lagres og distribueres til de lokale NSP er. På NSP erne ligger således allerede i dag en del stamdata herunder hele CPR-registeret. For at sikre NSP ernes performance og stabilitet har NSI har defineret en række principper for NSP herunder at NSP ikke må være ansvarlig for data. NSP kan benyttes til opbevaring og distribution af data, men selve dataejerskabet skal ligge et andet sted. Dette er bl.a. baggrunden for, at Kronikerdata (MONI og EGNE) ligger i en database, som er ekstern i forhold til NSP. Et andet grundlæggende princip for NSP er, at opdateringer af data sker gennem DoDi (Dataopsamling og Distribution). Opdateringer kan således godt ske via kald af Services, som er udstillet på NSP en, men disse Services skal i givet fald blot agere proxy, som viderestiller kaldene til eksterne Services, som opdaterer et ekstert datagrundlag. DoDi er en mekanisme til at distribuere data fra en central database til de enkelte NSP instanser. DoDi kan benyttes til at bringe centrale kronikerdata tæt på de enkelte anvendere og dermed sikre kortere svartider og mindre netværkstrafik se nedenstående figur: NSP NSP NSP DB DB DB SDN b DoDi Master DB DoDi a Kilde X DB Kilde Y DB Figur 6. NSP og DoDi (Dataopsamling og -Distribution) DoDi opdateres fra forskellige kilder og sørger herefter for distribution af data til de enkelte NSP instanser. Kommunikationen mellem DoDi og de enkelte NSP er sker via Sundhedsdatanettet (SDN). Hvis man skal overføre disse principper til den skitserede løsning, skal opdateringer stadig ske ved, at NSP en viderestiller Servicekald til KronikerIndeksets Servicedel, som ud over at opdatere Datadelen (MONI og EGNE) skal opdatere den centrale DoDi master database, som vil sørge for at distribuere ændringerne til de lokale NSP er: *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 11

12 Figur 7. Opdatering og disibution via DoDi Opdateringen sker på samme måde som i figur 3, men der er et ekstra trin (5), hvor Servicen på KronikerIndekset ud over at opdatere sin egen database (EGNE) skal opdatere DoDi master databasen, som straks vil sørge for, at ændringerne distribueres til alle de lokale DoDi databaser. Det er en del af serviceaftalen for NSP, at der tages backup af data. Men i nødstilfælde skal data i DoDi master databasen kunne genskabes ud fra indholdet i KronikerIndeksets database. MedCom meddelelser MedCom meddelelser er som nævnt så integreret en del af sundhedsvæsenets infrastruktur, at det vil være formålstjenstligt at fortsætte med at understøtte disse en periode fremover: *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 12

13 Figur 8. MedCom meddelelser 1. Oplysninger registreres i systemer hos læger og kommuner og sendes til KronikerIndekset som MedCom meddelelser (henvisning, korrespondance eller booking). KronikerIndekset er oprettet med et Lokationsnummer 2. KronikerIndekset sørger for at opdatere kronikerdata i databasen (EGNE) Abonnementer Den Nationale Kroniker Infrastruktur skal kunne understøtte abonnementer. F.eks. skal en praktiserende læge kunne abonnere på sine patienters dagbogsnotater og andre instansers SKL noter. Der skal også defineres kriterier for overvågning af borgernes måleresultater f.eks. ved forværring i tilstand. Der udestår en analyse af de aktuelle hændelser, der skal udløse alarmer m.v. Til afklaring Kan der være et udestående i forhold til sikkerhed i forbindelse med f.eks. opslag af FMK via NSP? F.eks. i forhold til anvendelse af medarbejder- eller virksomheds certifikater? Kan det på nogen måde være en ulempe, at der ingen forbindelse er mellem KronikerIndekset og de Nationale Services? Det kunne måske være ønskeligt, at hele Kroniker Datasættet kan hentes ved et kald direkte til KronikerIndeksets Servicedel og altså udenom NSP en, som kun kan tilgås via Sundhedsdatanettet *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 13

14 Skal KronikerIndekset opbevare kopier af data af hensyn til såvel performance (bedre svartider) som sikring af historik? Hvordan skal Logging (audit) håndteres? Skal det være muligt at genskabe søgeresultater? Når visse Kronikerdata kun hentes ved kald af de Nationale Services (NS), kan de være svære at genskabe Der skal stilles krav til og identificeres en databærende platform. Det vil være oplagt at genbruge en eksisterende infrastruktur, og RSI anbefaler at benytte Region Sjællands BilledIndeks. Men hvad siger Region Sjælland til, hvis deres BilledIndeks ikke bare kommer til at indgå i en fælles regional løsning, men i en National og Tværsektoral infrastruktur? Og hvad siger andre end regionale aktører til, at data muligvis kommer til at ligge regionalt? Der er både praktiske og juridiske udeståender. Hvordan er sammenhængen mellem borgerens kalender (Data segment nr. 12) og sundhed.dk s Aftalebog? Et forslag er, at aftaler i borgerens kalender overføres til Aftalebogen. Et andet forslag kunne være at få udvidet funktionaliteten i sundhed.dk, så den kan indeholde kalenderdelen af Kroniker Datasættet Booking processen (herunder anvendelse af MedCom booking meddelelser) er uafklaret. Behovet for at abonnere på oplysninger er endnu ikke fuldt afdækket. F.eks. skal man kunne abonnere på dagbogsnotater og SKL noter for udvalgte borgere Det er endnu ikke diskuteret, om abonnementer skal håndteres på NSP (funktionaliteten implementeres i version 2.0 forbindelse med CPR) eller i KronikerIndeksets Servicedel (ESB) Skal MedCom meddelelser gå direkte til KronikerIndekset, eller skal de f.eks. leveres gennem KMD? Kommuner (KL) har givetvis krav og ønsker, der endnu ikke er taget tilstrækkeligt hensyn til Næste skridt Glenn afleverer nyt udkast til MedCom (HBJ) inden mødet den 14. november 2011 Møde hos NSI den 14. november 2011 Henrik og Glenn aftaler nærmere efter mødet med NSI Møde med NSI den 13. december 2011 MedCom styregruppemøde den 15. december 2011 Glenn tilpasser oplægget sammen med NSI Dokumenthistorik Version Dato Forfatter Beskrivelse Glenn Petersen, 7N Første oplæg *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 14

15 Glenn Petersen, 7N Tilrettet efter MedComs samtaler med NSI, hvor det er besluttet at lave et fælles oplæg, hvor NSP en bliver en central komponent i den Nationale Kroniker Infrastruktur Glenn Petersen, 7N Tilrettet efter møde i MedCom den Glenn Petersen, 7N Tilrettet efter møder med NSI den 13. og Højere vægt på principper for løsningen Glenn Petersen, 7N A/S Enterprise Arkitekt, Partner *Mennesker gør en forskel! 7N A/S Kongevejen 400A DK 2840 Holte CVR T F info@7n.dk 15