orderNumber: 3

Tiltak og begrensninger ved EbXml-standarden

EDI 2.0 implementerer EbXml-standarden (HIS1037:2011) for kommunikasjon med aktører som ikke bruker EDI 2.0.

Re-sending

Meldinger som ikke har fått kvittering (Acknowledgement eller MessageError) vil bli sendt på nytt.

• Vi sjekker 1 gang per time hvilke meldinger som skal re-sendes.
• Vi re-sender alle meldinger som har minst 12 timer siden siste sendingsforsøk.
• Vi gjør opp til 5 forsøk på re-sending.
• Altså kan en melding være i EDI-transaksjon i opptil 72 timer.
• Etter dette vil vi gi opp utvekslingen.

Standardverdier for EbXml- og system-metadata

Du kan spesifisere verdier for innhold i EbXml-konvolutten som metadata når du sender en melding. Les om dette på siden for sending. Hvis dette ikke oppgis vil EDI 2.0 bruke noen standardverdier:

• Service, Action og Role (HIS 1209:2018) settes ut ifra forretningsdokumentets innhold.
• MshSystem (HIS 1210:2018): Norsk Helsenett Meldingstjener.
• MshVersion (HIS 1210:2018): v1.0.
• AppSystem (HIS 1210:2018) deduseres ut ifra API-headeren nhn-source-system.
• AppVersion (HIS 1210:2018) deduseres ut ifra API-eaderen nhn-source-system.

Kryptering og signering

Vi krypterer selve forretningsdokument med symmetrisk AES med 256-bytes nøkkel og CBC-mode (OID=2.16.840.1.101.3.4.1.42), mens tillatt mottaker (CmsRecipient) krypteres med SHA256RSA med deres offentlige sertifikat.

Vi signerer med SHA256RSA med vårt private sertifikat.

Prosedyre for identifikasjon av avsender og mottaker i EbXml-konvolutten ved avvik i adressering

Den korrekte måten å spesifisere avsender i EbXml på, er å skrive en enkelt HER-Id-verdi i xml-pathen <From>/<PartyId type="HER">. Den korrekte måten å spesifisere mottaker er å skrive en enkelt HER-Id-verdi i xml-pathen <To>/<PartyId type="HER">. Ved mottak av EDI-meldinger som har avvik i adresseringen, ønsker vi likevel å identifisere hvem de faktiske kommunikasjonspartene er, slik at vi kan melde fra til deg som mottaker at noen har sendt deg en melding med avvik. Avvikets meldes tilbake til avsender ved å sende en MessageError, men bare hvis også avsenderen er identifiserbar.

• Hvis det finnes ett enkelt innslag av <PartyId type="HER">, hentes kommunikasjonsparten ut ifra dennes verdi.

• Hvis det finnes flere innslag av <PartyId type="HER">, hentes kommunikasjonsparten ut ifra verdien som oppgis i det første innslaget.

• Hvis det ikke finnes noen innslag av <PartyId type="HER">, vil vi prøve å sjekke innslag av <PartyId type="ENH">.

  • Hvis det finnes ett enkelt innslag av <PartyId type="ENH">, hentes kommunikasjonsparten ut ifra dennes verdi.
  • Hvis det finnes flere innslag av <PartyId type="ENH">, hentes kommunikasjonsparten ut ifra verdien som oppgis i det første innslaget.

• Hvis det ikke finnes noen innslag av enten <PartyId type="HER"> eller <PartyId type="ENH">, gir vi opp å identifisere kommunikasjonsparten.

Etter at vi har identifisert en kommunikasjonspart (også de som har adressert riktig i EbXml), vil vi prøve å hente den nødvendige informasjonen om kommunikasjonsparten fra Adresseregisteret. Det er en forutsetning at kommunikasjonsparten har tilstrekkelig mye informasjon oppgitt for at vi skal kunne gjennomføre utvekslingen.

For å kunne slå opp informasjon om en kommunikasjonspart, må vi være i stand til å lese inn verdien i EbXml-konvolutten som et heltall.