Konfigurasjon av EDI 2.0

NB! Denne funksjonaliteten er under utvikling, og kan gjennomgå brekkende endringer. Benytt "api-version"-headeren 2-vNext i dine API-kall for å teste det ut.

Detaljert API-avtrykk finnes på Swagger-siden.

Du kan konfigurere deler av hvordan EDI 2.0 skal oppføre seg som din meldingstjener. Det kreves en konfigurasjon per HER-Id.

Konfigurasjon bør oppdateres regelmessig. Vi anbefaler at du definerer ønsket konfigurasjon deklarativt, og sender denne inn ved hver oppstart av applikasjonen.

Send inn meldingstjener-konfigurasjon

POST /MshConfiguration

Skriver de oppgitte konfigurasjonene til EDI 2.0 sin meldingstjener.

Hvilken måte vil du motta beskjed om nye meldinger på?

Bruk feltet receiveNotificationChannel. Denne vil fortløpende utvides med flere mulige verdier.

• ApiPolling: Du "poller" med kall til endepunktet /Messages (Les mer om endepunktet på siden for API-endepunkt).
• Kafka: Du konsumerer en kafka-topic. NB! Kafka-topic er bare tilgjengelig internt i NHN.

Vil du vite om meldinger til deg som er avvist eller som ikke kunne leveres på grunn av feil?

Bruk feltet receiveRefusedMessageNotices. Hvis denne er true, vil du kunne hente ut informasjon om meldinger som er adressert til din HER-id, men som ikke vil bli levert videre av EDI 2.0.

Du kan motta informasjon om avviste og ikke-leverte meldinger ved å benytte endepunktet GET /Messages/notices. Les mer på siden for Hente informasjon om innkommende meldinger.

Vil du avvise visse meldinger?

Bruk feltet rejectMessageFilters. Her kan du oppgi nøkler (dictionary/key) som indikerer hva slags felt du vil avvise, og verdier (dictionary/value) som indikerer hvilke av verdiene i feltet som skal avvises. I øyeblikket tilbys disse filterene som nøkler:

• MessageFunction - Oppgi koder fra Helsedirektoratets kodeverk 8279 - "Meldingens funksjon".
  • For en melding mottatt over tradisjonell EDI sjekkes dette mot Action fra EbXml-konvolutten, som benytter kodeverk 8279 (spesifisert i HIS1209:2018). Merk at Action strengt tatt kan være feilmarkert eller mangle verdi. I slike tilfeller vil Meldingstjener ikke avvise meldingen.
  • For en melding mottatt fra en annen API-bruker av EDI 2.0 sjekkes dette mot feltet i fagmeldingen der meldingens funksjon spesifiseres, som varierer per meldingstype. For meldinger som implementerer standarden for hodemelding (HIS80601:2006) vil dette ligge under MsgHead/MsgInfo/Type.
• XmlNamespace - Oppgi xml namespace for meldingsskjema.
  • For en melding mottatt over tradisjonell EDI sjekkes dette mot Schema/location i EbXml-konvolutten der namespace er påkrevd (HIS1210:2018). Grunnstandarden åpner imidlertid opp for at dette feltet kan mangle, og i så fall vil Meldingstjener ikke avvise meldingen.
  • For en melding mottatt fra en annen API-bruker av EDI 2.0 sjekkes dette mot namespace definert i meldingen. For meldinger som implementerer standarden for hodemelding (HIS80601:2006) står dette i første node under Document/RefDoc/Content, mens for andre meldingsstandarder står dette i rot-noden.

Når EDI 2.0 avviser en melding fra en EDI-avsender, sendes negativ transportkvittering (MessageError) med feilkode NotSupported. Når EDI 2.0 avviser en melding fra en EDI 2.0-avsender, settes mottakerstatus til Rejected.

Eksempel på bruk av rejectMessageFilters:

Her spesifiseres det at vi vil avvise en rekke verdier fra kodeverk 8279 som sendes i sektor, men som ligger utenfor standarden for Svarrapport versjon 1.4. Det spesifiseres også at vi vil avvise namespacet som hører til den utgåtte 1.3-versjonen av svarrapport:

{
    MessageFunction: ["SVAR_KKL", "SVAR_CYT", "SVAR_MBIO", "SVAR_HIST", "SVAR_OBD", "IMTR", "SVAR_IMTR"],
    XmlNamespace: ["http://www.kith.no/xmlstds/labsvar/2008-12-01"]
}