VANS. Koordineringsgruppemøde d. 21/9-17. Aaaaaa Aaaaaaa. Standarder, Infrastruktur, Test & Governance

Koordineringsgruppemøde d. 21/9-17 Aaaaaa Aaaaaaa VANS Standarder, Infrastruktur, Test & Governance Michael Johansen, Standarder, test & certificering mjo@medcom.dk

Tema: VANS Introduktion til VANS Opfølgning på negative kvitteringer Adressering udfordringer/udvidelser Enhedstyper i SOR Eventuel udvidet brug af pakketabellen Orientering om FMK på socialområdet Orientering om adressering og flow ved flere kommunale modtagere af samme meddelelsestypestatistik omkring MedCom-meddelelser Statistik omkring MedCom-meddelelser Modernisering af MedCom standarder MedCom10-regi Vedhæftning af bilag ved indlejring VANS-kuverter VANS-kvitteringer MedCom11-regi Modernisering af MedCom standarder & infrastruktur FHIR-korrespondance: orientering og invitation til pilot

Introduktion til VANS VANS har været anvendt gennem mange år, og er siden starten løbende blevet udvidet. Udover transport af EDI-meddelelser, understøtter VANS nu også mapning mellem formater (for udvalgte standarder og parter). Den øgede funktionalitet har affødt en tilsvarende øget kompleksitet, som giver en større opgave med administration af VANS. Brugen af VANS har gennem årene skiftet karakter, så det nu ikke længere er ITsystemerne der integreres direkte med VANS, men i stedet integreres ITsystemerne via en eller flere integrationsplatforme/mellemled, som kan være regionale applikationer (som fx cloverleaf), eller kommunale beskedfordelere. Den øgede kompleksitet af VANS og de øvrige led i forsendelsesforløbet har medført flere kilder til fejl, og samtidigt vanskeliggjort fejlsøgning. Der er ingen overordnet monitorering af hele forsendelsesforløbet, og ingen aftalt SLA mellem parterne.

Oprindelige VANS To posthuse, der udvekslede EDI-meddelelser (dannet, KMD). Direkte filudveksling mellem VANS-klient i IT-system og VANS. Positiv/negativ kvittering, samt VANS-kvittering (CTL01). EAN-lokationsnumre anvendes til adressering. Afsender Inhouse VANS VANS Inhouse Modtager

Nuværende VANS Tre posthuse, der udveksler EDI-meddelelser (TrueCommerce, KMD, MultiMed) IT-system kan sende meddelelser via regional integrationsplatform eller kommunal beskedfordeler. VANS-kuvert, der er XML der kan rumme meddelelser af forskellige formater. VANS-kuvert kvittering (primær afsendelse af VANS). XML mappes til EDI, sendes som EDI, og mappes til XML igen. Mapning mellem meddelelsestyper (fx fra GGOP til DIS91). Routning af henvisninger til henvisningshotel. Særskilt kvitteringspolitik for kommunebeskeder, med op til tre gen-sendelser.

Nuværende VANS, eksempel Mange led i forsendelseskæden. Inhouse Cloverleaf Cloverleaf VANS RefHost VANS Cloverleaf Cloverleaf Inhouse Inhouseformat (fx HL7v2) håndteres med produkter som Camel. Anvendelse af regionale(rh) VANS-kuverter (på strækningen inhouse til VANS). Kommunikationsvej kan variere (fx overspringe regional cloverleaf), og foregå med forskellig teknologi som fildeling, FTP, køsystemer eller webservice. Fejlsøgning er svært udenfor afsender/modtager system. Fejlsøgning (fx mellem VANS instanser) er manuel. Overordnet monitorering savnes

Nuværende VANS SLA med VANS? mellem VANS? de øvrige led i kæden? Funktionalitet Transport EDI/VANS-kuvert Mapning EDI/XML, HL7v2 & inhouseformater Procedure ved fejl for lokationsnummer opdatering

Opfølgning på negative kvitteringer Forsendelse afvist Lokationsnumre forkerte. SOR ikke opdateret. SOR ikke retvisende. Forkert valg af modtager. Fejl i meddelelserne Struktur ikke valid. Semantisk indhold forkert. Hvad gør vi med ulydige systemer?

Målsætning i forhold til negative kvitteringer Reducere de negative kvitteringer til 25 % af niveauet pr. 1. januar 2016, som supplement til Danske Regioners tidligere initiativ på området.

Hvordan går det med negative kvitteringer? Landsdækkende statistik - samtlige afsendte negative kvitteringer Md-År CTL02 XCTL02 CTL01 XCTL01 CTL02 + XCTL02 CTL01+ XCTL01 I alt CTL 01 +02 jan-16 12.211 2.338 5.862 246 14.549 6.108 20.657 nov-16 12.274 416 5.155 89 12.690 5.244 17.934 dec-16 10.084 267 5.185 77 10.351 5.262 15.613 jan-17 12.458 654 5.034 90 13.112 5.124 18.236 feb-17 10.207 336 4.210 4 10.543 4.214 14.757 mar-17 11.522 272 4.684 5 11.794 4.689 16.483 apr-17 10.341 409 3.796 0 10.750 3.796 14.546 maj-17 11.687 1.386 4.940 0 13.073 4.940 18.013 jun-17 9.071 1.662 4.631 0 10.733 4.631 15.364 jul-17 6.445 1.062 3.672 0 7.507 3.672 11.179 aug-17 8.798 363 4.374 0 9.161 4.374 13.535

Når projektet helt i mål? Fejl som følge af manglende overholdelse af syntaks- og kommunikationsregler. Pludselig opståede fejl, som følge af applikationseller systemændringer i kommunikationsplatforme Uhensigtsmæssigheder i lokale applikationsopsætninger eller arbejdsgange.

Er der behov for fortsat central monitorering & opfølgning? Der følges jo allerede op på negative kvitteringer ude ved slutbrugerne og hos leverandører! Eller gør der? Nogen holdninger i gruppen her (er det spild af tid og ressourcer)?

Adressering udfordringer/udvidelser Enhedstyper i SOR Eventuel udvidet brug af pakketabellen Orientering om FMK på socialområdet Orientering om adressering og flow ved flere kommunale modtagere af samme meddelelsestype Statistik omkring MedCom-meddelelser

Enhedstyper i SOR Data i SOR er hierarkisk struktureret og indeholder minimum tre niveauer. Hvis navngivning ikke er meget tydelig, kan det være meget vanskeligt for en samarbejdspartner at finde rette modtager. Enhedstyper i SOR a. Registrering af enhedstype er obligatorisk i SOR. b. Enhedstypen skal altid registreres så specifikt som muligt ift. til de 3 niveauer i SOR Institutionsejer (IE), Sundhedsinstitution (SI) eller Organisatoriske enheder (OE). c. Der er mulighed for at oprette flere OE niveauer lokationsnummer kan nedarves eller optræde med yderligere præcisering SOR kan understøtte at finde rette modtager og BGF præsentation Hvordan implementeres dette i systemerne, hvis vi bliver enige om at anvende enhedstyper? Der er brug for fælles anvendelseskriterier af SOR data.

Enhedstyper som nøgle til adressering Alle enheder i SOR har en enhedstype Vision om entydigt match mellem kommunale lovbundne opgaver og de kommunale organisationer i SOR: Sociale indsatser Misbrugsbehandling Genoptræning Sundheds og Forebyggelse Hjemmesygepleje Mv. *undtagen Læsø kommune

Kommunale enhedstyper i SOR NU Enhedstype SI OE Andet sundhedsvæsen X X Administrativ enhed X Anden EDI X Asylcenter X X Behandlingscenter for stofmisbrugere X X Center for misbrugsbehandling X X Bosted X X Genoptræningscenter X X Hjemmesygepleje X X Handicap og psykiatri X X Jobcenter X X Plejehjem X X Pædagogisk Psykologisk Rådgivning X X Sundhedsforvaltning X X Sundhedspleje X X Sundhedscenter X X Supplerende oplysninger X

Enhedstyper og nedarving af lokationsnumre - et eksempel fra virkeligheden (ønsket SOR opbygning) Kommune Social & Sundhedsforvaltning + lokationsnummer Brug af enhedstyper? Betydning af nedarving lokationsnumre? Hjemmesygepleje ARVER LOKATIONSNUMMER Handicap & psykiatri ARVER LOKATIONSUMMER Center for Misbrugsbehandling EGET LOKATIONSNUMMER Bosted ARVER LOKATIONSNUMMER Bosted EGET LOKATIONSNUMMER

FMK social og SOR 1200 kommunale sociale organisationer skal oprettes i SOR ifm. FMK til social området SOR data anvendes/skal anvendes Adressering/lokationsnumre ved beskedbaseret kommunikation/medcom standarder Indberetning utilsigtede hændelser Risikobaserede tilsyn FMK statistik og FMK social - behov for indlæsning af kommunale enheder Indberetning af genoptræning Ajourføring af kommunale data med sociale institutioner, enhedstyper og tjek af lokationsnummer på SI og OE niveauerne Dialog mellem KL, FMK, Sundhedsdatastyrelsen/SOR og MedCom

Eventuel udvidet brug af pakketabellen Styrer forsendelse af henvisninger til rette modtager Vejledning til henviseren Udvide brugen af pakketabellen for kommuner - i dag henvises til kommunale forebyggelsestilbud - SST foreslår at medtage henvisning til kommunale akutfunktioner + tilbagesvar - i dag anvendes korrespondance til hjemmesygepleje

Flere kommunale modtagere af samme meddelelsestype Social- & psykiatriområdet indgå i elektronisk kommunikation Sundhedsaftaler 2015-2018 ligestiller somatik & psykiatriområdet MedCom modtager løbende henvendelser om at komme i gang Lokale pilotprojekter kæmper for at finde løsninger for meddelelses flow FMK social få en spydspids funktion Hvis en borger både er tilknyttet social-& psykiatri samt hjemmesygeplejen Orientering igangværende proces om adressering og flow ved flere kommunale modtagere af samme meddelelsestype(advis & hjemmepleje-sygehus) Workshop onsdag d. 20. september 2017 løsning model skal drøftes Oplæg til kommende møde i sygehus-kommune leverandørgruppen er d. 2. november 2017

Flere kommunale modtagere af samme meddelelsestype

Digital kommunikation for social-&psykiatri området Ønskes: Beskedfordeler KOMBIT eller den enkelte kommune Men mange ukendte faktorer: - Tidsplan - Den konkrete snitflade? - Hvad omfatter løsningen? Hvilke services løser hvad tværsektorielt og intrakommunalt? - Advis certificering på vej - Øvrig kommunikation? Drøftes: Løsning indenfor eksisterende rammer OBS delmængde af borgere er både-og - Bruge SOR enhedstyper ifm. valg af modtager - SOR data kommuner skal ajourføres - De regionale systemer skal understøtte proaktivt system + bruger tilpasning - Behov for analyse af konsekvenser og behov for supplerende regelsæt Udfordring: Uanset løsningsmodel - Tidshorisont - Omkostninger - Eksisterende meddelelser dækker måske kun delvist behovet hos social- & psykiatriområdet = nemmere med nye standarder - Notat d. 2. november 2017 SOR-enhedstyper Fælles regler Pakketabel MedCom Kommunale data i SOR Fælles kommunalt datasæt/organisatorisk register til ajourføring af data? Sociale institutioner Systematisk opdatering af enhedstyper og lokationsnumre Bilag XML indlejret filer Opstart? Planlægning? Modernisering af kommunikation tidsplaner m.m.

Statistik omkring MedCom-meddelelser Nuværende statistik følger som udgangspunkt standarden Genoptræningsplan findes i tre udgaver, der er sideløbende gyldige og anvendes samme version, GGOP1, GGOP2 og GGOP3. Samme opdeling findes i VANS-kuverten. Bør statistik opdeles for andre MedCom standarder?

Modernisering MedCom10-regi Vedhæftning af bilag ved indlejring VANS-kuverter VANS-kvitteringer Løbende aktiviteter Videreføres fra MedCom10 over i MedCom11

Modernisering MedCom10-regi løbende aktiviteter Udvidet brug af UUID muliggør den røde tråd. Harmonisere CDA, bl.a. fælles CDA header, ved MaTIS opfølgning og nye CDA. Berigtigelse/sletning (fx sletteanmodning for laboratorie-rekvisition/-svar)? Nationale e-cpr indarbejdes i standarderne? CPR-opslag 1.0.4 for grænsegængere på omgangshøjde. Revidere EDI/XML (fx medruc til Praksys, SUP til E-journal, FSIII udvekslingsformat). Pilotafprøvning af IDWS (der erstatter DGWS). EU Persondataforordningen?

Infrastrukturmodernisering på den korte bane Skift af VANS meddelelser til webservicekald via sundhedsdatanet. I gang for webreq laboratorierekvireringsportal Planlagt for refhost henvisningshotel Stabilitet på VANS (og det som ligger mellem VANS og endepunkterne). Overvågning, udmeldinger ved driftsproblemer. Procedure for fejlsøgning? Driftsproblem for RH medførte nødprocedure til 9.000 i kommunen og 40.000 i regionen. NSP services. Dokumentdelingsservice med IHE XDS, med CDA-dokumenter, og tilhørende kompleks af støtteservices samtykke, behandlingsrelation, MinLog, advisering.

Vedhæftning af bilag ved indlejring Vedhæftning af bilag sker i dag med MEDBIN og XMEDBIN. Fordel er, at stort bilag ikke forhindrer tilhørende besked. Indlejring af bilag Fordel er, at man ikke skal afvente samhørende beskeder. Undgår parring af de samhørende beskeder. Videreforsendelse får alle oplysninger med.

VANS-kuverter Forsendelse af andet end EDI skal ske i VANS-kuvert (ved VANS kommunikation) Én meddelelse Emessage pr. VANS-kuvert. Én Emessage rummer kun én besked. Revidering af VANS-kuvert KuvertID og BrevID adderes VANS-kuverten (lokalisér meddelelse der kvitteres). Payload type ændres til String (kræver binary i dag) Payload benytter fortsat base64 encoding.

VANS-kvitteringer Forenklede kvitteringsregler. Intet gensendes baseret på udeblevet kvittering (nu må der gensendes op til tre gange). Bør sende kvittering, hvis der anmodes Krav i dag ved henvisninger + genoptræningplan. Udvides i 2017 for kommune/sygehus-kommunikationen. Kvitteringsøkonomi (VANS prispolitik), VANS-kuvert med kvittering koster? Understøtte KL beskedfordeling. Beskedfordeler kvittere for modtagelse. Opsnappe kommunal modtagersystems eventuelle kvitteringer.

VANS dag d. 1/11-2017

Modernisering MedCom11-regi Standarder Infrastruktur Test FHIR-korrespondance: Orientering og invitation til pilot

Modernisering af MedCom standarder Migrering mod øget brug af HL7 CDA ved national dokumentdeling (XDS). Fælleseuropæiske XDS metadata (SDS)? FHIR ved asynkron forsendelse af meddelelser. Dynamik med spilleregler. Der er stadig behov for høj strukturering. Hvor fleksibel må standarderne være (håndtering af extensions)? Udfasning af EDI men kun hvor det giver nytteværdi Sideløbende brug af EDI/XML, med successiv migrering Kun vælge nyt redskab, hvis det ikke kan løses med eksisterende redskaber. XML har intuitiv hierarki, modsat EDI. Adgang til ressourcer & understøttelse i udviklingsværktøjer. Klassifikationsserver (FTP)

Status på arbejdet med HL7 CDA ultimo MedCom10 Der udvikles løbende nye HL7 CDA dokumenter, med henblik på integration efter den nationale referencearkitektur. Hjemmemålinger (PHMR), der lagres i KIH-databasen. Spørgeskemaer og spørgeskemabesvarelser (PRO). Aftaler, som del af projektet for komplekse forløb. Der er aftalt udvikling af CDA for plan/opfølgning, også som del af projektet for komplekse forløb. Samlingen af CDA dokumenter anvender et fælles header element, som løbende ajourføres ved behov, når nye CDA bringer nye behov til den fælles dokumentation. Der er udviklet et hjælpeværktøj CDA builder for anvendelse af systemleverandørerne, ligesom MedComs testværktøj løbende udvides med nye CDA.

Status på arbejdet med HL7 FHIR ultimo MedCom10 Der afprøves en dansk profilering af HL7 FHIR ressourcer, til identifikation af problemområder der bør løses, inden en eventuelt migrering planlægges. Afprøvningen løber over andet halvår 2017, og skal ultimo året give styregruppen en indstilling til det eventuelt videre arbejde med HL7 FHIR. Konkret afprøves FHIR version STU3 med to projekter. Mapning fra OIOXML laboratoriesvar fra laboratoriesvardatabanken til FHIR. Udover konkret afprøvning af mapning fra XRPT, så rummer projektet også afprøvning af RESTteknologi, hvorved laboratoriesvar udstilles for mobile enheder i JSON format. Forsendelse af korrespondancemeddelelse mellem to pilot installationer, for afprøvning af agil revidering af standarden. Der er ikke lavet aftaler med de to pilot installationer endnu. Transporten tænkes udført som en FHIR indpakket i VANS-kuvert, hvorved test filer kan forsendes med den eksisterende infrastruktur. Arbejdet koordineres med HL7 affiliate (Dansk Standard), og de opsamlede erfaringer præsenteres på det kommende e-sundhedsobservatoriet d. 12. oktober 2017.

Modernisering af MedCom standarder ISO-certificering af proces for udarbejdelse/revidering af standard Konsistens i dokumentation standarder, vejledninger og testprotokoller Uddybende beskrivelse for valgfrie oplysninger Støve syntaks- og kommunikations-regler af. Online dokumentation, udtræk det format (XML/JSON) man ønsker. Governance Overblik over de samlede årshjul Elektrificering af MedComs opgavetavle

Modernisering af MedCom infrastruktur Tour de MC11 Mange parallelle initiativer Generel fællesoffentligt infrastruktur til brug for digital post Fælleskommunal KOMBIT-infrastruktur Fællesregional XDS-infrastruktur på sundhedsområdet Praksissektorens fælles services Fælles nationale services på sundhedssektorens NSP Hvor skal vi sammen udbrede den tværsektorielle anvendelse af den nye generation af MedCom standarder? IT arkitektoniske hensyn: Det sektorspecifikke og det fælles! Økonomiske hensyn: Skal vi lade noget være som det er? Politiske hensyn: Hvem skal have førertrøjen på?

Infrastruktur arkitektur Infrastrukturer VANS Sundhedsdatanet (SDN) National serviceplatform (NSP) Beskedfordelere (fx kommunale KOMBIT) Primærsektorens serviceplatform (PLSP) Kommunikationsmåder EDI/OIOXML beskeder sendes via VANS (fx epikriser og genoptræningsplaner). EDI sendes til central database, hvorfra der videresendes (fx henvisningshotellet). OIOXML udstilles via webservice på Sundhedsdatanet (SDN), fx laboratoriesvarportalen (analogt FMK). HL7 uploades/downloades via central database (fx hjemmemonitoreringsdata).

Sundhedsdatanet Det oprindelige VANS-netværk er konstrueret til at sende meddelelser fra afsender til modtager, hvilket sker asynkront så de enkelte IT-systemer ikke er gensidigt afhængige af hinandens tilgængelighed. I takt med at typen af interoperabilitet ændredes, så IT-systemer fik behov for på anfordring at hente oplysninger, skabtes sundhedsdatanettet. Derved kunne IT-systemer integreres synkront via udstillede services, i tråd med tidssvarende serviceorienteret arkitektur (SOA). Sundhedsdatanettet kan anvendes både til hentning af oplysninger fra nationale databaser, men også til upload til de nationale databaser. Den hidtil gængs anvendte webservice teknologi suppleres evt. fremover af REST-teknologi, der har sin styrke ved anvendelse på mobile enheder.

Sundhedsdatanet Høj sikkerhed med aftalesystem. Høj tilgængelighed med redundans Funktionalitet (ex) Webservice opslag Webløsninger FTP

REST-teknologi Dynamiske søgeparametre mindsker krav til udstyrs ydeevne. Processering af data foretages centralt, og netværkstrafik mindskes. Bagudkompabilitet reducerer mobile enheders behov for opdatering. REST-teknologi kan fx anvendes mellem smartphones/tablets og fagsystemer/opsamlingsenheder. Bør REST-teknologi anvendes over sundhedsdatanettet til nationale services? Sikkerhedsmodel skal laves.

National serviceplatform Nationale services som FMK, nationale registre som CPR, m.fl. transporteres sikkert via sundhedsdatanettet. Løbende revideres de nationale services, i tråd med den nationale strategi, bl.a. med dokumentdelingsservice, samtykkeservice, behandlingsrelationsservice, etc. Nye services kommer til, fx komplekse forløb (stamkort, livstestamente). NSP bygger på deling af data, fremfor udveksling af meddelelser, hvorfor den nye meddelelsesbaserede infrastruktur bør indgå i denne deling.

Kommunale beskedfordelere Det har vist sig udfordrende at håndtere, at flere modtagere ønsker samme information, og afsenderen ikke er bekendt hermed. Problemet løses derfor ikke med information om kopimodtagere el.lign. Udfordringen løses med brug af beskedfordelere, der modtager den udvekslede meddelelse, fx et indlæggelsesadvis, og rummer et internt abonnementssystem der fordeler meddelelsen til de relevante IT-systemer i egen organisation. Det er beskedfordelerens opgave at returnere kvittering for den modtagne meddelelse. Ibrugtagning af beskedfordelere bevirker at SOR-oplysninger skal justeres, så aktuelle standarder/lokationsnumre evt. fjernes fra de organisatoriske enheder der anvender IT-systemerne, og i stedet tilføjes oplysningerne den centrale modtageenhed. Der etableres evt. en kommunal pakketabel til håndteringen.

Kommunale beskedfordelere Tegning

Primærsektorens Leverandør Service Platform (PLSP) Spor 1, der fokuserer på løsninger der kan understøtte og bidrage til at skabe sammenhæng på tværs af systemhusene og andre aktører i sundhedsvæsenet. Her kan nævnes borgersamtykke, aftaler, retten til at blive glemt, tilbagekaldelse af distribueret information og information omkring praksis, åbningstider ferie mv. Her er tale om oplysninger, som skal eksponeres både via apps, portaler, men også webservices, som understøtter system til system kommunikation. Spor 2, der på baggrund af de etablerede services sikrer dialogen mellem borger og den praktiserende læge. Sikrer vidensdeling og udvikling på baggrund af de mange erfaringer der opsamles, med udgangspunkt i det fortrolighedsforhold der er kendetegnet for relationen mellem den enkelte borger og den praktiserende læge.

Primærsektorens Leverandør Service Platform (PLSP) Fælles funktionalitet samlet for PL-forum Forløbsplan arkitektur, fx med forløbsplanregler FNUX lookup (kan udvides med andre meddelelsestyper, hvis SOR ikke løser opgaven, men denne service bør være national). Udstille klinikkers ferielukninger Fælles snitflade mod beskedudveksling det nye VANS Brugerstyring?

Primærsektorens Leverandør Service Platform (PLSP) Tegning

Modernisering af infrastruktur (fra MedCom 8) At MedCom kommunikationen bygger på forældet teknologi der involverer mange aktører, mangler effektiv support og overvågning og har store problemer med adressering og versionsstyring. At MedComs standardisering bør professionaliseres og omfatte en effektiv release- og versionsstyring, benytte internationale standarder og i højere grad bygge på en fælles datamodel. Der er behov for at tænke de tekniske ændringer sammen med muligheden for at øge implementeringshastigheden for specifikke standarder, fx ved versionsændringer Der er behov for at inddrage leverandørsiden og dens betydning for udrulningshastigheden af nye standarder og versionsændringer.

Modernisering af infrastruktur, løsningsforslag (fra MedCom 8) Et MedCom Meddelelseshotel, der skal gøre det muligt at sundhedspersonale og borgere kan se indholdet af alle meddelelser. En modernisering af MedCom infrastrukturen, hvor et af alternativerne er en fremtidig NemInfo infrastruktur (nemhandel). Effektivisering af standardiseringsarbejdet Styrket driftssikkerhed med overvågning og support

Modernisering af MedCom infrastruktur Deling af data, i stedet for meddelelsesforsendelse Asynkron kommunikation er stadigt et behov. Hvordan sikres at kun relevante ser meddelelse? Hvordan adviseres modtager, at de skal hente post (abonnement, advis eller periodisk)? Både understøtte XDS og samtidigt udstille webservices og REST-services, for de udvekslede beskeder? Transition fra VANS til én national kanal, med tæt sammenhæng til NSP. Der ønskes flere forskellige måder at kommunikere på. Ikke fastlåst til én måde at gøre ting på. Integrere med kommunale beskedfordelere og PLSP sektor fordøre. Kvittér ved hoveddøren. Hver sektor håndterer interne kvitteringer bag deres egen fordør. Central governance, logning og statistik.

Modernisering af MedCom infrastruktur Reduceret transporttid med højere leverancesikkerhed. Have så få led i kæden som muligt, for øget driftsstabilitet. Successive overgange i den takt IT-systemerne og infrastrukturen er klar. Mapning mellem versioner af samme standard (fx 1.0.3 til 1.0.2) Mapning mellem standarder (fx GGOP til DIS91) Implementeringsplaner bliver uafhængige af roadmaps for de IT-systemer der senest implementerer nyt. Dette betyder at nye projekter fremover langt hurtigere kan idriftsættes. Åben for apps, der kan række ud mod borgerne. Sikkerhed Databehandleraftaler. EU persondataforordning? OIO IDWS Den gode webservice version 2 (efterlever IHE XUA) nemid (inkl. krav til stabilitet hos Nets)

Den nye infrastruktur 1. udkast Valg af kanal for beskedbaseret kommunikation. Integrere nyt med eksisterende. Bevare lokationsnumre & SOR til adressering. Beskrivelse af transition. Årsager til migrering. Behovsdiskussion d. 6/11 på styregruppeseminar.

Den nye infrastruktur 2. udkast SDN PLSP PLSP bank NSP XDS KMD bank KOMBIT DDS REST-server Webservice CDA X Bank Delbare data Afsender Region Afsender Kommune Region KOMBIT X Monitorering Konv VANS Modtager Afsender Læge PLSP +Kvit Statistik

Arkitekt dag d. 25. oktober 2017

Modernisering af MedCom test og implementering Certificering af system pr. standard suppleres med End2End test. Undgå manuel portering af testfiler til VANS produktionsmiljø? Implementering Ønsker mindsket bøvl ved versionsskifte. Undgå at alle skal skifte samtidigt. Vil idriftsættelse mon gå hurtigere med FHIR? (Samme komplekse organisation)

Korrespondance i FHIR Koordinering af danske profiler for FHIR ressourcer (SDS, HL7-affiliate) Map fra laboratoriesvar XRPT01 til FHIR-format via REST-server Send korrespondancebrev som FHIR Korrespondancemeddelelser er blevet en skraldespand Udfordring: Hvilke data må man undlade at vise, hvis tilføjelser er frit for afsenderen? Bør FHIR extensions angives redundant i læsbar udgave? Stadigt behov for høj strukturering i meddelelserne Invitation til pilotafprøvning

FHIR projekt en har allerede takket ja

Resumé Standarder afprøves i HL7 FHIR. Håndtering af extensions, valg af terminologi og struktur. Fundament for innovation. Beskedbaseret infrastruktur mellem parter omlægges til datadeling. Sammenhæng med national NSP infrastruktur. Tidstro interoperabilitet, med øget driftsstabilitet. Test i særskilt infrastruktur, da klassifikationer som SOR og lokationsnumre kun findes i én udgave. Adressering i SOR Nye enhedstyper. Versioner af meddelelsestyper (ellers laves der en ny service?) SDS og RUSA accept af foreslået NSP arkitekturudvidelse. Arkitekturdag hos MedCom.