Indhold

Introduktion

Formål

Dette dokument beskriver hvordan man kommer i gang med at tilpasse eller videreudvikle EMR - EMH, som er en del af EMR (EHMI MeddelelsesRegistrering).

Læsevejledning

Læser forventes at have kendskab til Java softwareudvikling med anvendelse af Maven, konfiguration af WildFly og brug af docker-compose.

Komponentens struktur

Selve komponenten er delt op i følgende moduler:

...

• Domibus-integration, baseret på WSDL-fil fra "msh_schema" og jakarta.xml.ws.
• EDS-integration som er FHIR-baseret.
• DROS-integration baseret på IHE-frameworket og Apache CXF.

Beskeder, kvitteringer og standarder

Dette afsnit giver et overblik over beskeder EMR henter og sender, hvordan de er pakket ind, og hvilke standarder der er i spil.

Hvad laver komponenten?

EMR fungerer som en bro mellem tre eksterne systemer:

...

Flowet er kø-baseret: Jobs kører i faste trin, og beskeder flyttes mellem interne DB-køer (ehmi_message_queue for forretningsbeskeder og kvitteringer, eds_message_queue for forsendelsesstatus). Der er ingen intern scheduler. Hvert job trigges udefra via en HTTP-servlet.

Beskeder ind og ud

Ind (hentes)

Ud (sendes)

...

• En kvittering til modparten (ReceiptAcknowledgement/ReceiptException). En EHMI-besked, der sendes tilbage gennem Domibus til den oprindelige afsender.
• En forsendelsesstatus til EDS. En intern statusmelding (FHIR AuditEvent) om, at en besked er hentet, gemt eller sendt.

Kvitteringer til modparten

En kvittering er selv en EHMI StandardBusinessDocument (se indpakning nedenfor). Der findes to slags:

...

• I SBDH via Scope-elementer: Kvitteringen får sit eget MESSAGEIDENTIFIER, mens den oprindelige beskeds id bevares i ORIGINALMESSAGEIDENTIFIER.
• I selve kvitterings-payloaden via felter som OriginalMessageIdentifier, OriginalDocumentIdentifier og CollaborationIdentifier.

Sådan er en besked pakket ind

En besked består af tre indpakningslag: Ydre, indre og payload. De to sidste lag er begge base64-encoded.

Konkret betyder det:

1. Forretnings-payloaden base64-kodes ind i SBDH'ens BinaryContent.
2. Hele SBDH-dokumentet serialiseres til XML og base64-kodes ind i ebMS-payloaden (PartInfo/value).
3. Det hele lægges i en ebMS3 UserMessage og sendes som AS4 gennem Domibus.

Ved modtagelse foldes lagene ud i omvendt rækkefølge.

Centrale begreber

Begreberne stammer fra to forskellige lag: ebMS3 (den ydre AS4-konvolut) og SBDH (den indre EHMI-besked).

ebMS3-laget (AS4-konvolutten)

• CollaborationInfo: Beskriver hvilken forretningsproces beskeden hører til.
• PartyId: Identificerer AP (afsender/modtager på AS4-niveau).
• MessageProperties: Nøgle/værdi-metadata på hele beskeden, fx originalSender og finalRecipient.

SBDH-laget (EHMI-beskeden)

• StandardBusinessDocument (SBD): Det yderste EHMI-element eren StandardBusinessDocumentHeader + et BinaryContent (den base64-kodede forretnings-payload).
• StandardBusinessDocumentHeader (SBDH): Routing- og metadata-header: Sender, Receiver, DocumentIdentification og BusinessScope.
• BusinessScope: Hvert Scope har en Type (fx SENDERID, RECEIVERID, MESSAGEIDENTIFIER, ORIGINALMESSAGEIDENTIFIER, XDS-METADATA, StatisticalInformation) og et InstanceIdentifier. Det er her fx XDS-metadata til DROS og korrelationen mellem besked og kvittering ligger.
• Partner-identifikation (ehmiPartner): SBDH's egen afsender/modtager: en Identifier med Authority (typisk GLN-baseret). Dette er ikke det samme som PartyId i Domibus-beskederne.

Standarder og namespaces

Skemaerne ligger i msh_schema/src/main/resources/.

...

• OASIS ebMS 3.0 Core: http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html
• OASIS AS4-profil: http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/AS4-profile-v1.0.html
• UN/CEFACT / GS1 Standard Business Document Header: https://www.gs1.org/standards/edi-xml/standard-business-document-header
• ISO 6523 (identifikations-schemes, iso6523-actorid-upis): https://www.iso.org/standard/25773.html
• HL7 FHIR R4: https://hl7.org/fhir/R4/
• IHE ITI-41 (Provide and Register Document Set-b): https://profiles.ihe.net/ITI/TF/Volume2/ITI-41.html
• Domibus (eDelivery Access Point): https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/Domibus
• MedCom EHMI: https://ehmi.dk//

Hvor i koden

Vigtige klasser i koden hvor de enkelte dele af besked-flowet håndteres:

• Parsing/marshalling af SBD: ehmi/EhmiMessageParser.java, ehmi/SbdUtil.java.
• Bygning af kvitteringer og response-SBD: ehmi/EhmiMessageFactory.java.
• Validering: validation/EhmiDocumentValidator.java.
• Domibus (submit/retrieve, ebMS-konvolut): domibus/DomibusService.java, integrations/domibus/DomibusWsPluginClient.java, profil i domibus/DomibusMessageProfile.java.
• Jobs: job/fetchjob/, job/savejob/, job/sendjob/, job/edsjob/. Wiring i msh_adapter/.../setup/JobsConfig.java.
• Genererede JAXB-klasser: pakkerne dk.nsp.msh.ehmisbdh (EHMI/SBDH) og org.oasis_open.docs.ebxml_msg... (ebMS3), genereret fra skemaerne i msh_schema.

Opsætning af udviklingsmiljø

Projektet ligger som nspop git-repository på følgende adresse: 

...

Som en del af bygget afvikles der unit tests.

Afvikling

Maven bygger war-filerne, som kan deployes med docker compose. Dette gøres lokalt med kommandoen:

...

Det er muligt at sætte en remote debugger op på port 5056.

Integrationstests

Integrationstesten kan afvikles op imod et kørende system på localhost med følgende kommando:

...

Pt. er det et udestående omkring at definerer profiler, så testen kan køre mod udviklingsmiljøerne på test1 og test2, da disse i skrivende stund endnu ikke er deployed.

Projektstruktur

For nærmeste beskrivelse af projektets struktur og opbygning, se Design- og Arkitekturbeskrivelsen.

Database

Databasemodellen styres ved hjælp af liquibase. Det betyder, at når der skal laves ændringer til databasen, så må man ikke rette i de eksisterende skemafiler. I stedet skal der laves nye filer, der beskriver ændringerne.

...