6.2.15.2.1 POC’ens eDelivery fundament
MedComs tilgang til eDelivery var i forberedelsen af POC’en at afprøve om CEF’s (EU’s Connecting Europe Facility) open source-komponenter i denne model, Domibus AP (Access Point) og SMP (Service Metadata Provider), kunne tages i anvendelse. Vi undlod bevidst at arbejde med SML (Service Metadata Locator), da dens funktion i princippet udelukkende er at udpege, hvilken SMP en given GLN-modtagers kapabiliteter er registreret i. Komponenterne viste sig at være ganske anvendelige og robuste, hvorfor de blev grundstenene i POC’en. Vi anvendte generelt i POC’en en generisk modtageradresse, således at der i princippet kan sendes en hvilken som helst dokumenttype (meddelelsestype) i dette setup. I en produktionsmoden verden ville registreringerne i SMP være meget specifikke ift. meddelelsestype.
SML og SMP anvendes i sammenhæng normalt til at håndtere de dynamiske opslag, hvor først SML og dernæst den korresponderende SMP kaldes for en given GLN-enhed. SMP udgør i praksis en udvidet adressebog ift. eksempelvis SOR, hvor en kombination af ”partnerskabstabellen” i SOR og de eksisterende VANS-leverandørers konfigurationer af fysiske adresser for en given GLN-enhed udgør en for alle brugere af SMP transparent kapabilitetsregistrering. Til sammenligning synkroniserer backend systemer i dag med SOR med jævne mellemrum, nogle dagligt andre ugentligt eller sjældnere, således at en given GLN-modtagers kapabiliteter kan slås op her, mens man overlader til VANS at håndtere de fysiske adresseringer via VANS leverandørernes egne konfigurationer af koblingen mellem SOR-kapabiliteterne og deres egne adresseregistreringer.
Formateret: Skrifttype: Calibri, 11 pkt
Vi anvendte 2 typer registreringer i SMP, ”opkomst” og ”distribution”, således at både 4- og 3-corner modellerne kunne afprøves. ”Distribution” anvendes ikke direkte forskelligt i hhv. 4- og 3-corner modellerne, men anvendes i 4-corner modellen som den direkte adresse til modtager, mens den i 3-corner modellen anvendes som den del af flowet, som sker fra Gateway’en/Hub’enHub’ens AP frem til slutmodtager. ”Opkomst” anvendes kun i 3-corner modellen til at håndtere den første del af flowet, hvor den første opkomst af en meddelelse på eDelivery infrastrukturen skal sendes frem til den intermediære part i flowet, Gateway’en. Gateway’ens fysiske adresse, C2s AP, vil i 3-corner sammenhæng altså altid repræsentere en opkomst-adresse, mens C3s AP altid vil repræsentere distribution-adressen.
Generelt anvendte vi MedComs Genoptræningsplans-meddelelse (GGOP) Korrespondance-meddelelse (XDIS91) og Positiv Kvitterings-meddelelse (XCTRL03) alle i xml-format. Disse meddelelser var udvalgt, fordi de i løbet af POC’ens udviklingstid potentielt ville være tilgængelige som hhv. CDA-version og FHIR-CDA-version ifm. andre projekter, som MedCom var involveret i. CDA CDA-versionen af GGOP blev i denne sammenhæng skabt ud fra en relativ primitiv xslt transformering af GGOP’en,
tilstrækkelig dog til at kunne opfylde CDA standarden, OIOXML’en XDIS91 nåede ikke at blive færdig som FHIR version, og den blev derfor i afprøvningen blot ”transformeret” (dvs. indpakket) i en FHIR Communication ressource, som blev sendt til FHIR serveren, og derfra kunne hentes og udpakkes igen som OIOXML. Formålet her var ikke at afprøve REST baserede kald ifm. datadeling på forespørgsel, og derfor blev der ikke gjort mere ud af transformationsdelen.
Udeladelse af en SML viste sig i praksis at betyde, at de dynamiske opslag i SMP ikke blev helt så dynamiske som forventet, idet det snarere blev en dynamisk synkronisering af alle registreringer i SMP end et direkte opslag på det enkelte GLN-nummers kapabiliteter. Dette kan gå i et test setup, men ville naturligvis skulle implementeres korrekt i et produktions-setup.
6.2.25.2.2 Afprøvning af eDelivery’s 4-corner model
eDelivery’s 4 corner model er grundmodellen i eDelivery infrastrukturen og den model, der er mest sammenlignelig med den eksisterende VANS infrastruktur.
I udviklingen af POC’en sattes en testapplikation1 (C1) til at sende en XDIS91 pakket ind i eDelivery’s SBDH-Konvolut (Standard Business Document Header) via en Domibus instans kaldet Red (C2) til en anden Domibus instans kaldet Blue (C3) og videre til en modtagende testapplikation2 (C4). Red (C2) slog testapplikation2s ”distribution” modtageradresse (Blue (C3)) op i SMP, sendte SBDH(XDIS91) pakket krypteret ind i AS4, modtog behørigt sin AS4-kvittering, hvorefter Blue (C3) videregav SBDH(XDIS91) til den modtagende testapplikation2 (C4). Testapplikation2 (C4) tilhørende Blue (C3) agerede på kravet om positiv kvittering og sendte derfor en SBDH(XCTRL03) den modsatte vej via Blue (C3), som slog Testapplikation1s ”distribution” modtageradresse op i SMP og sendte tilsvarende SBDH(XCTRL03) pakket krypteret ind i AS4, Red (C2) svarede med en AS4-Ack og videregav SBDH(XCTRL03) til den oprindeligt afsendende testapplikation (C1).
Figur 3 - CEF's eDelivery 4-corner model
Dette er simuleringen af en helt normal meddelelsescyklus i VANS-nettet blot tilført dynamisk opslag i SMP og anvendelse af åbne internationale standarder, alle sammen specificeret i OASIS-regi.
I Connectathon-setuppet agerede RegionSyds Cosmic Applikation i produktion C1 med en tilhørende Domibus-instans, C2, opereret af KMD. Herimellem anvendte RegionSyd og KMD deres sædvanlige Cloverleaf og VANS-setup. Modtagende parter (C4) udgjordes af hhv. PLSP og MedComs Testcenter, PLSP (C4) repræsenteret af MultiMed, med egenudviklet Access Point (C3) (videreudviklet fra en Peppol Access Point baseret på AS2) og MedComs Testcenter (C4) med et TrueCommerce Domibus baseret Access Point (C3).
I ”Figur 4 - Sekvensdiagram af 4-corner modellen” ses flowet grafisk af denne kommunikation.
RegionSyd
Ansat Cosmic PLSP
Send XDIS91
Send XDIS91
AS4(Ack)
KMD AP PLSP AP
Send AS4(SBDH(XDIS91))
Send SBDH(XDIS91) Send SBDH(XCTL03)
Send AS4(SBDH(XCTL03)) AS4(Ack) Send SBDH(XCTL03)
SMP
getAddress (PLSP, distribution)
getAddress (PLSP, distribution)
Figur 4 - Sekvensdiagram af 4-corner modellen
6.2.35.2.3 Afprøvning af eDelivery’s 3-corner model
Formålet med afprøvning af 3-corner modellen, som i princippet ”blot” er 2 4-corner modeller sat sammen, er at kunne indsætte en gateway, som kan agere på en række forskellige måder, alt efter hvilket udbytte man vil have af en sådan enhed. Gateways kan bruges som integratorer mellem 2 forskellige net, oversætte formater fra afsender til modtager, opsamle statistik, centralt overvåge nettrafikken, kopiere meddelelser til brug i anden sammenhæng såsom datadeling. Man skal i dette eDelivery setup skifte forståelse af corner-betegnelserne, idet de ikke optræder med samme logik som i 4-corner modellen. Backendsystemet og dets AP smelter sammen til C1 hhv. C3 i
modtagersituationen, mens Hub/Gateway får betegnelsen C2.
Der etableres altså 2 4-corner scenarier, hvor C1 interagerer direkte med C2, og hvor C2 interagerer direkte med C3. Det eneste, der adskiller de 2 scenarier, er at man i SMP søger efter hhv. ”opkomst”-adresser og ”distribution”-”opkomst”-adresser. Selvom et sekvensdiagram ser mere uoverskueligt og komplekst ud, er der intet uoverskueligt i det praktiske, som hver enkelt part skal foretage sig.
En mere kompleks version af det ovenfor beskrevne følger her, hvor den detaljerede beskrivelse af sekvensdiagrammet udfoldes. Det følgende kræver tungen lige i munden!
I det følgende betegnes Backendsystem og AP hhv. C1_1 og C1_2 i afsendersituationen, Gateway og dens AP betegnes hhv. C2_1 og C2_2, mens modtagersystemets backend og AP betegnes C3_1 og C3_2.
For at kunne adressere korrekt i 3-corner modellen, opererer en modtager, som tidligere nævnt, med både en ”opkomst” adresse og en ”distribution” adresse, hvor den første bruges første gang en meddelelse optræder i eDelivery-infrastrukturen, mens ”distribution” bruges, når den samme meddelelse videreformidles i infrastrukturen.
I udviklingen af POC’en sattes
- testapplikation1 (C1_1) til at sende en XDIS91 pakket ind i eDelivery’s SBDH-Konvolut (Standard Business Document Header) via Red (C1_2)
- Red (C1_2) slog testapplikation2s ”opkomst” modtageradresse for XDIS91, dvs. Gateway’ens AP (C2_2) op i SMP
- Red (C1_2) sendte SBDH(XDIS91) pakket krypteret ind i AS4 til Gateway’ens AP (C2_2) og modtog behørigt sin AS4-kvittering derfra
- Gateway’ens AP (C2_2) slog testapplikation2s ”distribution” modtageradresse for XDIS91, dvs.
Blue (C3_2) op i SMP
- Gateway’ens AP (C2_2) sendte SBDH(XDIS91) pakket krypteret ind i AS4 til Blue (C3_2) og modtog behørigt sin AS4-kvittering derfra
- Blue (C3_2) sendte SBDH(XDIS91) videre til en modtagende testapplikation2 (C3_1)
- testapplikation2 (C3_1) sendte herefter en Positiv kvittering (XCTRL03) pakket ind i eDelivery’s SBDH-Konvolut (Standard Business Document Header) via Blue (C3_2)
- Blue (C3_2) slog testapplikation1s ”opkomst” modtageradresse for XCTRL03, dvs. Gateway’ens AP (C2_2) op i SMP
- Blue (C3_2) sendte SBDH(XCTRL03) pakket krypteret ind i AS4 til Gateway’ens AP (C2_2) og modtog behørigt sin AS4-kvittering derfra
- Gateway’ens AP (C2_2) slog testapplikation2s ”distribution” modtageradresse, dvs. Red (C1_2) op i SMP
- Gateway’ens AP (C2_2) sendte SBDH(XCTRL03) pakket krypteret ind i AS4 til Red (C1_2) og modtog behørigt sin AS4-kvittering derfra
- Red (C3_2) sendte SBDH(XCTRL03) videre til den modtagende testapplikation2 (C1_1)
Figur 5 - CEF's edelivery 3-corner model
I Connectathon-setuppet agerede RegionSyds Cosmic Applikation i produktion C1_1 med en tilhørende Domibus-instans, C1_2, opereret af KMD. Herimellem anvendte RegionSyd og KMD deres sædvanlige Cloverleaf og VANS-setup. Gateway’ens AP udgør som i udviklingsforløbet C2_2. Modtagende parter udgjordes af hhv. PLSP (C3_1) og MedComs Testcenter (C3_1), PLSP (C3_1) repræsenteret af MultiMed, med egenudviklet Access Point (C3_2) (videreudviklet fra en Peppol Access Point baseret på AS2) og MedComs Testcenter (C3_1) med et TrueCommerce Domibus baseret Access Point (C2_2).
I ”Figur 6 - Sekvensdiagram af 3-corner modellen” ses flowet grafisk af denne kommunikation.
RegionSyd
Figur 6 - Sekvensdiagram af 3-corner modellen
6.2.45.2.4 POC’ens datadeling på forespørgselsfundament
POC’ens datadelingsfundament er eDelivery 3-corner infrastruktur, som skaber muligheden for at lave den glidende overgangsløsning mellem datadeling ved videregivelse og datadeling på forespørgsel ved at stille en Gateway til rådighed for at viderebehandle de ankomne meddelelser på Gateway’ens AP.
Gateway’en giver hermed på baggrund af en intern konfiguration mulighed for
- at route meddelelser til en hvilken som helst service som gateway’en understøtter - at transformere meddelelser fra et format til et andet.
I POC’en er transformationer fra OIOXML til hhv. HL7 CDA og HL7 FHIR udvalgt til 2 forskellige platforme for datadeling på forespørgsel, XDS repræsenteret ved den på NSP velkendte
Dokumentdelingsservice (DDS) og FHIR repræsenteret ved en til lejligheden oprettet FHIR server.
I DDS-sammenhæng ønskede vi at afprøve dels, at vi kunne transformere en OIOXML til HL7 CDA, registrere den via DDS’ens XDS-infrastruktur, notificere National Adviseringsservice (NAS) herom og dels at gøre den tilgængelig for systemer, der abonnerer på NAS’en.
Tilsvarende ønskede vi i FHIR setup’et med en meget simpel FHIR-transformation at bringe REST paradigmet i spil og vise, at integration af FHIR kombineret med NAS vil kunne laves ligeså sømløst som DDS/NAS kombinationen vel vidende, at der er en række sikkerhedsmæssige aspekter, der skal løses, før det er realiserbart i produktion.
Formålet med at gøre meddelelserne tilgængelige på de 2 platforme, var foruden at gøre dem tilgængelige for de kliniske systemer i regioner, kommuner og hos praktiserende læger også at gøre det muligt for patienten og pårørende selv at kunne se dem på sundhed.dk
Sundhed.dk’s rolle i infrastrukturen var derfor på baggrund af det anvendte cpr-nr. at hente de delte data og præsentere dem for brugeren i deres brugergrænseflade.
Vi har i POC’en ikke taget stilling til hvilke meddelelser, der er egnet til hverken den ene eller den anden form for datadeling på forespørgsel, blot vise, at det kan gøres ved at tage udgangspunkt i det velkendte meddelelsesparadigme og aktivere datadelingsparadigmet derfra.
Vi har heller ikke forholdt os til, hvor et givent meddelelseshotel bedst implementeres, men blot at det kan realiseres, og at det bør underlægges nøjagtig de samme sikkerhedsmæssige forordninger som DDS og de øvrige komponenter på NSP.
6.2.55.2.5 Datadeling på forespørgsel – Dokumentdelingsservicen (DDS)
I POC’ens datadelingsscenarier via DDS og NAS opererede vi med GGOP som meddelelsestype og lod den afsende fra Corner 1 i eDelivery infrastrukturen til Gateway’ens AP i Corner 2, hvorfra den blev sendt til selve Gateway’en. Gateway’en lagrer og transformerer meddelelsen til CPD-DK, nyudviklet HL7 CDA til ”Planer og indsatser” i Patientoverbliksprojektet. Herefter sendes den via XDS-servicen ProvideAndRegisterDocumentSet til DDS, og efterfølgende notificeres NAS med et i dette opsæt simpelt datasæt indeholdende CPR-nr., kommune og meddelelsestype, så det efterfølgende er muligt at udsøge dokumentet i DDS. Brugere af NAS, der abonnerer på meddelelser med netop dette indhold, vil efterfølgende hente NAS-beskeden ned og på baggrund af indholdet i denne afgøre, at der skal hentes et dokument i DDS.
Figur 7 Datadeling på forespørgsel – Dokumentdelingsservicen (DDS)
I POC’en var det stadig RegionSyds Cosmic produktionsinstallation, som agerede corner 1 og afsendte GGOP originalmeddelelsen frem til gateway’en i corner 2 via det tidligere beskrevne setup for eDelivery 3-corner modellen. Gateway’en udførte det ovenfor beskrevne setup ift. at få registreret den
transformerede CPD-DK i hhv. DDS og notifikation herom i NAS.
Sundhed.dk hentede dokumentet i DDS og kunne vise dette via det generelle stylesheet for CDA, cda.xsl.
PLSP agerede abonnent på NAS og kunne konstatere, at dokumentet var registreret i DDS, men eftersom der ikke var en økonomisk aftale med PLSP om at hente meddelelsen i DDS, måtte vi nøjes med det.
MedComs Testcenter havde som sundhed.dk ikke abonnement på NAS’en, men kunne i lighed med sundhed.dk udsøge meddelelserne i DDS og præsentere dem via det generelle stylesheet for CDA, cda.xsl.
Figur 8 Sekvensdiagram af datadeling på forespørgsel – Dokumentdelingsservicen (DDS)
6.2.65.2.6 Datadeling på forespørgsel – MedCom Meddelelseshotel (FHIR)
I POC’ens datadelingsscenarier via MedComs Meddelelseshotel og NAS opererede vi både med GGOP og Korrespondancemeddelelse som meddelelsestyper og lod disse afsende fra Corner 1 i eDelivery infrastrukturen til Gateway’ens AP i Corner 2, hvorfra de blev sendt til selve Gateway’en. Gateway’en lagrede og ”transformerede” (rettere indpakkede) meddelelserne til FHIR Communication-ressourcer.
Herefter sendtes de til MedComs Meddelelseshotel baseret på HAPI open source implementation af en FHIR server.
Efterfølgende notificeres NAS i lighed med DDS setup’et med et i dette opsæt simpelt datasæt indeholdende CPR-nr, kommune og meddelelsestype, så det efterfølgende er muligt at udsøge ressourcerne på FHIR-serveren. Brugere af NAS, der abonnerer på meddelelser med netop dette indhold, vil efterfølgende hente NAS-beskeden ned og pba indholdet i denne afgøre, at der skal hentes ressourcer i Meddelelseshotellet. Abonnenten vil derefter hente disse ressourcer og præsentere dem i sit system.
Ansat Cosmic DDS
Send GGOP
Send GGOP
AS4(Ack)
KMD AP GW AP
Send AS4(SBDH(GGOP))
ProvideAnd- Register-DocumentSet
(GGOP)
GW
Send AS4(SBDH(GGOP))
NAS
SetNotification (MedCom-Message, DDS)
Abonnent
system RegSyd Ansat
ReadTopic(MedCom-Message, FHIR-Hotel, Patient)
RerieveDocumentSet(GGOP) Notify(NewMessage)
GetMessage()
Figur 9 Datadeling på forespørgsel – MedCom Meddelelseshotel (FHIR)
I POC’en var det stadig RegionSyds Cosmic produktionsinstallation, som agerede corner 1 og afsendte hhv. GGOP og XDIS91 originalmeddelelserne frem til gateway’en i corner 2 via det tidligere beskrevne setup for eDelivery 3-corner modellen. Gateway’en udførte det ovenfor beskrevne setup ift. at få registreret de transformerede ressourcer i hhv. Meddelelseshotellet og notifikation herom i NAS.
Sundhed.dk hentede ressourcerne på FHIR-hotellet og kunne vise dette via de dedikerede stylesheets for MedComs OIOXML meddelelser.
PLSP agerede abonnent på NAS og kunne konstatere, at dokumentet var registreret i FHIR-hotellet, og derefter kunne PLSP hente meddelelserne og præsentere dem for sine brugere.
Tilsvarende var det muligt for sundhed.dk at udsøge de nytilkomne FHIR-ressourcer i meddelelseshotellet og præsentere dem for sine brugere via MedComs OIOXML stylesheets.
MedComs Testcenter havde som sundhed.dk ikke abonnement på NAS’en, men kunne i lighed med sundhed.dk udsøge meddelelserne i FHIR-hotellet og præsentere dem via MedComs eget stylesheet.
Figur 10 Sekvensdiagram af datadeling på forespørgsel – MedCom Meddelelseshotel (FHIR)
76 Deltagernes erfaringer og evaluering
Nedenfor beskrives evalueringer og vurderinger fra deltagerne i POC, herunder Connectathon d.
12/12-2018. Evalueringerne baseres på skriftlige tilbagemeldinger og afholdt fokusgruppemøde.