FHIR Chat · Messaging og HER-id · norway

Stream: norway

Topic: Messaging og HER-id

Eirik Myklebost (Aug 31 2021 at 10:33):

Hei.

I NAV er vi i en eksperimentell fase for meldingsutveksling i FHIR og vi ser på hvordan vi kan basere profilene på noe av arbeidet rundt Dialogmelding og Tjenestebasert adressering. I best-practice nevnes messaging, men det ser ikke ut å være noe aktivitet rundt dette og vi prøver oss derfor litt frem på egenhånd.

En FHIR MessageHeader har få required felt, men den krever en source.endpoint og destionation.endpoint av datatype URL for å identifisere sender og mottaker. For å være i henhold til Tjenestebasert adressering vil det her være fornuftig å bruke en fully-qualified HER-id?
Eksempel: urn:oid:2.16.578.1.12.4.1.2.131725.

En slik fully-qualified HER-id er en gyldig URL og kan regnes som en logical URI slik det er beskrevet i speken:

If MessageHeader.source.endpoint and MessageHeader.destination.endpoint, are literal URLs, then they SHOULD identify the addresses to which messages can be delivered. If they are logical URIs (i.e. non-dereferenceable), message delivery intermediaries must know how to deliver the message to the destination application.

Thomas Tveit Rosenlund (Sep 02 2021 at 04:53):

Jeg tenker at endpoint må beskrive en adresse som kan benyttes til å faktisk sende meldingen @Eirik Myklebost . I norsk sammenheng er det en mailadresse til enepunktet (meldingstjener), altså en epostadresse. HERid bør ligge i destination.receiver

Thomas Tveit Rosenlund (Sep 02 2021 at 05:12):

For eksempel slik (fra https://simplifier.net/velferdteknologiskknutepunktr4/vkpmessageheader).

"receiver":{
   "identifier":{
      "system":"urn:oid:2.16.578.1.12.4.1.2",
      "value":"102287"
   },
   "display":"Sykepleietjeneste, pleie- og omsorg"
}

Men VKP har heller ikke løst endpoint utfordringen, det er jo mange tilfeller i Norge hvor receiver er kjent men endepunktet ikke er kjent. Kanskje noe vi burde gi tilbakemelding til HL7 International om? På den andre siden så kan vi jo slå opp endepunktet i Adresseregisteret hvis vi har HERid...

Eirik Myklebost (Sep 02 2021 at 09:26):

Jeg har allerede sett på VKP sin MessageHeader og har inntrykk av at den jobber imot standarden. F.eks bruker den sender og destination.receiver istedenfor source.endpoint og destination.endpoint slik standarden legger opp til. Det virker som dette er gjort med ønske om å bruke datatypen Identifier istedenfor URI til HER-id.

Ved å bruke sender/receiver elementene må fremdeles source- og destination-endpoint ha verdier, å sette dette til en epost-adresse bare for å "ha noe der" bidrar til å gjøre meldingen mer verbose og kompleks.
VKP MessageHeader er heller ikke gyldig R4. Det ser ut som en blanding mellom STU3 og R4 ved at den fremdeles har MessageHeader.receiver fra STU3.

Slik jeg tolker standarden er de valgfrie elementene sender, enterer, author, responsible, destination.target, destination.receiver ment for auditing og/eller intern-ruting.

De påkrevde elementenesource.endpoint og destination.endpoint brukes til å identifisere systemene som kommunikasjonen går mellom. Dette kan enten være en resolvable URL til en FHIR-Server, eller en id til en logisk entitet, slik som HER-id. Ref:

The only requirement for the transfer layer is that requests are sent to a known location and responses are returned to the source of the request. This specification considers the source and destination applications as logical entities, and the mapping from logical source and destination to implementation specific addresses is outside the scope of this specification.

Under søkeparametre til MessageHeader speken er følgende beskrivelser brukt:

| destination-uri | uri | Actual destination address or id |
| source-uri | uri | Actual message source address or id |

Eirik Myklebost (Sep 02 2021 at 09:39):

Litt mer kontekst: Vi ser på mulighetene for å bruke et FHIR RESTful API som broker for meldinger, eksemplene i spesifikasjonen legger opp til bruk av destination og source.

GET [base]/Bundle?message.destination-uri=[rcv]&_lastUpdated=>2015-03-01T02:00:02+01:00

Thomas Tveit Rosenlund (Sep 02 2021 at 11:22):

vkp-MessageHeader ble skrevet som STU3 profil, det ser ut som oversettelsen til R4 har det blitt introdusert en feil i forhold til hvordan receiver ligger i StructureDefinition. Jeg la inn en issue på akkurat dette med receiver tidligere idag, siden den ligger på feil sted i forhold til R4 spec:
https://github.com/HL7Norway/Velferdsteknologi/issues/12

Eirik Myklebost said:

De påkrevde elementenesource.endpoint og destination.endpoint brukes til å identifisere systemene som kommunikasjonen går mellom. Dette kan enten være en resolvable URL til en FHIR-Server, eller en id til en logisk entitet, slik som HER-id. Ref:

The only requirement for the transfer layer is that requests are sent to a known location and responses are returned to the source of the request. This specification considers the source and destination applications as logical entities, and the mapping from logical source and destination to implementation specific addresses is outside the scope of this specification.

Under søkeparametre til MessageHeader speken er følgende beskrivelser brukt:

| destination-uri | uri | Actual destination address or id |
| source-uri | uri | Actual message source address or id |

I Norsk sammenheng med meldingsformidling over ebXML er det i praksis SMTP adresser som identifiserer endepunktene. Skal man kjøre transporten over andre protokoller blir det selvfølgelig en kutt annen diskusjon. De aller fleste meldinger i Norge vil ikke ha en resolvable URL som endepunkt men en smtp adresse. eResept benytter vel en SOAP adresse som endepunkt.

Igjen ved meldingsformidling i Norge er det helt andre krav til hvilken informasjon som skal være med i meldingshode (eller MessageHeader) så sender/receiver elementene er ikke bare til auditing men også til faktisk adressering og sortering av meldingene til riktig mottaker i organisasjonen, så det kan hende at det vil stilles krav om innhold i disse i en eventuell norsk profil.

Vanlig praksis i dag vil jo ofte være at fagsystemet ikke har noen forhold til de faktiske endepunktene, men adresserer til en organisasjon, da er sender og receiver den beste plasseringen for den informasjonen. Hvis man skal benytte HERid til routing kan jo HERid ligge i MessageHeader.receiver, men i utgangspunktet ville det være mest ryddig om HERid ligger i destination.receiver som en identifier referanse og at en eventuell meldingsformidler fyller inn det faktiske endepunktet (smtp adressen).

Igjen i Norsk sammenheng er det vanlig at meldingshodet fylles ut av fagsystemet som egentlig ikke har noe forhold til faktiske endepunkt, derfor er det litt uheldig at FHIR standarden setter krav om endepunktadresser i MessageHeader, selv om disse bør ha verdi når faktisk routing skal foregå.

Thomas Tveit Rosenlund (Sep 02 2021 at 11:37):

Eirik Myklebost said:

Litt mer kontekst: Vi ser på mulighetene for å bruke et FHIR RESTful API som broker for meldinger, eksemplene i spesifikasjonen legger opp til bruk av destination og source.

GET [base]/Bundle?message.destination-uri=[rcv]&_lastUpdated=>2015-03-01T02:00:02+01:00

Jeg tror dette use-caset ligger litt på siden av mainstream meldingsformidling i Norge idag. Vi bør antakelig tenke oss godt om før vi forsøker å bruke identifikatorer i endepunktsadressene, selv om det er mulig å angi en identifikator som en url. Men som jeg skriver over, en rekke systemer vil ikke ha noe forhold til de faktiske endepunktsadressene og må kanskje fylle ut HER-id i destination.receiver og source.endpoint slik dere foreslår.

Eirik Myklebost (Sep 02 2021 at 12:01):

Standarden sier at source.endpoint og destination.endpoint ikke trenger å være faktisk adresser, og hvis det er det tolker jeg det til å være URL til en FHIR Server, ikke en SMTP eller annen protokoll. FHIR messaging legger ingen føringer på hvilken transport protokoll som brukes, og dette er forståelig siden meldingene kan "overleve" bruken av protokoll (SMTP, HTTP, MQ, Kafka etc.).

The exact mechanism of transfer is irrelevant to this specification, but may include file transfer, HTTP based transfer, MLLP (HL7 minimal lower layer protocol), MQ series messaging or anything else.

En FHIR melding kan gå via flere mellomlag og forskjellige protokoller på sin vei fra sender til mottaker, f.eks Sender -> Kafka -> HTTP -> MQ -> destination. Det er derfor naturlig å referere til sender og mottaker som logiske entiteter uavhengig av transport protokoll, og metadata relatert til protokollen ligger da i det "ytre lag" og ikke embedded i selve FHIR meldingen.

Thomas Tveit Rosenlund (Sep 02 2021 at 12:05):

@Eirik Myklebost absolutt, jeg prøver ikke å si at det skal være SMTP

Thomas Tveit Rosenlund (Sep 02 2021 at 12:11):

Eirik Myklebost said:

En FHIR melding kan gå via flere mellomlag og forskjellige protokoller på sin vei fra sender til mottaker, f.eks Sender -> Kafka -> HTTP -> MQ -> destination. Det er derfor naturlig å referere til sender og mottaker som logiske entiteter uavhengig av transport protokoll, og metadata relatert til protokollen ligger da i det "ytre lag" og ikke embedded i selve FHIR meldingen.

Enig, og akkurat dette får meg til å tenke at å sette krav om endpoint i MessageHeader egentlig er en feil. Etter min mening bør dette routes etter hvem som skal motta meldingen (for eksempel en HERid i destination.receiver), og ved hjelp av endpoint, hvis man kjenner til et faktisk endepunkt. I en multimodal routing vil antakelig den faktiske endepunktsadressen endre seg flere ganger underveis.

Eirik Myklebost (Sep 02 2021 at 12:20):

Vi er nok enige. Det som er forvirrende er bruken av ordet endpoint, siden standarden sier det kan være enten en resolvable URL (endepunkt) eller en logisk-id. I mitt forslag er det altså snakk om å bruke dette som ID til kommunikasjonsparten (HER-id), ikke et faktisk endepunkt. At datatypen er URL og ikke URI skaper også forvirring, men dette er bare pga. historiske årsaker, det skal nemlig tolkes som en URI.

Hadde det vært slik at endpoint het noe annet og var en choice type med URL og Identifier hadde nok dette vært tydeligere, men det er nå slik standarden er i dag.

Thomas Tveit Rosenlund (Sep 02 2021 at 12:26):

Ja, tror det og med dagens utforming av standarden kan det godt hende at en id her er den beste løsningen.

Min tolkning av endpoint har alltid vært faktiske endepunktsadresser på grunn av definisjonen av Endpoint ressursen altså at man kan legge en Endpoint.address direkte inn i MEssageHeader.destination.endpoint. I definisjonen av Endpoint ressursen er det helt tydelig at endepunktsadressen er tenkt å være en faktisk adresse.
https://www.hl7.org/fhir/endpoint.html

Eirik Myklebost (Sep 02 2021 at 12:27):

Et eksempel fra NHS der de bruker en id som endpoint.

endpoint value="urn:nhs-uk:addressing:ods:RFM8C2

Eirik Myklebost (Sep 02 2021 at 12:39):

Jeg har sett på Endpoint tidligere, men sliter med å se sammenhengen til MessageHeader, den eneste koblingen jeg har funnet er følgende setning:

Messaging: (currently defined in the Message Header, but only as the address)

Hvis Endpoint ressursen var ment å bli brukt i MessageHeader hadde jeg forventet type Reference(Endpoint) istedenfor URI.

Eirik Myklebost (Sep 02 2021 at 12:42):

@Thomas Tveit Rosenlund , men tenker du at det er riktig av oss i NAV å fortsette i dette sporet med fully-qualified HER-id som "endpoint"? Så kan vi eventuelt ta opp tråden senere der vi presentere et forslag vi kan samarbeide med og forhåpentligvis utarbeide en nasjonal base profil for MessageHeader?

Thomas Tveit Rosenlund (Sep 03 2021 at 04:28):

Eirik Myklebost said:

Jeg har sett på Endpoint tidligere, men sliter med å se sammenhengen til MessageHeader, den eneste koblingen jeg har funnet er følgende setning:

Messaging: (currently defined in the Message Header, but only as the address)

Hvis Endpoint ressursen var ment å bli brukt i MessageHeader hadde jeg forventet type Reference(Endpoint) istedenfor URI.

Nettopp, det er akkurat det som er sammenhengen slik jeg forstår dokumentasjonen, for messaging så kan Endpoint benyttes til å angi alle slags endepunkter, inkludert endepunkter for messaging.

Thomas Tveit Rosenlund (Sep 03 2021 at 05:19):

Eirik Myklebost said:

Thomas Tveit Rosenlund , men tenker du at det er riktig av oss i NAV å fortsette i dette sporet med fully-qualified HER-id som "endpoint"? Så kan vi eventuelt ta opp tråden senere der vi presentere et forslag vi kan samarbeide med og forhåpentligvis utarbeide en nasjonal base profil for MessageHeader?

Litt usikker av flere grunner.

Vi må kanskje få ferdigstilt denne:
https://github.com/HL7Norway/basisprofiler-r4/blob/herid.namingsystem/NamingSystem/no-basis-herid.namingsystem.xml

Har du noen gode innspill til diskusjonen?
https://github.com/HL7Norway/basisprofiler-r4/issues/36

Hvis dette skal være fast praksis, noe jeg er litt skeptisk til siden jeg heller ville hatt en faktisk identifikator i dette tilfellet, så må vi antakelig veilede her (men jeg er usikker på om dette egentlig er beste praksis):
https://github.com/HL7Norway/best-practice/blob/master/docs/HER-id.md

Har du innspill @Espen Stranger Seland

Thomas Tveit Rosenlund (Sep 03 2021 at 05:45):

Hvis denne går igjennom og endpoint blir valgfri i R5, vil det antakelig være lurt å legge inn HER-id som en identifier referanse?
https://jira.hl7.org/browse/FHIR-26898

Espen Stranger Seland (Sep 03 2021 at 06:27):

I sin enkleste form er HER-id er en business identifier som kan benyttes for å finne et endpoint ved oppslag - ett eller flere (ebXML/SMTP, WS, REST-API etc.)

I Endpoint-ressursen ville det vært naturlig å benytte HER-id (Endpoint.identifier), da man kunne laget en katalog (Adresseregisteret), men slik FHIR er nå det man oppgir URL direkte for endpoint i MessageHeader faller HER-id mellom barken og veden. Én HER-id ville uansett vært gyldig for flere endpoint slik det er i dag, og ikke unik. Og en endpoint-URL vil uansett være unik for alle praktiske formål, så jeg vil tro at den nesten kan fungere som en business identifier i seg selv.

Slik er det egentlig også for f.eks. meldinger over ebXML, der "fysisk" endpoint oppgis i selve sendingen ("legevakt@kommune.no") og HER-id kan ses på som en redundant opplysning i ebXML-konvolutten (men ligger i selve meldingen/dokumentet som business identifier, knyttet til/under organisasjon).

MessageHeader blir i så måte litt lik, der man (etter evt oppslag) kun trenger den faktiske endpoint-adressen.

Eirik Myklebost (Sep 03 2021 at 10:41):

@Espen Stranger Seland, jeg refererer til mine tidligere kommentarer for min tolkning; source.endpoint kan enten være enten en "fysisk" adresse eller en logisk-id (URI), i norsk sammenheng er HER-id en logisk-id som er alt som trengs for å rute meldingen uavhengig av transport protokoll. At det heter Endpoint og har URL som datatype er forvirrende/uheldig, men standarden er konsis på at det kan være en ID og ikke bare en resolvable URL.

MessageHeader er kandidat til å bli Normative i R5, så det blir spennende å se hva de legger seg på. Jeg foreslår at vi spør våre internasjonale venner ved å lage en topic på fhir-messages for å oppklare rundt tiltenkt bruk av endpoint, logisk-id og eventuell relasjon til Endpoint-ressursen.

Espen Stranger Seland (Sep 03 2021 at 11:49):

Enig at det burde være en URI, og vi kunne brukt f.eks. "urn:no:nhn:ar:her:123456" eller noe lignende. Og helst bare i de tilfellene der man ikke kan/ønsker å oppgi "fysisk" endpoint. Samhandlingsarkitekturen for meldingsutveksling har en godt fleksibilitet, men den gir også noen ulemper ved at man ikke trenger å være så eksplisitt. FHIR sier jo "The id may be a non-resolvable URI for systems that do not use standard network-based addresses.", så vi kommer vel uansett rundt det ved å utforme det som URL ("http://nhn.no/ar/her/123456" eller lignende).

@Thomas Tveit Rosenlund @Øyvind Aassve og andre: Bør vi spille inn at URI bør brukes for MessageHeader.destination.endpoint med fler i R5? URL er jo subset av URI, så det burde dekke begge.

Eirik Myklebost (Sep 03 2021 at 12:00):

Det jeg lurer på er om bruken av URL datatype her er relatert til Canonical URLs, merk følgende:

Some resource types have a defined element url which is the 'canonical URL' that always identifies the resource. This is a special kind of Business Identifier. Note that the element actually contains a URI, but is named url for legacy reasons.

Dette samsvarer med bruken av URI ellers i MessageHeader beskrivelsen. F.eks søkeparametrene destination-uriog source-uri.

Thomas Tveit Rosenlund (Sep 03 2021 at 12:17):

Espen Stranger Seland said:

Thomas Tveit Rosenlund Øyvind Aassve og andre: Bør vi spille inn at URI bør brukes for MessageHeader.destination.endpoint med fler i R5? URL er jo subset av URI, så det burde dekke begge.

Ja, det kunne vært en URI, men jeg tenker også at hvis det legges in fleksibilitet i forhold til destination.endpoint source.endpoint slik som foreslått på HL7 Jira så vil det være mer naturlig å benytte en identifier referanse for å henvise til noe som ikke har eller man ikke kjenner til en faktisk adresse. Det gir kanskje noen utfordringer knyttet til søk, siden man ikke har et spesifikt element man alltid kan søke på, men siden det er tilllatt både med id'er og faktiske adresser i endpoint er det ikke vanntett det heller. Hvis man søker på id vil man ikke få meldinger adressert med faktiske adresser og vise-versa.

Thomas Tveit Rosenlund (Sep 03 2021 at 12:19):

Jeg tror vi må følge med på WGM neste gang om hva som skjer med MessageHeader og kanskje starte en diskusjon her på chatten på forhånd. Personlig støtter jeg @Cooper Thompson sitt forslag: https://jira.hl7.org/browse/FHIR-26898

Eirik Myklebost (Sep 03 2021 at 12:21):

Thomas Tveit Rosenlund said:

Jeg tror vi må følge med på WGM neste gang om hva som skjer med MessageHeader og kanskje starte en diskusjon her på chatten på forhånd. Personlig støtter jeg Cooper Thompson sitt forslag: https://jira.hl7.org/browse/FHIR-26898

Det virker som Cooper har en tolkning av at endpoint må være en resolvable URL og ikke en logisk id, som er det han ønsker å bruke.

Thomas Tveit Rosenlund (Sep 09 2021 at 05:34):

Eirik Myklebost said:

Thomas Tveit Rosenlund said:

Jeg tror vi må følge med på WGM neste gang om hva som skjer med MessageHeader og kanskje starte en diskusjon her på chatten på forhånd. Personlig støtter jeg Cooper Thompson sitt forslag: https://jira.hl7.org/browse/FHIR-26898

Det virker som Cooper har en tolkning av at endpoint må være en resolvable URL og ikke en logisk id, som er det han ønsker å bruke.

Ja, det han skriver i Jira saken sammenfaller tilsynelatende med det jeg mener om hvordan MessageHeader bør brukes. Regner med at en diskusjon på Chat + WGM røyker ut forskjellige meninger om hvordan dette bør fungere, og at det er mulig å komme til en konklusjon om hvordan dette bør utformes for fremtiden (R5).

Eirik Myklebost (Sep 14 2021 at 13:19):

Har opprettet en topic på fhir-messages streamen, dere må gjerne komme med innspill der @Thomas Tveit Rosenlund , @Espen Stranger Seland .

Thomas Tveit Rosenlund (Sep 15 2021 at 07:01):

Mange viktige momenter i den diskusjonen og svært godt underlag i starten av tråden @Eirik Myklebost

Eirik Myklebost (Sep 20 2021 at 10:29):

@Thomas Tveit Rosenlund , @Espen Stranger Seland Var diskusjonen i fhir-messages noe oppklarende?

Jeg skal prøve å oppsummere det jeg plukket opp:

1. Det virker som det er en enighet blant John M. og Lloyd M. om at endpoints i source/destination kan være IDer (URI) eller URL.
2. At endpoint har datatypen URL og ikke URI er en feil i spec og bør endres.
3. Cooper T. er opptatt av scenarioet med mellomledd (intermediaries). Hvis senderen har en Business-ID (f.eks HER-id) holder det å referere til denne i destination.endpoint og mellomleddet kan rute meldingen umodifisert videre. Dersom det er behov for å adressere mellomleddet foreslår John M. å pakke meldingen inn i en annen melding som er addressert til mellomleddet. Her vil jeg også trekke inn davinci-alerts ig som enda et løsningsforslag.
4. Kevin M. tolker at endpoint må være en resolvable URL og har derfor gjort det på samme måte som i VKP ved å bruke Reference (sender og receiver) istedenfor endpoint. Dette strider med det John M. og Lloyd M. sier er intensjonen.

Hvilken oppfatning sitter dere med?

Thomas Tveit Rosenlund (Sep 20 2021 at 10:55):

Jeg tenker diskusjonen om de to Jira sakene blir avgjørende for hva vi bør anbefale her.

Det er ikke noe direkte feil med å ha en identifikator med en prefix i source.endpoint, men jeg synes ikke nødvendigvis det er en god løsning av den grunn :-) Jeg synes forslag til John M. har styrker og svakheter, det øker kompleksiteten og setter fingeren på at MessageHeader kanskje bør rendyrke sitt mandat noe bedre. Ideelt sett burde MessageHeader kanskje ikke inneholde direkte endepunkter i det hele tatt siden rutingen svært sjelden vil foretas av det semantiske laget men skal håndteres på underliggende lag og identifisering av hvem (organisasjon/helsetjeneste) som skal motta/sende burde være tilstrekkelig?

Espen Stranger Seland (Sep 20 2021 at 17:12):

WGM onsdag Q3 er det som ser ut som størst sjanse for disse issuene (har ikke spurt rundt ennå). Jeg kommer til å være der uansett.
https://confluence.hl7.org/display/MnM/MnM+Agenda+WGM+202109+Virtual

Eirik Myklebost (Oct 08 2021 at 16:38):

Espen Stranger Seland said:

WGM onsdag Q3 er det som ser ut som størst sjanse for disse issuene (har ikke spurt rundt ennå). Jeg kommer til å være der uansett.
https://confluence.hl7.org/display/MnM/MnM+Agenda+WGM+202109+Virtual

Ble dette temaet nevnt i WGM?

Espen Stranger Seland (Oct 11 2021 at 07:35):

Nei. Har dog ikke sjekket om det er noe bevegelse på Jira siden da.

Last updated: Apr 12 2022 at 19:14 UTC