Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
Indhold
| Table of Contents |
|---|
Introduktion
Formål
Dette dokument beskriver hvordan man kommer i gang med at tilpasse eller videreudvikle 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)
| Besked | Kilde | Hvordan |
|---|---|---|
| EHMI-forretningsbesked | Domibus | Fetch-jobbet henter ventende beskeder (listPendingMessages + retrieveMessage), parser dem og gemmer dem i køen som type EHMI. |
Ud (sendes)
| Besked | Modtager | Hvornår |
|---|---|---|
| Dokument-upload (ITI-41) | DROS | Save-jobbet uploader den indgående forretningsbesked til dokumentregisteret. |
Kvittering (ReceiptAcknowledgement / ReceiptException) | Domibus (retur til oprindelig afsender) | Save-jobbet opretter kvitteringen og lægger den i køen som type RECEIPT. Send-jobbet sender den. |
Forsendelsesstatus (FHIR AuditEvent) | EDS | Alle tre jobs skriver track-and-trace-hændelser til EDS-køen. Et separat EDS-job sender dem. |
...
- 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.
...
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.
...