Koordineringsgruppemøde d. 21/9-17
• Aaaaaa
• Aaaaaaa
Michael Johansen, Standarder, test & certificering mjo@medcom.dk
Standarder, Infrastruktur, Test &
Governance
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
Tema: 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 IT- systemerne der integreres direkte med VANS, men i stedet integreres IT-
systemerne 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.
Introduktion til 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.
Oprindelige VANS
Afsender Inhouse VANS VANS Inhouse Modtager
• 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
• Mange led i forsendelseskæden.
• 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, eksempel
Inhouse Cloverleaf Cloverleaf VANS RefHost VANS Cloverleaf Cloverleaf Inhouse
• 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
Nuværende VANS
• 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?
Opfølgning på negative kvitteringer
• Reducere de negative kvitteringer til 25 % af niveauet pr. 1. januar 2016, som supplement til Danske Regioners tidligere initiativ på området.
Målsætning i forhold til negative kvitteringer
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
• Fejl som følge af
manglende overholdelse af syntaks- og
kommunikationsregler.
• Pludselig opståede fejl, som følge af applikations- eller systemændringer i kommunikationsplatforme
• Uhensigtsmæssigheder i lokale applikations-
opsætninger eller arbejdsgange.
Når projektet helt i mål?
• 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)?
Er der behov for fortsat central monitorering & opfølgning?
• 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 Adressering – udfordringer/udvidelser
• 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 i SOR
• 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
Enhedstyper som nøgle til adressering
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
Hjemmesygepleje ARVER
LOKATIONSNUMMER
Handicap & psykiatri ARVER
LOKATIONSUMMER
Bosted ARVER
LOKATIONSNUMMER
Bosted EGET
LOKATIONSNUMMER Center for
Misbrugsbehandling EGET
LOKATIONSNUMMER
Brug af enhedstyper ?
Betydning af nedarving lokationsnumre?
• 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 FMK social og SOR
• 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
Eventuel udvidet brug af pakketabellen
• 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
Flere kommunale modtagere af samme meddelelsestype
Ø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?
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
Modernisering af kommunikation – tidsplaner m.m.
Bilag XML indlejret filer Opstart?
Planlægning?
Digital kommunikation for social-&psykiatri området
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
• 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?
Statistik omkring MedCom-meddelelser
Koordineringsgruppemøde d. 21/9-17
• Aaaaaa
• Aaaaaaa
Michael Johansen, Standarder, test & certificering mjo@medcom.dk
Standarder, Infrastruktur, Test &
Governance
VANS
• Vedhæftning af bilag ved indlejring
• VANS-kuverter
• VANS-kvitteringer
• Løbende aktiviteter
• Videreføres fra MedCom10 over i MedCom11
Modernisering MedCom10-regi
• 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?
Modernisering MedCom10-regi – løbende aktiviteter
• 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.
Infrastrukturmodernisering på den korte bane
• 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.
Vedhæftning af bilag ved indlejring
• 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-kuverter
• 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-kvitteringer
VANS dag d. 1/11-2017
• Standarder
• Infrastruktur
• Test
• FHIR-korrespondance: Orientering og invitation til pilot Modernisering MedCom11-regi
• 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)
Modernisering af MedCom standarder
• 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 CDA – 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 REST- teknologi, 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.
Status på arbejdet med HL7 FHIR – ultimo MedCom10
• 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 standarder
• 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å?
Modernisering af MedCom infrastruktur – ”Tour de MC11”
• 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).
Infrastruktur arkitektur
• 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
Sundhedsdatanet
• 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.
REST-teknologi
• 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.
National serviceplatform
• 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 …
Kommunale beskedfordelere
• 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 …
Primærsektorens Leverandør Service Platform (PLSP)
• 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 (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 infrastruktur, løsningsforslag (fra MedCom 8)
• 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)
Modernisering af MedCom infrastruktur
• Valg af kanal for besked- baseret 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 – 1. udkast
Den nye infrastruktur – 2. udkast
Afsender Region
”X” Bank
KOMBIT ”X”
Afsender Kommune
Afsender Læge
Region
PLSP
Monitorering
Statistik Delbare data
NSP XDS
Konv
CDA
DDS
REST-server Webservice
KMD bank PLSP bank
SDN
PLSP KOMBIT
+Kvit
Modtager VANS
Arkitekt dag d. 25. oktober 2017
• 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)
Modernisering af MedCom test og implementering
• 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 Korrespondance i FHIR
FHIR projekt – en har allerede takket ja
Koordineringsgruppemøde d. 21/9-17
• Aaaaaa
• Aaaaaaa
Michael Johansen, Standarder, test & certificering mjo@medcom.dk
Standarder, Infrastruktur, Test &
Governance
VANS
• 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.
Resumé
