Riktlinjer för meddelandetyper

Bild illustrerar parter som deltar inom SDK. Förvaltare av meddelandetyp ansvarar för hantering av meddelandetyper.

Federationen tillhandahåller en säker infrastruktur för informationsöverföring mellan anslutna deltagare. För att möjliggöra säker och stabil meddelandeöverföring tillhandahåller federationen gemensamma regelverk och tekniska komponenter.

Federationen ansvarar för att parter kan utbyta information på ett tillförlitligt, säkert och effektivt sätt. Riktlinjer för förvaltning av meddelandetyper och Riktlinjer för meddelandetyper skapar förutsättningar för ett långsiktigt och stabilt informationsutbyte mellan deltagare.

Detta dokument innehåller riktlinjer för utformning och dokumentation av meddelandetyper inom federationer (SDK). Syftet är att säkerställa att dokumentationen stöder både verksamhetens och teknisk personals behov vid verksamhetsinförande och teknisk implementation av meddelandetjänster och meddelandeklienter.

1.1 Övergripande riktlinjer

• Informationsmängder och datatyper ska vara tydligt definierade och dokumenterade.
• Regler kopplade till informationsmängder och datatyper ska vara tydligt dokumenterade.
  • Frivilliga och obligatoriska värden
  • Värdemängder: uttömmande uppräkning av giltiga värden (klartext), med eventuell kod, eller hänvisning om värdemängden är externt förvaltat (t.ex. Län- och kommunkoder).
  • Valideringsregler för informationsmängder
  • Kvalificering av deltagare
• Ett definierat tekniskt format som kan valideras ska användas.

Riktlinjerna består av:

• Riktlinjer för förvaltningsorganisation meddelandetyp
• Riktlinjer för meddelandetyper (informationen på denna sida)

2. Klassificering av meddelandetyp

Meddelandetyper inom Säker digital kommunikation (SDK) klassificeras utifrån olika aspekter av interoperabilitet. Klassificering syftar till att tydliggöra för intressenter meddelandetypens mognadsgrad vid införande i deltagarens verksamhetsprocesser och verksamhetssystem.

3. Informationsarkitektur (Semantisk interoperabilitet)

3.1 Inledning

Detta avsnitt innehåller regler för informationsbeskrivningar i form av grafiska modeller för meddelandetyper inom Säker digital kommunikation. Dessa beskrivningar tas fram och publiceras av förvaltaren av meddelandetypen. Modeller är av typerna informationsmodeller och begreppsmodeller. För att meddelandetyper ska klassificeras som semantiskt interoperabla, ska dess beskrivningar följa samtliga regler som utrycks med SKA.

Reglerna uttrycks antingen som krav eller uppmaningar:

• Regler som uttrycks med SKA är krav, som ska följas.
• Regler som uttrycks med BÖR är uppmaningar, som bör följas.

Regler beskrivs enligt följande mönster:

3.2 Modelltyper

3.2.1 Begreppsmodell

Begreppsmodellens syfte är att definiera begrepp och dess relationer till andra begrepp.

3.2.2 Informationsmodell

Syftet med en informationsmodell är att beskriva den information som förmedlas i en meddelandetyp, eller, om det är lämpligt, flera av eller alla förvaltarens meddelandetyper. En informationsmodell bör vara spårbar till motsvarande begreppsmodell. Modellen är teknikneutral och anpassad för utbyte av information.

3.2.3 Standarder

Att tillämpa standarder är ett effektivt sätt att skapa igenkänning, jämförbarhet och högre kvalitet över organisations-, eller sektorsgränser. Enligt Svenskt ramverk för digital samverkan, rekommendation 8 – Använd standarder i första hand Länk till annan webbplats., ska offentliga organisationer använda standarder och rekommendationer. För att minska inlåsnings- och exkluderingseffekter så är öppna och fria standarder att föredra.

Det är därför viktigt att förvaltaren av meddelandetyp för respektive meddelandetyp säkerställer att det finns beskrivet vilka eventuella standarder som tillämpats och var dessa finns att ta del av.

3.3 Gemensamma regler för begreppsmodeller

Förvaltare av meddelandetyper BÖR publicera, eller hänvisa till redan publicerade begreppsmodeller, som beskriver begrepp som förekommer i en meddelandetyp eller, om det är lämpligt, flera av eller alla förvaltarens meddelandetyper.

Om förvaltaren av meddelandetyp publicerar begreppsmodeller bör förvaltaren i möjligaste mån följa relevanta delar av det gemensamma regelverk för begreppsmodeller som uttrycks i Ramverk för nationella grunddata inom den offentliga förvaltningen, bilaga informationsarkitektur Länk till annan webbplats..

I det följande beskrivs avvikelser från eller kompletteringar till nämnda bilaga.

Begrepp ska återanvändas

3.3.1 Regel

Begrepp SKA återanvändas mellan en förvaltares meddelandetyper, och, om möjligt inom SDK och BÖR återanvändas från relevanta grunddatadomäner. Om förvaltare publicerar modeller med begrepp som refererar till en annan begreppsmodell ska de ha samma definition och beskrivning. För dessa begrepp ska en referens, tex. i form av en länk (URL), anges.

Anledning: Återanvändning är en förutsättning för att förstå sammanhang och få en enhetlig terminologi.

Konsekvens: Förvaltaren av meddelandetyp ska säkerställa återanvändning. Federationsägaren uppmanar förvaltarna av meddelandetyper att arbeta för en enhetlig terminologi

3.4 Gemensamma regler för informationsmodeller

Förvaltare av meddelandetyper SKA publicera informationsmodeller som beskriver den information som förmedlas i en meddelandetyp, eller, om det är lämpligt, flera av eller alla förvaltarens meddelandetyper, och, om möjligt relatera dessa till referens-informationsmodeller (t.ex. grunddatadomänmodeller).

Detta avsnitt redogör för ett antal regler för informationsmodeller till stor del gemensamma med de regler som uttrycks i Ramverk för nationella grunddata inom den offentliga förvaltningen, bilaga informationsarkitektur Länk till annan webbplats.. De utgör en minsta gemensam nämnare för informationsmodellens form och innehåll.

Reglerna rör både informationsmodellernas form och innehåll, både själva informationsmodellen/diagrammet och dess olika modellelement.

Notation BÖR vara beskriven och dokumenterad

3.4.1 Regel

Förvaltaren av meddelandetyp BÖR definiera, dokumentera och publicera beskrivning av domänens notation.

Anledning: Regeln syftar till att underlätta för den som ska läsa informationsmodellen. En tydlig beskrivning ökar och underlättar förståelsen.

Konsekvens: Förvaltaren av meddelandetyp bör beskriva sina notationsval, gärna i dialog med federationsägaren. Beskrivningarna publiceras i anslutning till de informationsmodeller som publiceras.

Informationsmodeller bör beskrivas i UML

3.4.2 Regel

Notationen som används av en förvaltare av meddelandetyper SKA vara enhetlig och BÖR vara UML.

Anledning: Regeln syftar till att underlätta för den som ska läsa informationsmodellerna. Läsbarhet och förståelse underlättas om alla informationsmodeller publicerade av en förvaltare av meddelandetyper samtliga meddelandetyper har samma notation, och också om olika förvaltare har samma notation.

Konsekvens: De förvaltare av meddelandetyper som använder annan etablerad notation kan använda denna. I de fall UML inte används är det extra viktigt att beskriva och dokumentera sin notation.

Informationsmodeller publicerade av en förvaltare av meddelandetyper ska ha ett enhetligt utseende

3.4.3 Regel

Informationsmodell och dess modellelement, publicerade av en förvaltare av meddelandetyper, SKA ha ett enhetligt visuellt utseende

Anledning: För att läsaren av informationsmodellerna SKA känna igen sig ska de ritas på ett likartat sätt. Detta gäller för alla modellelement.

Konsekvens: Förvaltaren av meddelandetyper SKA beskriva sina val gällande grafiskt uttryck. Beskrivningarna ska publiceras i anslutning till de informationsmodeller som publiceras.

Namnsättningsregler BÖR följas

3.4.4 Regel

Namnsättning BÖR vara enhetlig för informationsmodellerna inom SDK och grunddataramverket.

Anledning

Anledning

Informationsmodeller inom SDK och olika grunddatadomäner får ett gemensamt utseende. Enhetlighet underlättar läsbarhet och förståelse av informationsmodellen.

Konsekvens

Förvaltaren av meddelandetyper ansvarar för publicering av informationsmodeller och måste kvalitetssäkra enhetlighet.

Informationsmodeller kan vara framtagna i internationell samverkan, då kan förvaltaren av meddelandetyp vara förpliktigad att använda annat språk än svenska.

Informationsobjekt ska ha entydiga namn

3.4.5 Regel

Informationsobjekt SKA ha entydiga namn som är fullständiga och inte förkortade.

Anledning

Entydiga namn underlättar förståelsen och läsbarheten av informationsmodellen. Namnen uttrycks så att de i möjligaste mån är självklara för läsaren. Förkortningar ska inte användas då de riskerar att missförstås.

Konsekvens

Informationsobjekt som återanvänds från en annan informationsmodell eller annan grunddatadomän ska ha samma beskrivning.

En informationsmodell ska ha metadata

3.4.6 Regel

Alla informationsmodeller SKA ha information om namn, version, beslutsdatum, syfte och kontaktuppgifter till förvaltningsgrupp.

Anledning

Regeln syftar till att öka läsbarhet och förståelse. Det skapar en trygghet i användande av informationsmodellen om giltighet är tydligt angivet.

Konsekvens

På detta sätt skapas en enhetlighet i dokumentationen av informationsmodeller inom SDK och ramverket för nationella grunddata.

Värdemängder och datatyper ska ha entydiga namn

3.4.7 Regel

Värdemängder och datatyper SKA ha entydiga namn som är fullständiga och inte förkortade.

Anledning

Entydiga namn underlättar förståelsen och läsbarheten av informationsmodellen. Namnen uttrycks så att de i möjligaste mån är självklara för läsaren. Förkortningar ska inte användas då de riskerar att missförstås.

Konsekvens

Namn kan behöva ha ett förled för att vara entydigt. Att använda namnet ”status” är inte tillräckligt tydligt. Genom att till exempel använda förledet ”ärende” har vi ett tydligare namn: ”ärendestatus”.

Värdemängder och datatyper som återanvänds från en annan informationsmodell eller grunddatadomän ska ha samma beskrivning.

Krav på dokumentation av informationsmodellens ingående delar

3.4.8 Regel

Följande uppgifter SKA eller BÖR minst anges för klass/informationsobjekt, attribut respektive relation.

Anledning

Ett gemensamt beskrivningssätt för informationsmodellerna inom SDK och ramverket nationellt grunddata, underlättar läsbarhet och förståelse.

Konsekvens

Det ska av notationens beskrivning framgå hur dessa uppgifter visas, till exempel i den visuella informationsmodellen eller i dokumentation kopplad till informationsmodellen. Multiplicitet ska visas grafiskt i informationsmodellen. Illustrativa exempelförekomster får gärna användas.

Klasser/informationsobjekt ska återanvändas

3.4.9 Regel

Klasser/informationsobjekt SKA återanvändas inom en förvaltare av meddelandetyper. Om det är möjligt SKA klasser/informationsobjekt från referens-modeller (till exempel Grunddatadomänerna Persons Fysisk Person, Företags Organisation eller Geodatas Fastighet) återanvändas. Om det är möjligt kan klasser/informationsobjekt från andra förvaltare av meddelandetyper återanvändas eller refereras till. Eventuella frånsteg ska motiveras.

Anledning

Återanvändning är en förutsättning för att förstå sammanhang och för att undgå redundans.

Konsekvens

Förvaltaren av meddelandetyp ska säkerställa återanvändning av klasser/informationsobjekt.

Informationsobjekt BÖR ha en unik identitet

3.4.10 Regel

Alla klasser/informationsobjekt BÖR ha eller av förvaltaren av meddelandetyp tilldelas persistent och unik identitet.

Anledning

För att säkra en hög kvalitet på hanteringen av klasser/informationsobjekt bör det finnas en unik identitet under dess hela livscykel. I den mån ett informationsobjekt med unik identitet är återanvänt bör denna identitet användas. Den unika identiteten ger entydighet och underlättar för förståelse och tillgänglighet till detta data.

Konsekvens

Användning av beständiga identifierare säkerställer att informationen blir möjlig att referera till över tid.

4. Tekniskt format (Teknisk interoperabilitet)

En meddelandetyps tekniska format kan vara av olika format beroende på bransch, syfte och teknisk miljö. SDKs infrastruktur stödjer alla typer av tekniska format.

Exempel på tekniska format:

• XML (Extensible Markup Language)

• CSV (Comma-Separated Values)
• YAML (Yet Another Markup Language)
• Binära dataformat (ZIP, Avro, Protocol Buffers etc)

Rekommendation: Valet av tekniskt format BÖR utgå från verksamhetsbehov, men format som XML eller JSON rekommenderas för hög interoperabilitet.

4.1 Minimikrav tekniskt format

Med tekniskt format avses den standard och struktur som beskriver och gör informationen maskinellt tolkningsbar (t.ex. XML eller JSON). En meddelandetyp ska använda ett tekniskt format som är allmänt tillgängligt för moderna tekniska plattformar.

Nedanstående krav ställs på tekniskt format;

1. Tydlig struktur och läsbarhet.
   1. Formatet SKA följa en logisk och väldefinierad struktur (exempelvis nyckel-värdepar, trädstruktur eller tabellformat).
   2. Maskinläsbarhet, formatet SKA kunna tolkas och processas av system utan manuell handpåläggning.
2. Standardisering och interoperabilitet
   1. SKA följa en etablerad standard.
   2. Stöd för flera plattformar och teknologier. Tekniskt format SKA kunna användas i olika programmeringsspråk och systemmiljöer.
3. Validering och felsäkerhet
   1. Formatet SKA stödja en metod för att valideras.
   2. Felhantering – Formatet SKA möjliggöra felhantering.
   3. Exempel på händelser och felkoder som kan förekomma för meddelandetypen SKA dokumenteras.

Motiv: Ett tekniskt format måste definieras för meddelandetypen för att möjliggöra plattformsoberoende systemintegration. Formatet behöver kunna implementeras av vanligt förekommande tekniska ramverk.

4.2 Identifierare av och namn för meddelandetyp och schema

Identifieraren används för:

• Teknisk adressering vid meddelandeöverföring (SMP, eDelivery dynamic discovery)
• Verksamhetsadressering (Adressbok)
• Skapa- och validera utgående och inkommande meddelanden (schema validering)

Regler för identifierare:

1. Identifieraren SKA vara unik inom SDK federationen.
2. Identifierare ska ha följande struktur: {DocumentNamespace}::{DocumentType}##{CustomizationID}::{Version}::{transportmodell}
   1. Observera att ”http://”, ”http://” eller ”/” inte får ingå i identifieraren.

Motiv: Identifieraren måste vara unik för att teknisk adressering och validering skall fungera inom SDK federationen (se dynamic discovery).

För att underlätta hanteringen av meddelandetyper i adressboken ska meddelandetypsförvaltaren ange ett namn på meddelandetypen i tillägg till identifieraren. Detta ska vara läsbart av människor och koncist beskriva meddelandetypen. Meddelandetypens namn ska vara unikt inom federationen och godkännas av federationsägaren.

4.3 Strukturering och utformning av schema

Avsnittet beskriver hur tekniska scheman BÖR struktureras för en meddelandetyp. En meddelandetyp SKA innehålla ett tekniskt schema (t.ex. JSON schema) som validerar meddelandetypen meddelanden.

Nedanstående krav ställs på meddelandetypens schema;

1. Konsekvent datastruktur
   1. Namnstandard: Fält- och attributnamn SKA vara konsekventa och om möjligt härledas till informationsmodell samt vara beskrivande och undvika specialtecken inklusive nationella tecken.
   2. Datatyper: Definiera tydligt vilka datatyper som används (exempel: sträng, nummer, datum, boolesk etc).
   3. Hierarkisk eller platt struktur: Schemat BÖR följa en logisk och väldefinierad struktur.
   4. Nestling/indentering: Hierarki (t.ex. JSON, XML) BÖR hållas minimalt för att undvika komplexitet.
2. Validerbarhet och schema-definition
   1. Schema SKA ha en definition som beskriver regler för meddelandetypens data (t.ex. JSON Schema).
   2. Schema SKA reglera obligatoriska och frivilliga/valfria fält.
   3. Formatvalidering BÖR tillämpas (t.ex. max-/minlängd, format).
   4. Meddelanden BÖR innehåller en referens till schema för validering.
3. Utökning och versionering
   1. Strukturen måste tillåta att nya fält läggs till utan att bryta befintliga system (implementationer).
   2. Versionshantering SKA användas för kompatibilitet (stödja kompabilitetskontroll).
4. Datatyper och standardiserade format
   1. Använd ISO-standarder för datum och tid – ISO 8601 (t.ex. "2024-03-03T14:00:00Z").
   2. Tydlig hantering av numeriska värden: Decimaltecken, negativa tal och enheter bör definieras.
5. Dokumentation
   1. Dokumentationstaggar BÖR användas
   2. Exempeltaggar BÖR inkluderas i schema
   3. Exempelmeddelanden SKA inkluderas i paketeringen

Motiv: För att säkerställa teknisk interoperabilitet måste meddelanden kunna valideras t.ex. med stöd av schema. Schema för meddelandetyper måste vara dokumenterade på ett sätt som ger stöd vid implementation.. Stora komplicerade scheman undvikas. Endast datatyper som används av meddelandetypen bör inkluderas i schema.

4.4 Paketering av meddelandetypen filer (schemafiler)

För att underlätta livscykelhantering kan det underlätta om namnsättning av schemafiler spegla meddelandetypens identifierare och version

1. Identifierare BÖR användas för att lätt kunna koppla ihop schemafiler och relaterade resurser. Namnsättning är ett hjälpmedel för mänsklig läsare och inte en valideringsmekanism.

Motiv: Federationsägaren vill underlätta hantering av meddelandetyper och dess versioner. Det är viktigt att kunna särskilja olika meddelandetyper och dess versioner på ett enkelt sätt.

4.5 Obligatorisk och rekommenderade attribut i meddelandetyp

• Datum för meddelande: creationDateTime
• SKA Meddelande-id: messageId
• BÖR conversationId
• BÖR refToMessageId
• BÖR Avsändande deltagarorganisation: sender (participant-id)
• BÖR Mottagande deltagarorganisation: recipient (participant-id)
• BÖR Avsändande funktionsadress: sender.attention.subOrganization.extension (identifier)
• BÖR Mottagande funktionsadress: recipientAttention.subOrganization.extension (identifier)

4.6 API för meddelandetyp

En API specifikation för integration mellan Meddelandetjänst (API producent) och Meddelandeklient BÖR tas fram för att underlätta lokal integration.

Meddelandetypens API SKA stödja följande statusar:

1. Stödja meddelandestatus (fetstil obligatoriska) enligt Rekommendation API MT/MK
   1. SCHEDULED
   2. SUBMITTED
   3. SCHEDULED_FOR_RESEND
   4. ACKNOWLEDGE
   5. WAITING_FOR_RECEIPT
   6. MESSAGE_EXCHANGE_ERROR
   7. ACCEPTED
   8. REJECTED
   9. RETRIEVED
   10. RECEIPT_SENT
   11. NEW
   12. ERROR
       
       
2. Stödja attribut enligt Rekommendation API MT/MK | Digg
   1. Meddelandestatus: messageStatus
   2. Datum för meddelande: creationDateTime
   3. Meddelande-id: messageId
   4. conversationId
   5. refToMessageId
   6. Avsändande deltagarorganisation: sender (participant-id)
   7. Mottagande deltagarorganisation: recipient (participant-id)
   8. Avsändande funktionsadress: sender.attention.subOrganization.extension (identifier)
   9. Mottagande funktionsadress: recipientAttention.subOrganization.extension (identifier)
   10. Objekt för felhantering: events
3. Stödja rekommenderade säkerhetsprotokoll Rekommendation API MT/MK | Digg Länk till annan webbplats.
4. Stödja moderna integrationsprotokoll som t.ex. REST
5. Dokumentera API specifikation enligt en etablerad standards t.ex. openAPI.
6. Innehålla nödvändig dokumentation för att stödja integration enligt Rekommendation API MT/MK | Digg Länk till annan webbplats..

Motiv: För att underlätta lokal integration av meddelandetyp behöver ett API tas fram som stödjer meddelandetypen.

4.7 Användandet av meddelandekvittens

Alla meddelandetyp SKA använda en meddelandetyp för meddelandekvittens. Meddelandekvittens signalerar att meddelandet har levererats och kommer hanteras av mottagande deltagarorganisation.

Meddelandetypen SKA tillämpa ett koncept för meddelandekvittering:

1. BÖR stödja standardiserad ”Meddelandekvittens” enligt Meddelandespecifikation Meddelandekvittens
2. Om ett eget koncept för meddelandekvittens tillämpas SKA denna motiveras och beskrivas i enlighet med dessa riktlinjer.

Motiv: SDK infrastrukturen transportprofil Utökad bas tillämpar ett asynkront integrationsmönster. Detta innebär att alla meddelanden behöver kvitteras med en meddelandekvittens för att sändande deltagare skall anse att meddelandet levererats korrekt.

5 Tillämpningsanvisning (Organisatorisk interoperabilitet)

5.1 Verksamhetsflöden

För att stödja ett effektivt verksamhetsinförande vid användning av en meddelandetyp, bör tillhörande processbeskrivningar tas fram. Dessa beskrivningar fungerar som ett gemensamt stöd för förståelse och implementering i berörda verksamheter.

1. En processbeskrivning som beskriver verksamhetsprocessen SKA tas fram i samband med framtagandet av en meddelandetyp.
2. Processbeskrivningen BÖR följa ett vedertaget ramverk eller standard, exempelvis:
   BPMN 2.0 (Business Process Model and Notation) – för grafiska modeller.
3. Processbeskrivningen BÖR tydligt redovisa följande aspekter:
   1. Deltagande aktörer (roller eller system) i processen
   2. Respektive aktörs ansvar i processens olika steg
   3. Informationsflöden mellan aktörer och system
   4. Start- och slutpunkter för processen

Motiv: Standardiserade och tydligt strukturerade processbeskrivningar gör det enklare att införa och samordna informationsflöden baserade på meddelandetypen. De bidrar till gemensam förståelse, högre kvalitet och bättre interoperabilitet mellan aktörer.

5.2 Tillgänglighetskrav (Service Level Agreements)

Förvaltare av meddelandetyp behöver definiera tillgänglighetskrav för deltagares verksamhet som använder meddelandetypen.

Tillgänglighetskrav ska primärt riktas mot verksamheten och dess verksamhetssystem (Meddelandeklient) som använder meddelandetypen då SDK definierar tillgänglighetskrav på anslutande system (Accesspunkt, Meddelandetjänst).

Förvaltaren SKA ta fram en SLA som omfattar:

1. Svarstider för handläggning
2. Verksamhetens tillgänglighet

Förvaltaren BÖR inkludera följande:

3. Uppskattade volymer

Motiv: Deltagarorganisationer behöver förstå vilka krav meddelandetypen ställer på verksamhet och verksamhetssystem. Detta för att integrera rätt verksamhet och verksamhetssystem.

6 Rättsliga förutsättningar och informationssäkerhet (Juridisk interoperabilitet)

För att underlätta införande av en meddelandetyp behöver anslutande verksamhet säkerställa att juridiska förutsättningar och informationssäkerhetsaspekter är beaktade.

6.1 Informationsklassning

Informationsklassning är ett obligatoriskt steg när deltagare utbyter information med stöd av meddelandetyper inom SDK.

SDK utgår från det metodstöd och rekommendationer som Myndigheten för samhällsskydd och beredskap (MSB 0040-09) tagit fram för informationssäkerhetsklassning där SDK som helhet (informationsbärare) är dimensionerad att hantera information enligt konsekvensnivå 3 (t.ex. känsliga personuppgifter).

Läs mer om SDK:s informationssäkerhet och informationsklassning här: Rekommendation för informationssäkerhet och teknisk IT-säkerhet | Digg Länk till annan webbplats.

Förvaltaren av meddelandetypen ansvarar för att ta fram en stödjande och vägledande beskrivning av informationssäkerhetsnivå. Detta för att deltagarorganisationer skall kunna avgöra egna sina egna förutsättningar för att använda meddelandetypen.

1. Förvaltaren ansvarar för att informationssäkerhetsklassificera meddelandetypen i enlighet med Rekommendation för informationssäkerhet och teknisk IT-säkerhet

Motiv: Federationsägaren (Digg) behöver säkerställa att deltagare som vill använda meddelandetyper har goda förutsättningar att införa och börja använda en meddelandetyp i sin verksamhet.

6.2 Juridiska förutsättningar

Informationsmängder som utbytes mellan deltagare inom federationen behöver en rättslig grund.

Förvaltaren av meddelandetypen ansvarar för att ta fram en stödjande och vägledande beskrivning av juridiska förutsättningar. Detta ska stödja deltagarorganisationernas egna utredningar om förutsättningarna för informationsutbyte med den nya meddelandetypen.

Förvaltaren behöver stödja ansluten deltagare med information om:

• En rättslig grund finnas för själva informationsutbytet.
• Sekretessregler som möjliggör utlämnandet.
• Mottagarens rätt att ta emot meddelandet.
• Avtal och tekniska lösningar stödja säker datadelning.

Förvaltarens ansvar:

1. Förvaltare av meddelandetyp SKA beskriva juridiska förutsättningar för informationsutbyte med stöd av meddelandetypen.

Motiv: För att underlätta införande av en meddelandetyp BÖR de juridiska förutsättningar för användandet av meddelandetypen vara beskrivna.

6.3 Licens

Dokumentationen ska tydligt ange vilka eventuella licensvillkor som gäller för nyttjande av specifikationen för meddelandetypen.

Motiv: Federationsägaren (Digg) behöver säkerställa att både deltagare och leverantörer som implementerar eller vidareutvecklar stöd för meddelandetyper är fullt informerade om gällande licensvillkor. Det inkluderar rätten att nyttja, implementera, modifiera och distribuera specifikationen samt förståelse för eventuella villkor för detta.

Bilaga: Fördjupning identifierare för meddelandetyp

Avsikten med denna bilaga är att fördjupa förklaringen av hur DocumentIdentifier används.

Hur används ”DocumentIdentifier”

Varje meddelandetyp ska ha en unik identifierare inom SDK federationen.

För att underlätta hanteringen av meddelandetyper i adressboken ska meddelandetypsförvaltaren ange ett namn på meddelandetypen i tillägg till identifieraren. Detta ska vara läsbart av människor och koncist beskriva meddelandetypen. Meddelandetypens namn ska vara unikt inom federationen och godkännas av federationsägaren.

Identifieraren används för följande:

Identifiering av deltagarens meddelandetyper i SMP.

Kodexempel från sdk-docs/Meddelandesystem/Meddelandetyper at main · diggsweden/sdk-docs · GitHub Länk till annan webbplats.

Identifiering av meddelandetyp i XHE kuvert. XHE.Header

XHE.Payloads.Payload.DocumentTypeCode (krypterad)

Exempel för en JSON meddelandetyp

Exempel utifrån struktur {DocumentNamespace}::{DocumentType}##{CustomizationID}::{Version}

Exempel på registreringbefintliga meddelandetyper:

SDK meddelande:

XML: urn:riv:infrastructure:messaging:MessageWithAttachments:3::messagePayload##3.0::tm-base-ext-sigenc

JSON:
digg.se/riv/infrastructure/messaging/MessageWithAttachments-3.schema.json::fdc:digg.se:edelivery:messagetype:MessageWithAttachments:json##3.0::tm-base-ext-sigenc

Meddelandekvittens:

XML:
urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##fdc:digg.se:edelivery:messagetype:response:1::2.1::tm-base-ext-sigenc

Bilaga XHE exempel

payLoadcontent – json meddelande

Avkodad base64 sträng innehåller komplett JSON meddelande.

JSON meddelande – schema