Rammeverk for elektronisk meldingsutveksling i helsevesenet

Transkript

1 Rammeverk for elektronisk meldingsutveksling i helsevesenet Basert på ebxml Versjon oktober 2002 Status: "For utprøving" KITH Rapport 25/02 ISBN

2 2

3 KITH-rapport TITTEL Rammeverk for elektronisk meldingsutveksling i helsevesenet Status: "For utprøving" Forfatter Espen Stranger Seland, m.fl. Oppdragsgiver Sosial- og helsedirektoratet Standardiserings- og samordningsprogrammet (SSP) Rapportnummer R 25/02 ISBN Godkjent av Jacob Hygen adm. direktør Sammendrag URL Dato 18. oktober 2002 Antall sider 37 Kvalitetssikret av Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset 7005 Trondheim Besøksadresse Sverresgt 15, inng G Telefon Telefaks e-post firmapost@kith.no Foretaksnummer Prosjektkode Gradering Åpen Dette dokumentet beskriver et rammeverk for elektronisk kommunikasjon for benyttelse i helse- og sosialsektoren. Rammeverket inkluderer metoder for sending og mottak av alle typer utvekslingsformater ved hjelp av en XML-konvoluttløsning. Rammeverket inneholder også retningslinjer for forretningsgang og transportsikkerhet. Rammeverket er basert på ebxml og følger sikkerhetskravene som er gitt av ENV og -3. 3

4 4

5 Forord Oslo, 18. oktober 2002 Dette er et produkt som har kommet frem i tett samarbeid mellom KITH og Rikstrygdeverket (RTV) i anledning Ei@-prosjektet (elektronisk innrapportering av sykmelding og legeerklæring). RTV har bl.a. fått hjelp av EdiSys AS med spesifikasjonsarbeide. Dette dokumentet gjør KITH Rapport 09/02 Konvolutt for meldingsutveksling (ISBN ) overflødig. Dokumentet er i versjon 0.90 Til utprøving og vil ferdigstilles etter erfaringer fra pilotdrift er gjort. Dokumentet er utarbeidet i samarbeid med Jostein Frømyr, EdiSys AS Bjørn Sundberg, EdiSys AS Torsten Kirschner, Rikstrygdeverket Arnstein Vestad, KITH Espen Stranger Seland

6 Innholdsfortegnelse FORORD... 5 INNHOLDSFORTEGNELSE... 6 FIGURER INNLEDNING BAKGRUNN MÅLSETNING LESERVEILEDNING KRAV OG FORUTSETNINGER FUNKSJONELLE KRAV BEGRENSNINGER EBXML MELDINGSTJENESTE BRUK AV EBXMLS MELDINGSTJENESTE BRUK AV EBXML-KONVOLUTT BRUK AV REFERANSER eb:cpaid eb:conversationid eb:messageid eb:reftomessageid eb:reference BRUK AV SAMHANDLINGSPLANER FUNKSJONELL ARKITEKTUR UTVEKSLINGSSCENARIER Overføring av forretningsmelding (P 1 ) med forretningssvar (P 2 ) uten kvitteringer eller feilmeldinger Overføring av forretningsmelding (P 1 ) med feil i konvolutt Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra, hvor det rapporteres feil fra applikasjon (P err ) Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra applikasjon (P akk ) EBXML KONVOLUTT SOAP:ENVELOPE SOAP:HEADER eb:messageheader ab:ackrequested ds:signature SOAP:BODY eb:manifest KODEVERK PartyId Role Services Action KVITTERING OG FEILMELDING SOAP:ENVELOPE SOAP:HEADER eb:messageheader eb:ackrequested eb:acknowledgement eb:errorlist ds:signature SIKKERHET

7 7.1. AUTENTISERING OG IKKE-BENEKTNING Autentisering på transportnivå Autentisering på meldingstjenestenivå Autentisering på applikasjonsnivå SIKRING AV KONFIDENSIALITET REFERANSER Figurer FIGUR 2 STRUKTUREN I EN MELDINGSOVERFØRING MED EBXML FIGUR 3 FUNKSJONELL ARKITEKTUR FIGUR 4 KVITTERING OG FEILRAPPORTERING FRA MELDINGSTJENESTEN FIGUR 5 KVITTERING OG FEILRAPPORTERING FRA APPLIKASJON FIGUR 6 OVERFØRING AV FORRETNINGSMELDING (P 1 ) MED FORRETNINGSSVAR (P 2 ) UTEN KVITTERINGER ELLER FEILMELDINGER FIGUR 7 OVERFØRING AV FORRETNINGSMELDING (P 1 ) MED FEIL I KONVOLUTT FIGUR 8 OVERFØRING AV FORRETNINGSMELDING (P 1 ) MED KRAV OM BEKREFTELSE FRA FIGUR 9 OVERFØRING AV FORRETNINGSMELDING (P 1 ) MED KRAV OM BEKREFTELSE FRA, HVOR DET RAPPORTERES FEIL FRA APPLIKASJON (P ERR ) FIGUR 10 KVITTERING (M AKK ) PÅ MOTTATT FEILRAPPORT FRA APPLIKASJON (P ERR ) FIGUR 11 OVERFØRING AV FORRETNINGSMELDING (P 1 ) MED KRAV OM BEKREFTELSE FRA APPLIKASJON (P AKK ) FIGUR 12HOVEDDELENE TIL SOAP-KONVOLUTTEN FIGUR 13 GRAFISK OVERSIKT OVER EB:MESSAGEHEADER FIGUR 14 GRAFISK OVERSIKT OVER EB:FROM. EB:TO ER LIK FIGUR 15 GRAFISK OVERSIKT OVER EB:MANIFEST. DENNE LIGGER I SOAP:BODY OG INNEHOLDER REFERANSER TIL MIME-VEDLEGGENE DER FORRETNINGSDOKUMENTENE (PAYLOAD) LIGGER FIGUR 16 OVERSIKT OVER EB:ACKNOWLEDGEMENT

8 1. Innledning Denne spesifikasjonen beskriver en meldingstjeneste, inklusive en meldingskonvolutt i XML-syntaks [XML], basert på ebxml [EBXML] meldingstjeneste, versjon 2.0 [EBMS], som skal benyttes for å utveksle XMLmeldinger mellom parter i helsevesenet. Mellomlaget er bygget på MIME og SOAP [SOAP]. Konvolutten skal i utgangspunktet inneholde informasjon som er relevant for å kunne:?? gi en entydig identifikasjon av kommunikasjonspartene (avsender og mottaker) og?? identifisere selve forretningstransaksjonen (sykmelding, resept, etc). Den elektroniske konvolutten kan således sammenlignes med en papirkonvolutt med referanser til vedlegg. Konvolutten skal videre sikre mulighetene til å:?? overføre kvitteringer på mottak av meldinger?? rapportere eventuelle feil som oppdages i behandling av en mottatt melding. Det er et absolutt krav at selve forretningstransaksjonen skal være frikoblet fra innholdet i konvolutten, slik at det skal være mulig å kryptere bare deler av meldingen hvis dette er ønskelig. Konvolutten skal kunne benyttes samme med alle typer informasjon som skal utveksles asynkront, så som strukturerte meldinger, bilder, lydopptak, videosekvenser og ustrukturerte vedlegg Bakgrunn Overgangen til XML som meldingssyntaks og anbefalinger om at utvekslingen skal forholde seg til kravene i CEN ENV [ENV] når det gjelder sending og kryptering av meldinger, stiller nye krav til hvordan meldinger kan og bør utveksles. Overgangen til annen meldingssyntaks, økt behov for å sende med andre typer vedlegg (bilder,lyd, etc) og mulighet for å benytte andre transportprotokoller gjør det også nødvendig å utarbeide et regelsett for hvordan meldinger skal utveksles uavhengig av transportprotokoll og uavhengig av syntaks og format på innholdet. Det ble derfor behov for å igangsatt et arbeid for å utarbeide en konvolutt/meldingshode i samarbeid med leverandørene Målsetning Målsettingen med arbeidet er å komme frem til et felles rammeverk over hvordan meldinger bør utveksles i helse- og sosialsektoren i Norge og å oppnå en felles enighet om dette i samarbeid med leverandørene. Arbeidet skal resultere i en felles måte å presentere informasjon om avsender/mottager, samt annen informasjon som kan være relevant å ha med i et meldingshode. Konvolutten skal være uavhengig av selve meldingsinnholdet og den medisinske informasjonen, slik at det skal være mulig å kryptere og/eller signere bare deler av meldingen hvis dette er ønskelig. Det skal også være mulig å benytte meldingskonvolutten sammen med ulike typer informasjon så som strukturerte meldinger, bildefiler, lydfiler og ustrukturerte vedlegg Leserveiledning Dokumentet er myntet på leverandører og it-personell som skal implementere konvoluttløsningen. Dette dokumentet bør leses sammen med ebxml Message Service Spesification v2.0 [EBMS]. For de som ikke er kjent med XML og XML Schema henvises det til referansene [XML] og [XMLS]. Kapittel 2 sier noe om forutsetningene for løsningen. Kapittel 3 inneholder hovedprinsippene ved utveksling med ebxml. Kapittel 4 beskriver hvordan arkitekturen fungerer. Kapittel 5 inneholder beskrivelse av selve konvolutten. Kapittel 7 beskriver på en overordnet måte rammeverkets sikkerhetsmekanismer. Sist i dokumentet finnes det referanser til kilder og aktuelle dokumenter. 8

9 2. Krav og forutsetninger 2.1. Funksjonelle krav Konvolutten er ment å dekke følgende funksjonelle krav, som også er i samsvar med ebxml sine krav:?? Elektroniske dokumenter skal kunne utveksles mellom parter, pakket inn i en konvolutt.?? En konvolutt kan inneholde en eller flere meldinger (for eksempel flere laboratoriesvar), forutsatt at alle meldingene er fra én avsender til én mottaker.?? En konvolutt kan inneholde en melding med relaterte vedlegg (for eksempel en patologirekvisisjon og et relatert bilde). Hvis konvolutten inneholder flere meldinger, kan meldingen ikke ha relaterte vedlegg/dokumenter i samme meldingsutveksling.?? En konvolutt kan inneholde flere uavhengige meldinger/dokumenter, eller flere meldinger/dokumentert som alle er relatert til hverandre.?? Avsender og mottakerinformasjon skal ligge i konvolutten.?? Meldingen skal kunne utveksles via flere ulike nettverksprotokoller.?? Meldinger som inneholder dokumenter skal ha global unik identifikator.?? Når konvolutten brukes som en kvittering eller feilrapport må den inneholde identifikasjon av den meldingsutvekslingen som den er et svar på.?? Konvolutten må inneholde informasjon om når den er generert Begrensninger I tråd med direktiver fra RTV og ønsker fra sektoren har man valgt en trinnvis tilnærming med mulighet for utvidelser etter hvert som nye behov fremkommer. Dette innebærer at ikke alle elementer som inngår i ebxml er tatt med i denne versjonen. Foreliggende funksjoner er dekket i foreliggende versjon:?? En konvolutt for å bære informasjon om forretningsdokumenter (for eksempel en sykmelding).?? Mekanismer for å rapportere eventuelle feil i forbindelse med mottak av konvolutt, det vil si en feilmelding?? Mekanismer for å rapportere mottak av en XML konvolutt, det vil si en 1 -kvittering?? En konvolutt for å bære informasjon om et applikasjonssvar/-kvittering?? Signering av en XML konvolutt, inklusive feilmelding og kvittering, samt selve forretningsdokumentet I foreliggende versjon dekker ikke denne spesifikasjonen funksjoner for kryptering. Funksjoner for kryptering forutsettes ivaretatt i transportlaget i henhold til ENV [ENV]. 1 Meldinghåndterings-system 9

10 3. ebxml meldingstjeneste Meldingstjenesten i ebxml beskriver en tjeneste for å utveksle elektroniske meldinger mellom partnere på en standardisert, sikker og pålitelig måte uavhengig av selve kommunikasjonssystemet. En ebxml meldingstjeneste (ebxml ) kan konseptuelt brytes ned i tre hovedfunksjoner (se figur 1): 1. Grensesnitt mellom applikasjon (avsendende eller mottagende applikasjon) og meldingstjenesten 2. Selve meldingstjenesten, som inneholder funksjoner for:?? Autentisering, autorisasjon og ikkebenekting?? Behandling av elementer i meldingshode?? Kryptering og signering?? Inn- og utpakking i enhelet egnet for overføring?? Feilhåndtering, inklusive rapportering av feil?? Håndtering av kvitteringer og bekreftelser 3. Grensesnitt mot underliggende kommunikasjonstjeneste En ebxml meldingstjeneste kan støtte både satsvise (enveis) overføringer og dialog-orienterte (spørsmål/svar) overføringer. Applikasjon Grensesnitt mot meldingstjeneste Meldingstjeneste Autentisering, autorisasjon og ikke-benekting Behandling av meldingshode Kryptering/signering Inn-/utpakking Grensesnitt mot kommunikasjon Behandlingen av meldinger i meldingstjenesten, og følgelig også de parametere som skal settes i konvolutten, reguleres av de avtaler HTTP SMTP IIOP FTP (samhandlingsavtaler) som er inngått mellom partene i en utveksling. En samhandlingsavtale Figur 1 Arkitektur for en ebxml meldingstjeneste. beskriver de regler som gjelder for behandling av en melding hos hver av partene. I henhold til ebxml-rammeverket kan slike samhandlingsavtaler etableres på en dynamisk måte i dét selve meldingsutvekslingen skal foregå eller være fast definert i et selvstendig dokument som partene er enig om. Strukturen i en melding som er satt opp i henhold til kravene i ebxml meldingstjenesten er vist i [EBMS] En meldingsoverføring i henhold til ebxml består av en transportkonvolutt som må settes opp i henhold til spesifikasjonene som gjelder for den transporttjenesten som benyttes, og selve meldingskonvolutten (MIMEkonvolutt) Meldingsoverføringen er uavhengig av den transporttjenesten som benyttes og omslutter det hele informasjonsinnholdet som skal overføres. Meldingskonvolutten realiseres i form av en multipart MIME melding hvor ebxml-konvolutten overføres i en MIME-del (MIME body part) og selve forretningsmeldingen (payload) i en eller flere andre MIME del(er). Meldingskonvolutten skal inneholde en ebxml-konvolutt og kan inneholde en ebxml payload. ebxml konvolutten skal være satt opp i henhold til SOAP 1.1 [SOAP] og skal overføres i en egen MIME bodypart. ebxml Payload, som inneholder selve forretningsmeldingen(e), skal overføres i en egen MIME bodypart. 10

11 Transportkonvolutt (HTTP, SMTP, etc.) MIME konvolutt (SOAP med vedlegg) MIME del SOAP konvolutt: Envelope SOAP konvolutt: MessageHeader ebxml: MessageHeader ebxml: ErrorList ebxml: Signature ebxml: Acknowledgement ebxml konvolutt melding SOAP konvolutt: Body ebxml: Manifest MIME del Payload (Foretningsmelding) ebxml payload Figur 2 Strukturen i en meldingsoverføring med ebxml ebxml-konvolutten er et XML dokument som skal være satt opp i henhold til SOAP 1.1. Det benyttes en rekke utvidelser til SOAP (SOAP extentions) for å overføre de parameterne som er nødvendig for å styre behendlingen i ebxml meldingstjenesten. ebxml-konvolutten skal inneholde et MessageHeader-element og kan inneholde et Manifest for å gi referanser til forretnings-dokumentene i innholdskonvolutten. MessageHeader-elementet skal være pakket inn i en SOAP envelope. Manifest-elementet skal være pakket inn i et SOAP body-element. En ebxml-konvolutt kan brukes for å:?? gi informasjon om data som overføres mellom to applikasjoner Dette kan være et forretningsdokument (for eksempel en sykmelding / legeerklæring) eller svar på et mottatt forretningsdokument (for eksempel en applikasjonskvittering eller en feilmelding). Se kapittel 5 for nærmere gjennomgang av de elementene i ebxml konvolutten som benyttes.?? rapportere om eventuelle feil som er oppdaget i en mottatt ebxml konvolutt Se kapittel 5.4 for nærmere gjennomgang av de elementene i ebxml konvolutten som benyttes.?? gi en kvittering på at en melding er mottatt av tjenesten Se kapittel 5.4 for nærmere gjennomgang av de elementene i ebxml konvolutten som benyttes. Konkret hvilke parameter i ebxml konvolutten som skal eller kan angis for hver av de tre områdene er beskrevet i respektive kapitler 5 og 5.4. gir en overordnet beskrivelse av de mest sentrale elementene. ebxml-konvolutten kan signeres direkte. Forretningsdokument signeres for seg selv, f.eks. integrert i dokumentet (XML, PDF) eller eksternt som vedlegg. Se kapittel Bruk av ebxmls meldingstjeneste De variantene av ebxml konvolutten som er beskrevet i denne spesifikasjonen (kapittel 5 og 6) er subsett av ebxml og har følgelig samme struktur som ebxml sin meldingstjeneste. En del elementer som er frivillige i ebxml er imidlertid ikke inkludert. Dette er i første rekke elementer knyttet til funksjoner for kryptering, men også enkelte andre funksjoner som vurderes som ikke essensielle på det nåværende tidspunkt. Konvolutten skal benyttes for å identifisere avsender og mottager, identifisere selve meldingsutvekslingen og innholdet i denne samt identifisere entydig hvilken meldingskonversasjon denne meldingsutvekslingen tilhører. 11

12 En forretningsmelding (payload) er et selvstendig dokument/brev/svar. Eksempler på forretningsmeldinger er et laboratoriesvar, en laboratorierekvisisjon, en epikrise, en journal etc. En forretningsmelding kan bestå av flere vedlegg. En rekvisisjon kan for eksempel bestå av selve rekvisisjonen (tilsvarende dagens papirskjema) med referanse til et bilde der bildet er lagt ved som et selvstendig vedlegg. Rekvisisjonen vil da bestå av to deler (bodyparts), én for selve rekvisisjonen (for eksempel en XML-instansmelding eller en EDIFACT-melding) og én for bildet (for eksempel en JPEG-fil). En meldingsutveksling kan bestå av flere meldinger. En meldingsutveksling vil for eksempel inneholde mange laboratoriesvar i én og samme meldingsutveksling. Dette forutsetter at mottager er sammenfallende for alle enkeltmeldingene. Konvolutten vil inneholde informasjon om avsender/mottager, samt referanse til alle enkeltmeldingene (her: laboratoriesvar), eller referanse til en samlefil som kan inneholde mange laboratoriesvar med referanser til andre vedlegg. En meldingskonversasjon kan bestå av flere relaterte meldinger. En meldingskonversasjon kan for eksempel bestå av en meldingsutveksling med laboratoriesvar, en feilmelding, en revidert meldingsutveksling hvis første meldingsutveksling inneholdt feil og kvittering på at meldingsutvekslingen er mottatt hos mottager Bruk av ebxml-konvolutt En forekomst av en ebxml-konvolutt komponeres av en samling elementer. Hvilke elementer som skal benyttes vil variere avhengig av den funksjon den aktuelle meldingen har. Nedenstående tabell gir en fremstilling av de viktigste elementene og den sammenheng disse benyttes. Det må påpekes at ikke alle elementene er gjengitt i denne tabellen. Kolonnen «Overføring av applikasjonssvar» er tatt med for å vise hvordan et applikasjonssvar kan utveksles. Et applikasjonssvar er i prinsippet likestilt som hvilket som helst annet forretningsdokument, men skilles seg ut ved at det er automatisk behandlet på lik linje med kvitterings- og feilmeldingsmeldinger. Følgende notasjon benyttes for å angi krav til tilstedeværelse:?? R (Required); innebærer at elementet altid skal benyttes. Dersom elementet ikke forekommer i en mottatt melding skal dette rapporteres som en feil.?? O (optional); innebærer at elementet kan benyttes. Det er med andre ord valgfritt om elementet benyttes eller ikke.?? N (Not used); innebærer at elementet ikke skal benyttes. Dersom elementet forekommer i en mottatt melding skal dette rapporteres som en feil. ebxml element Funksjonelt innhold Overføring av forretningsdokument MIME part MIME-referanse til ebxml feilmelding kvittering Overføring av Applikasjonssvar R R R R konvolutten SOAP:Envelope Innkapsling R R R R SOAP:Header Innkapsling R R R R eb:messageheader Innkapsling R R R R eb:from Avsender R R R R eb:to Mottaker R R R R eb:cpaid Unik identifikasjon av samhandlingsavtale R R R R eb:conversationid Unik identifikasjon av konversasjon R R R R eb:service Angivelse av tjeneste R R R R eb:action Angivelse av prosess innenfor en tjeneste R R R R eb:messagedata Innkapsling R R R R eb:messageid Unik identifikasjon av den enkelte melding i en konversasjon R R R R eb:timestamp eb:reftomessageid Når konvolutten ble generert Referanse til tidligere melding (=eb:messageid i mottatt melding) R R R R N R N R 12

13 ebxml element Funksjonelt innhold Overføring av forretningsdokument eb:timetolive Konvoluttens gyldighetsperiode eb:duplicateeliminaton Angir om meldingen er et duplikat eb:description Verbal beskrivelse av konvoluttens innhold eb:ackrequested Anngir krav om kvittering fra eb:acknowledgement Innkapsling av kvittering fra eb:timestamp Når kvitteringen ble generert Referanse til den konvolutten det kvitteres for eb:reftomessageid (=eb:messageid i mottatt melding) feilmelding kvittering Overføring av Applikasjonssvar O N N O O N N O O O O O O N N O N N R N N N R N N N R N eb:errorlist Innkapsling av feilmeldinger N R N N eb:error Feilmelding N R N N ds:signature Innkapsling av sikkerhetsinformasjon R R R R ds:signatureinfo Informasjon om konvoluttsignaturen R R R R ds:reference Referanse til et objekt som signeres (=MIME referanse) R N N R ds:digestvalue Signatur for objektet R N N R ds:signaturevalue Signatur for konvolutten R N N R ds:keyinfo Informasjon om nøkler bruk for signering av konvolutt O N N O SOAP:Body Innkapsling av informasjon om innhold i meldingen R R R R eb:manifets Innkapsling O N N R eb:reference Referanse til payload R R N N (=MIME-referanse) 2 forekomster eb:schema Identifikasjon av den XSD som gjelder for Payload O N N O eb:description Verbal beskrivelse av Payload O N N O MIME part MIME referanse til Payload (forretningsdokumentet) R N N R Payload Selve forretningsdokumentet evt applikasjonssvaret R N N R 3.3. Bruk av referanser I ebxml-konvolutten benyttes det en rekke forskjellige referanser for å knytte sammen deler av en melding og ulike ebxml-konvolutter til en større helhet. De viktigste referansebegrepene er: eb:cpaid Dette elementet skal angis for å identifiserer den protokoll (samhandlingsavtale) som gjelder for samhandlingen. Protokoll her innebærer et sett med regler som partene må forholde seg til. Meldingen som overføres sammen med konvolutten skal være i overensstemmende med denne protokollen. Innhold i elementet kan være en URI som inneholder et XML dokument. Alternativt et dokument med en beskrivelse av samhandlingen i form av tekst alene, eller med støtte av en modell. Siden CPAId angis på høyeste nivå i ebxml konvolutten må alle de forretningsdokumenter og applikasjonssvar som overføres i en melding være underlagt den samme samhandlingsavtalen. 13

14 eb:conversationid Dette elementet skal angis for å gi en unik identifikasjon for et sett meldinger som utgjør en konkret dialog eller konversasjon. Identifikator skal være unik for alle deltagende parter. Identifikator genereres av initiativtaker til konversasjonen, og skal ha samme verdi for alle meldinger som inngår i konversasjonen eb:messageid Dette elementet skal angis for å gi en globalt unik identifikasjon av den enkelte melding som inngår i en konversasjon. Hvilket applikasjonslag som skal generere denne er avhengig av bruken. I valgt arkitektur er det naturlig at genererer denne identifikatoren. Identifikatoren vil gjelde konvolutt samt samtlige vedlegg (Payload) som inngår i meldingen eb:reftomessageid Dette elementet kan benyttes for å referere til en tidligere melding som meldingen er et svar på. Innehold i dette elementet er da innholdet i "eb:messageid" elementet fra meldingen den er et tilsvar på. Elementet skal ikke benyttes for den første melding i en konversasjon eller dialog. Elementet skal angis når meldingen er en endring eller en kansellering av en tidligere melding. Elementet skal angis når meldingen er en kvittering eller feilmelding på - eller applikasjonsnivå eb:reference Dersom meldingen inneholder Payload skal dette elementet benyttes for å gi referanse til Payload (det vil si der hvor meldingen overfører et forretningsdokument eller et applikasjonssvar). Referansen skal inneholde adressen til MIME vedlegget (CID) som inneholder Payloaden og skal være unik i forhold til eb:messageid Dersom meldingen inneholder et applikasjonesvar (feilmelding eller kvittering fra mottakene applikasjon) skal det benyttes en ordnet rekke med to referanser. Første referanse i settet skal angi adressen til MIME vedlegget som inneholder applikasjonssvaret. Andre referanse i settet skal angi adressen til MIME vedlegget i denne opprinnelige meldingen som denne meldingen er et tilsvar på. Elementet skal ikke benyttes dersom meldingen ikke inneholder Payload (det vil si der hvor meldingen overfører en kvittering eller feilmelding fra -laget) Bruk av samhandlingsplaner I denne versjonen av spesifikasjonen er det ikke lagt opp til en dynamisk etablering av samhandlingsavtaler (Collaboration Protocol Agreement - CPA) på grunnlag av partenes samhandlingsprofiler (Collaboration Protocol Profile - CPP). Det forutsettes derfor at de eksakte regler som gjelder for en meldingsutveksling er definert i et selvstendig dokument som partene er enig om. Innholdet i samhandlingsavtalen vil regulere hvilke av de valgfrie elementene i konvolutten som skal benyttes og det eksakte verdiinnholdet for disse elementene. 14

15 4. Funksjonell arkitektur Meldingstjenesten i ebxml (ebxml ) baserer seg på en tradisjonell lagdelt arkitektur som vist i figur 3. Avsender applikasjon data Avsender ebxml Komm Konvolutt + data Mottaker Komm ebxml data Mottaker applikasjon Figur 3 Funksjonell arkitektur Arkitekturen baserer seg på følgende saksgang: 1. Avsenders applikasjon klargjør de data som skal overføres til mottaker, det vil si selve forretningsmeldingen (engelsk: payload) og leverer dette sammen med parametere som styrer fremføringen (blant annet hvem som er motaker) til avsenders meldingstjeneste. Dette steget vil også omfatte signering av forretningsdokumentet med brukerens nøkler. 2. Avsenders meldingstjeneste etablerer den nødvendige konvolutten og gjør konvolutten sammen med forretningsmeldingen klar for overføring. Dette steget vil også omfatte signering av konvolutten med meldingstjenestens nøkkler. 3. Avsenders meldingstjeneste starter så selve kommunikasjonen via en av de aktuelle kommunikasjonstjenestene (HTTP, SMTP, etc.) for å overføre konvolutten og forretningsmeldingen til mottaker. Dette steget vil også omfatte en eventuell kryptering med meldingstjenestens nøkkler. 4. Mottakers kommunikasjonstjeneste mottar overføringen og leverer konvolutten og foretningsinnholdet til mottakers meldingstjeneste. Dette steget vil også omfatte en dekryptering. 5. Mottakers meldingstjeneste verifiserer innholdet i konvolutten og behandler konvolutten og forretningsmeldingen i henhold til de parametere som er spesifisert i konvoluten før selve forretningsmeldingen leveres til mottakers applikasjon. Behandlingen i mottakers meldingstjeneste kan blant annet omfatte:?? Verifikasjon av at overføringen har kommet til riktig mottaker?? Verifikasjon av sikkerhetsinformasjon, det vil si verifikasjon av signatur på konvolutten?? Gi kvittering (acknowledgement) på at overføringen har kommet frem, tilbake til avsenders meldingstjeneste?? Rapportering av eventuelle feil i konvolutten eller melding om funksjoner som ikke støttes tilbake til avsender 6. Mottakers applikasjon behandler selve forretningsmeldingen i henhold til det regelverket som gjelder. Denne behandlingen kan omfatte:?? Verifikasjon av sikkerhetsinformasjon, det vil si verifikasjon av signatur på selve forretningsdokumentet?? Gi kvittering på at forretningsmeldingen har kommet frem til mottakers applikasjon tilbake til avsenders applikasjon?? Verifisere datainnholdet i foretningsmeldingen og rapportere eventuelle feil tilbake til avsenders applikasjon 15

16 Sett fra meldingstjenesten vil meldinger som inneholder kvitteringer og feilrapporter fra applikasjon i utgangspunktet bli behandlet som en hvilken som helst annen forretningsmelding. Avsender applikasjon data Avsender ebxml Komm Konvolutt + data Mottaker Komm ebxml data Mottaker applikasjon Kvittering på mottak Rapportering av feil Figur 4 Kvittering og feilrapportering fra meldingstjenesten. Rapportering av feil Kvittering på mottak Avsender applikasjon data Avsender ebxml Komm Konvolutt + data Mottaker Komm ebxml data Mottaker applikasjon Figur 5 Kvittering og feilrapportering fra applikasjon Utvekslingsscenarier Med utgangspunkt i ovenstående saksgang kan følgende utvekslingsscenarier forekomme: 1 Overføring av forretningsmelding (P 1) med forretningssvar (P 2) uten kvitteringer eller feilmeldinger 2 Overføring av forretningsmelding (P 1) med feil i konvolutt 3 Overføring av forretningsmelding (P 1) med krav om bekreftelse fra 4 Overføring av forretningsmelding (P 1) med krav om bekreftelse fra, hvor det raporteres feil fra applikasjon (P err) 5 Overføring av forretningsmelding (P 1) med krav om bekreftelse fra applikasjon (P akk) Applikasjon Applikasjon kvittering feilrapport kvittering feilrapport Nei Nei Nei Nei Nei Ja - - Ja Nei - - Ja Nei Nei Ja - Nei Ja nei 16

17 Overføring av forretningsmelding (P 1 ) med forretningssvar (P 2 ) uten kvitteringer eller feilmeldinger Avsender applikasjon Avsender Motaker Mottaker applikason 1: P1 6: P2 2: (M1+P1) 5: (M2+P2) 3: P1 4: P2 Figur 6 Overføring av forretningsmelding (P 1 ) med forretningssvar (P 2 ) uten kvitteringer eller feilmeldinger. Konvolutten M 1 skal inneholde en referanse som brukes for å identifisere det forretnings-/sakstilfelle innholdet i konvolutten omhandler. Referansen gis i form av en konversasjonsreferanse (ConversationId). Det forretningsmessige svaret (P 2 ) fra mottakers applikasjon bør inneholde nødvendige referanser som gjør avsenders applikasjon istand til å relatere svaret til den opprinnelige forretningsmeldingen (P 1 ). Konvolutten M 2 skal identifisere det samme forretnings-/sakstilfellet som angitt i den mottatte konvolutten M 1. Se «eb:reftomessageid», side Overføring av forretningsmelding (P 1 ) med feil i konvolutt Avsender applikasjon Avsender Motaker Mottaker applikason 1: P1 2: (M1+P1) 3: Merr Figur 7 Overføring av forretningsmelding (P 1 ) med feil i konvolutt. Feilrapporteringen fra mottakers vil skje ved at det genereres en melding som kun inneholder en ebxml konvolutt (M err ). Det vil si ikke inneholder noen forretningsmelding i form av payload. Konvolutten M err skal inneholde referanse til den mottatte konvolutten M 1 foruten en liste som angir de feil som er oppdaget. Den opprinnelig mottatte konvolutten M 1 identifiseres ved at man oppgir referansen til det MIMEelementet som inneholdt konvolutten. Det skal ikke kvitteres for en mottatt feilmelding fra. 17

18 Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra Avsender applikasjon Avsender Motaker Mottaker applikason 1: P1 7: P2 2: (M1+P1) 3: Makk 6: (M2+P2) 4: P1 5: P2 Figur 8 Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra. Kvitteringen fra mottakers vil skje ved at det genereres en ebxml-melding som kun inneholder en ebxml konvolutt (M akk ), det vil si ikke inneholder noen forretningsmelding - payload. Konvolutten M akk skal inneholde referanse til den mottatte konvolutten M1 foruten et element som angir at dette er en bekreftelse. Den opprinnelig mottatte konvolutten M1 identifiseres ved at man oppgir referansen til det MIME-elementet som inneholdt konvolutten. Se kapittel 5.4. Det skal ikke kvitteres for en mottatt kvittering fra Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra, hvor det rapporteres feil fra applikasjon (P err ) Avsender applikasjon1 Avsender 1 Motaker 1 Mottaker applikason1 1: P1 7: Perr 2: (M1+P1) 3: Makk 6: (Merr+Perr) 4: P1 5: Perr Figur 9 Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra, hvor det rapporteres feil fra applikasjon (P err ). Feilrapportering fra mottagers applikasjon (P err ) bør inneholde nødvendige referanser som gjør avsenders applikasjon i stand til å relatere feilrapporten til den opprinnelige forretningsmeldingen (P 1 ). Konvolutten M err skal inneholde referanse til den mottatte konvolutten M1 foruten en referanse til den opprinnelige forretningsmeldingen (P 1 ). Referansen til den opprinnelige forretningsmeldingen gis i form av en referanse til det MIME-elementet i den opprinnelige meldingen som inneholdt forretningsmeldingen. Sett fra meldingstjenestens () vil meldinger som inneholder feilrapporter fra applikasjon i utgangspunktet bli behandlet som en hvilken som helst annen forretningsmelding. Som sådan kan det godt returneres en kvittering (M akk ) på en mottatt feilrapport fra applikasjon (P err ). 18

19 Avsender applikasjon Avsender Motaker Mottaker applikason 1: P1 8: Perr 2: (M1+P1) 3: Makk 6: (Merr+Perr) 7: Makk 4: P1 5: Perr Figur 10 kvittering (M akk ) på mottatt feilrapport fra applikasjon (P err ) Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra applikasjon (P akk ) Avsender applikasjon Avsender Motaker Mottaker applikason 1: P1 8: Pakk 2: (M1+P1) 3: Makk 6: (Makk+Pakk) 7: Makk 4: P1 5: Pakk Figur 11 Overføring av forretningsmelding (P 1 ) med krav om bekreftelse fra applikasjon (P akk ). Selve kravet om kvittering fra applikasjon kan fremgå av samhandlingsavtalen mellom partene eller spesifiseres som en parameter i selve forretningsmeldingen (P 1 ). Kvitteringen fra mottakers applikasjon (P akk ) bør inneholde nødvendige referanser som gjør avsenders applikasjon istand til å reletere feilrapporten til den opprinnelige forretningsmeldingen (P 1 ). Meldingshodet i konvolutten M akk skal inneholde referanse til den motatte konvolutten M 1 foruten en referanse til den opprinnelige forretningsmeldingen (P 1 ). Referansen til den opprinnelige forretningsmeldingen gis i form av en referanse til det MIME-elementet i den opprinnelige meldingen som inneholdt forretningsmeldingen. 19

20 5. ebxml konvolutt Dette kapittelet beskriver en elektronisk konvolutt i XML-format for utveksling av meldinger i helsevesenet. Se kapittel 7 om sikkerhet på -laget. Konvolutten beskrevet i dette kapittelet baserer seg på struktur fra SOAP versjon 1.1 (W3C Note 08 mai 2000), SOAP Messages with Attachments (W3C Note 11 Desember 2000) samt komponenter fra OASIS ebxml Message Service Spesification version 2.0 (1 april 2002). Basis for det hele er selvfølgelig "XML Schema Recommendation 2 may 2001". Versjonene av SOAP foreligger bare som notat og er ikke stabile dokument. I SOAP er meldingsinnholdet spesifisert til å være inneholdt i SOAP konvolutten. ebxml bryter dette prinsippet i og med at en baserer seg på spesifikasjonen for vedlegg med SOAP. Dermed vil meldingsinnholdet komme etter konvolutten innkapslet i en MIME konvolutt. Konvolutten her kan betraktes som et separat vedlegg i XML format med informasjon om avsender, mottaker, samhandlingsprosess for en eller flere meldinger som følger etter konvolutten. Disse meldingene er dermed frigjort fra XML formatet. Dette dokumentet kan leses og forståes av enhver som har kjennskap til XML og XML Schema. Det vil være imidlertid ikke være en ulempe å sette seg inn i ovennevnte spesifikasjoner. Alle elementer i konvolutten er beskrevet i en hierarkisk struktur som gjenspeiler seg i kapitteloppbyggingen. Innholdsfortegnelsen vil følgelig gi et godt bilde av strukturen i konvolutten. I tillegg er det en grafisk beskrivelse av XML Schema. Dokumentet inneholder tilstrekkelig informasjon om innholdet i en elektronisk konvolutt for implementering. I dokumentet finnes det endel grafiske oversikter over en del grunnleggende elementer. Disse viser ikke attributtene i elementene. XML Schema for ebxml-konvolutten finnes her: SOAP:Envelope Figur 12Hoveddelene til SOAP-konvolutten. Dette er rotnode i konvolutten, og alle andre noder i konvolutten er etterkommere av dette elementet. I spesifiseringen til SOAP er kun "SOAP:Body" et påkrevet element. ebxml har et stort fokus på informasjon om parter rundt en sending og har "SOAP:Header" som et påkrevet element. I denne konvolutten er "SOAP:Header" påkrevet. 20

21 I spesifiseringen til SOAP er "SOAP:Body" innkapsling av selve meldingsinnholdet (payload). ebxml benytter MIME konvolutt hvor selve meldingen (payload) er et MIME vedlegg. Innholdet i Body virker dermed noe overflødig, men er påkrevet og benyttes til å gi informasjon om payload. Det er ikke definert noen attributter utover standard xml attributter, og elementet fungerer kun som innkapsling av meldingen. rot node - container node Tekstnode Lovlige ytre elementer Indre elementer SOAP:Header (1) SOAP:Body (1) 5.2. SOAP:Header Dette elementet er en innkapsling av elementer som inneholder informasjon om utvekslingen og ikke selve meldingsinnholdet. Elementet "eb:messageheader" er påkrevet. Elementet "eb:ackrequested" benyttes når en kvittering for mottatt melding er ønsket, men er ikke påkrevet benyttet i denne konvolutten. Denne kvitteringen vil kun være en kvittering for konvolutten fra. Ønskes en kvittering fra applikasjon, må dette defineres i en samhandlingsprosess, eller i form av krav i payload som blir overført til applikasjonen. I en samhandling hvor det forutsettes at applikasjon som mottar payload skal generere en svarmelding, vil dette kravet være overflødig. Elementet "ds:signature" er ikke beskrevet i dette dokumentet, men er beskrevet i et eget dokument som omhandler signatur. container node Tekstnode Indre elementer eb:messageheader (1) eb:ackrequested (0..1) ds:signature (1) eb:messageheader Figur 13 Grafisk oversikt over eb:messageheader 21

22 Dette elementet er innkapsling av en rekke elementer som inneholder informasjon om parter og krav rundt sendingen. Attributtene eb:version og soap:mustunderstand er påkrevet. Attributtet soap:mustunderstand skal settes til "sann". Tekstnode container node med attributt eb:version string Innehold Fast verdi = 2.0 Bruk Påkrevet. Definerer versjon av ebxml Message Services soap:mustunderstand boolsk Innehold (true 1) (false 0) Bruk Indre elementer eb:from (1) eb:to (1) eb:cpaid (1) eb:conversationid (1) eb:service (1) eb:action (1) eb:messagedata (1) eb:duplicateelimination (0..1) eb:description (0..1) eb:from Påkrevet. Definerer krav til at mottaker kan prosessere innholdet innkapslet av MessageHeader. Om mottaker ikke kan utføre prosesseringen må det resultere i en feilmelding Figur 14 Grafisk oversikt over eb:from. eb:to er lik. Innkapsling av informasjon som identifiserer meldingens opprinnelige avsender, og ikke siste avsender som formidlingssentral eller liknende. De kan kun være en avsender definert i konvolutten. Med denne begrensningen vil det ikke være mulig for en å samle flere avsendere i en konvolutt. Elementet PartyId er påkrevet og kan forekomme flere ganger, dvs at opprinnelig avsender kan identifiseres på flere alternative måter. container node Tekstnode Indre elementer eb:partyid (1..*) eb:role (0..1) eb:partyid Det er mulighet for flere typer identifikatorer for avsender. De forskjellige typer er definert i attributtet "type". Anbefaler en type identifikator (HER, helsepersonellnummer og/eller organisasjonsnummer) samt en routingadresse (X.400 eller epost-adresse). tekstnode med attributt Tekstnode non-empty-string Innehold Identifikator for avsender eb:type non-empty-string Innehold Kode for type identifikator. Se kapittel 5.4 for gyldige koder. Bruk Påkrevet. Definisjon av type identifikator som ligger i tekstnode Indre elementer Eksempel: <eb:partyid eb:type="herid">noh </eb:partyid> 22

23 eb:role Definerer hvilken rolle avsender har. I et scenario med kun én avsender og én mottaker, kan det virke overflødig. Det anbefales likevel benyttet slik at mottaker kan kontrollere om avsender har korrekt rolle i en konversasjon. Innhold i en rolle vil være en kode eller URI som kan leses av applikasjoner eller som er en tekstlig beskrivelse av rollen. Se kapittel 5.4 for gyldige koder. tekstnode med attributt Tekstnode non-empty-string / URI Innehold Identifikator for rolle avsender. Se kapittel 5.4 for gyldige koder. Indre elementer Eksempel: <eb:role>part</eb:role> eb:to Innkapsling av informasjon som identifiserer mottaker av meldingen. Det vil være endelig mottaker og ikke. All payload skal til denne mottaker. I spesifiseringen av SOAP er det mulig med transittnoder for meldingen som kan foreta prosessering av elementer i Header identifisert ved rollen til transittnode. Foreløpig er det kun ende til ende kommunikasjon, og dermed kun endelig mottaker som blir identifisert. Elementet "eb:partyid" er påkrevet, men det anbefales at elementet "eb:role" også benyttes. container node Tekstnode Indre elementer eb:partyid (1..*) eb:role (0..1) eb:partyid Det er mulighet for flere typer identifikatorer for mottaker. De forskjellige typer er definert i attributtet "type". tekstnode med attributt Tekstnode non-empty-string Innehold dentifikator for mottaker eb:type non-empty-string Innehold Kode for type identifikator. Se kapittel 5.4 for gyldige koder. Bruk Påkrevet. Definisjon av type identifikator som ligger i tekstnode Indre elementer eb:role Definerer hvilken rolle mottaker skal ha har. Et scenario med kun en avsender og en mottaker kan det virke overflødig, men anbefales brukt slik at mottaker kan kontroller om de har den rolle som avsender forventer. Innhold i en rolle vil være en kode eller URI som kan leses av applikasjoner eller som er en tekstlig beskrivelse av rollen. Se kapittel 5.4 for gyldige koder. tekstnode med attributt Tekstnode non-empty-string / URI Innehold Identifikator for rolle mottaker Se kapittel 5.4 for gyldige koder. Indre elementer eb:cpaid Unik identifisering av en protokoll for samhandling. Protokoll her innebærer et sett med regler som partene må forholde seg til. Meldingen identifisert ved denne konvolutten må være i overensstemmende med denne protokollen. Dette elementet er påkrevet. 23

24 Innhold i elementet kan være en URI som inneholder et XML-dokument. Alternativt et dokument med en beskrivelse av samhandlingen i form av tekst alene, eller med støtte av en modell. Det kan og være en kode for hvilken samhandlingsavtale dette er. Ved bruk av en kode må en sikre at partene har en felles definisjon og forståelse om framdrift og om rekkefølge av meldinger i samhandlingen. container node Tekstnode non-empty-string / URI Innehold Identifikator for forretningsprosess Indre elementer Eksempel med URI: <eb:cpaid>htttp:// Eksempel med kode: <eb:cpaid>singlemessagelegeerklaering</eb:cpaid> eb:conversationid En unik identifikator for et sett meldinger som utgjør en konkret dialog eller konversasjon. Denne identifikator må være unik for alle deltagende parter. Den unike identifikatoren blir generert av initiativtaker til konversasjonen, og skal være identisk i alle meldinger som inngår i konversasjonen. container node Tekstnode non-empty-string / URI Innehold Unik identifikator for dialog / konversasjon Indre elementer Eksempel: <eb:conversationid>ahus </eb:conversationid> eb:service En unik identifikator for hvilken type tjeneste meldingen utfører. Det anbefales en URI til identifisering av tjenesten. Det åpnes og for å benytte kodeverdi, men da er attributtet "type" påkrevet om en benytter koder. Dette for å identifisere kodeverk. Se kapittel 5.4 for gyldige koder. Dette er de samme koder som benyttes i subjectfeltet på X.400-meldinger. tekstnode med attributt Tekstnode non-empty-string / URI Innehold Kode for tjeneste. Se kapittel 5.4 for gyldige koder. eb:type non-empty-string Innehold fast verdi = kithservice. Bruk Påkrevet identifikasjon av kodesett ved bruk av kode for til å definere en tjeneste. Ikke påkrevet ved bruk av URI som tjenestedefinisjon. Se kapittel 5.4 for gyldige koder. Indre elementer Eksempel: <eb:service eb:type="kithservice">clin REQ</ eb:service> eb:action Identifiserer hvilken prosess som skal behandle meldingen. Action er et påkrevet element. Dette er en del av en tjeneste og må ha en unik identifikator innen tjenesten. Koder benyttet er må være omfattet av en samhandlingsavtale. Kodeverk og definering av krav til tjeneste må gjøres eksplisitt av KITH, med en presis definisjon av krav til prosessen for hver kode. Se avsnitt for generelle koder beregnet på enkel meldingsutveksling. 24

25 som mottar kvittering vil da kunne identifisere dette som en kvittering eller feilmelding på applikasjonsnivå, og foreta nødvendig prosessering ut fra denne informasjonen. som mottar meldingen må være i stand til å sende den til korrekt applikasjon i avtalt format. tekstnode Tekstnode non-empty-string Innehold Kode for tjeneste. Se avsnitt Indre elementer Eksempel: <eb:action>newmessage</eb:action> eb:messagedata Innkapsling av elementer som gir mulighet for en unik identifikasjon av en XML-melding og tidspunkt for generering av melding. Dette er et påkrevet element. I denne sammenhengen skal det refereres til når konvolutten ble generert, og ikke når payload ble generert. Om en benytter en type meldingssentral kan det defineres et siste tidspunkt for formidling av denne meldingen. Dette forutsetter tilgang for transittnoder å prosessere "SOAP:Header". container node Tekstnode Indre elementer eb:messageid (1) eb:timestamp (1) eb:reftomessageid (0..1) eb:timetolive (0..1) Eksempel: <eb:messagedata> <eb:messageid>ahus </eb:messageid> <eb:timestamp> t12:45:32</eb:timestamp> <eb:reftomessageid>drdygo </eb:reftomessageid> <eb:timetolive> t14:45:32</eb:timetolive> </eb:messagedata> eb:messageid Skal inneholde en global unik identifikator for hver melding. Hvilket applikasjonslag som skal generere denne er avhengig av bruken. I valgt arkitektur er det naturlig at genererer denne identifikatoren. Denne meldingsid kan være en kombinasjon av id utstreder med klokke og teller er en mulig variant. Denne id vil gjelde konvolutt samt samtlige vedlegg i meldingen. tekstnode Tekstnode non-empty-string Innehold Global unik identifikator for meldingen Indre elementer Eksempel: <eb:messageid>ahus </eb:messageid> eb:timestamp Påkrevet for å angi tid da meldingen eller konvolutten ble generert. ebxml presiserer bruk av UTC. tekstnode Tekstnode datetime, CCYY-MMThh:mm:ss Innehold Tidspunkt for generering av konvolutt Indre elementer Eksempel: <eb:timestamp> t12:45:32</eb:timestamp> 25

26 eb:reftomessageid Gir referanse til en tidligere melding som denne meldingen er et svar på. Innehold i dette elementet er fra "eb:messageid" elementet i meldingen den er et tilsvar på. Benyttes ikke om dette er første melding i en konversasjon eller dialog. Påkrevet ved endring, nysending samt kansellering av tidligere melding. Er et påkrevet element når denne konvolutt benyttes til kvittering eller feilmelding på applikasjonsnivå. tekstnode Tekstnode non-empty-string Innehold Referanse til tidligere melding Indre elementer Eksempel: <eb:reftomessageid>drdygo </eb:reftomessageid> eb:timetolive Gir tidspunkt for når en melding skal være hos mottaker. Om tiden for levering har gått ut, skal det sendes en feilmelding til avsender. Om dette elementet benyttes må hos mottaker kunne forholde seg til dette kravet. Er ikke påkrevet, og kan benyttes ved bruk av meldingssentral som videresender meldinger. tekstnode Tekstnode datetime CCYY-MM-DDThh:mm:ss Innehold Deadline for levering Indre elementer Eksempel: <eb:timetolive> t14:30:47</eb:timetolive> eb:duplicateelimination Indikerer at denne meldingen er sendt tidligere med identisk identifikator for melding. Benyttes om ved sending av melding som muligens er sendt tidligere samt ny sending av melding ved uteblitt kvittering. Tekstnode Indre elementer Eksempel tomt element <eb:duplicateelimination/> eb:description Mulig for en tekstlig beskrivelse av meldingen, hensikt etc. Det er en tekst som er beregnet for lesing av mennesker. Ikke påkrevet, benyttes om ønskelig. tekstnode med attributt Tekstnode non-empty-string Innehold Tekstlig beskrivelse xml:lang non-empty-string to karakterer Innehold Kode to bokstaver. Default = no Bruk Påkrevet. Definerer språk i beskrivelsen. Indre elementer Eksempel: <eb:description xml:lang="no">legeerklaering</eb:description> 26

27 ab:ackrequested Benyttes når det er krav om en kvitteringsmelding for konvolutten. En definert samhandlingsprosess kan kreve at kvitteringsmelding skal sendes uansett, og dette elementet benyttes når en ønsker kvittering selv om ikke er påkrevet i følge definert samhandling. Foreløpig benyttes utelukkende attributtet "eb:signed" for å indikere om kvitteringsmeldingen må være signert. Innhold i dette attributtet er "true" eller "1" for krav om signert kvittering. Om det ikke er krav om signatur benyttes "false" eller "0". Signatur behandles i et eget dokument. Tekstnode Indre elementer Eksempel: tomt element med attributt eb:version string Innehold Fast verdi = 2.0 Bruk Påkrevet. Definerer versjon av ebxml Message Services soap:mustunderstand boolsk Innehold (true 1) (false 0) Bruk Påkrevet. Definerer krav til at mottaker kan prosessere innholdet innkapslet av AckRequested. Om mottaker ikke kan utføre prosesseringen må det resultere i en feilmelding soap:actor non-empty-string Innehold anyuri Bruk Ikke påkrevet. SOAP attributt med URI hvor rollen som skal ha kvittering er definert. Default opprinnelig sender av melding. eb:signed boolsk Innehold (true 1) (false 0) Bruk Påkrevet. Definerer krav til mottaker om signert eller usignert kvitteringsmelding. <eb:ackrequested eb:version="2.0" soap:mustunderstand="1" eb:signed="1"/> ds:signature Signering av konvolutten utført av. Signatur behandles i et eget dokument. Se også kapittel SOAP:Body Innkapsling av informasjon om vedleggene i meldingen. Det er ikke noe payload i body slik der er spesifisert SOAP. Meldingsdelene (payload) kommer i en MIME konvolutt. Ut fra det som er skrevet over er "Body" i denne konvolutten ikke nødvendig å ha med, og kan være et tomt element. Det kan benyttes til å gi referanser til samtlige MIME vedlegg som følger i denne meldingen. Tekstnode Indre elementer container node Vanlig melding: Manifest (0..1) Kvittering og feilmelding applikasjon: Manifest (1) 27

28 eb:manifest Figur 15 Grafisk oversikt over eb:manifest. Denne ligger i SOAP:Body og inneholder referanser til MIMEvedleggene der forretningsdokumentene (payload) ligger. Manifest er innkapsling av elementer som gir informasjon om MIME vedleggene. Påkrevet ved bruk av konvolutt til overføring av kvitteringer eller feilmeldinger på applikasjonsnivå. Tekstnode Indre elementer eb:reference container node med attributt eb:version non-empty-string Innehold Fast verdi = 2.0 Bruk Påkrevet. Definerer versjon av ebxml Message Services Vanlig melding eb:reference (1..*) Kvittering og feilmelding applikasjon: eb:reference (2..*) Innkapsling av informasjon om innhold i datastrømmer som kommer etter ebxml konvolutten, der meldingsinnholdet kommer ligger i et MME vedlegg. Om benyttet bør det være et "eb:reference" element for hvert MIME vedlegg hvor signaturinformasjon befinner seg. For feilmelding eller kvittering applikasjon, benyttes en ordnet rekke med to og to referanser. Første referanse i et sett er adresse til MIME vedlegget i opprinnelig melding. Dette første "eb:reference" elementet inneholder ingen signaturinformasjon. Andre referanse i settet er adresse til MIME vedlegget i denne meldingen, som er kvittering eller feilmelding. Om payload er signert, må sette andre "eb:reference" elementet inneholde nødvendig informasjon om signaturen. Selve kvitteringen / feilmeldingen ligger som payload i denne meldingen. Anbefaler en konvolutt for hver applikasjonskvittering eller feilmelding, da det er enklere å forholde seg til ett sett URI referanser. Tekstnode Indre elementer eb:schema (0..*) eb:description (0..*) container node med attributt xlink:type string Innehold Fast verdi = simple Bruk Ikke påkrevet. xlink:href anyuri Innehold URI Bruk Påkrevet. URI for referanse til payload i MIME konvolutt xlink:role anyuri Innehold URI Bruk Ikke påkrevet. URI til informasjon som definerer payload 28