FAQ för nya meddelandetyper

En meddelandetyp i SDK är ett överenskommet format för information som skickas mellan organisationer. Formatet beskriver vilken slags information som ingår, hur informationen struktureras (det vill säga vilka fält som finns) och hur informationen ska tolkas av mottagaren.

Med en ny meddelandetyp menas att man har definierat ett nytt, standardiserat format för ett visst behov. Exempel på format skulle kunna vara IT-incidentrapport, intyg, statistikleverans eller remiss.

I riktlinjerna beskrivs att varje meddelandetyp ska ha en tydlig begreppsmodell, informationsmodell och teknisk specifikation. Det gör att alla som använder meddelandetypen förstår varandra och menar samma sak.

Det finns flera anledningar till att införa nya meddelandetyper i SDK. Det kan finnas ett behov av att kunna utbyta information på ett mer strukturerat sätt, inte bara som fria dokument. En annan anledning kan vara behovet av att lättare bygga automatiska flöden och integrera olika system med varandra. I riktlinjerna anges att meddelandetyper ska bidra till interoperabilitet. Nya meddelandetyper gör det enklare att återvända samma informationsmodell i flera system och processer.

I SDK finns idag två olika meddelandetyper. Den första är SDK-meddelande för ostrukturerat innehåll med bilagor. Den andra är Meddelandekvittens vilket i praktiken är ett svar på om meddelandet har accepterats eller inte.

De nya riktlinjerna i SDK öppnar för att det ska kunna finnas fler meddelandetyper som är mer domänspecifika. De skulle till exempel kunna användas för särskilda rapporter, särskilda beslut eller intyg samt särskilda samverkansunderlag.

Vilka meddelandetyper som faktiskt tas fram beror på vilket behov du har inom din verksamhet. Viktigt att komma ihåg när du tar fram en ny meddelandetyp är att utse en roll som har ansvar för förvaltning och utveckling.

Nya meddelandetyper kan användas av alla verksamhetsområden som har återkommande informationsutbyte, behov av att standardisera innehållet eller av två eller fler aktörer som behöver ta del av samma information. Exempel på verksamhetsområden är socialtjänst, utbildning, arbetsmarknad, hälso- och sjukvård, statistik, krisberedskap, tillsyns- och rapporteringsprocesser mellan myndigheter. Riktlinjerna är inte specifika för olika verksamhetsområden. Det viktiga är att modellerna är väl definierade och dokumenterade, oavsett domän.

Alla deltagare i SDK behöver inte använda de nya meddelandetyperna. För vissa meddelandetyper kan det bli obligatoriskt inom en viss federationsöverenskommelse eller ett visst regelverk. I andra sammanhang kan det vara frivilligt men rekommenderat för de organisationer som berörs. Enligt riktlinjerna är det förvaltaren för meddelandetypen samt federationsägaren som sätter ramarna. Din organisation behöver ta ställning till vilka meddelandetyper som är aktuella för era processer.

Exempel på när din organisation berörs av en ny meddelandetyp skulle kunna vara när förvaltaren har identifierat er som målgrupp eller om den nya meddelandetypen ingår i en process där ni deltar.

När din organisation ska införa en ny meddelandetyp behöver ni analysera ert behov och hur ni påverkas, kartlägga system, planera införandet, testa och verifiera samt planera för den löpande förvaltningen.

Hanteringen av versioner för nya meddelandetyper beskrivs i riktlinjerna. När du tar fram en ny meddelandetyp ska den ha en egen unik id-beteckning (till exempel en URN) och ha ett namn i adressboken som är lätt att förstå. Det är också viktigt att versionerna är tydligt strukturerade så att det går att följa ändringar över tid.

På en övergripande nivå finns två typer av versioner - major och minor.

Tumregeln är att en majorversion skapas när du gör en ändring som gör att äldre system inte längre kan använda typen. Exempel på en majorversion när man ändrar vad ett fält betyder eller tar bort ett obligatoriskt fält. En minorversion innebär att du gör en mindre ändring som fortfarande fungerar med äldre system. Exempel på en minorversion är att man lägger till ett frivilligt fält eller förtydligar dokumentationen.

Om era befintliga integrationer påverkas när nya meddelandetyper införs beror på om era system ska börja skicka och ta emot den nya meddelandetypen. Det beror också på om era nuvarande integrationer är flexiblet byggda och till exemepel tolererar nya fält.

Riktlinjerna säger att du helst ska göra ändringar som fungerar med äldre versioner och beskriva dem tydligt. Då blir påverkan på andra system så liten som möjligt.

Riktlinjerna beskriver tre olika nivåer av samarbete mellan system och organisationer.

1. Teknisk interoperabilitet. Det betyder att systemen kan utbyta information med varandra. Viktiga komponenter är format, protokoll och adressering.
2. Semantisk interoperabilitet. Det betyder att alla tolkar informationen på samma sätt. Samma ord och fält betyder samma sak för alla tack vare gemensamma modeller och definitioner.
3. Organisatorisk interoperabilitet. Det betyder att arbetssättet hänger ihop mellan organisationerna. Processer, roller och ansvar passar ihop så att samarbetet fungerar i praktiken.

Meddelandetyper tas fram för att öka interoperabiliteten på alla ovanstående nivåer.

Enligt riktlinjerna ska varje meddelandetyp dokumenteras tydligt. Dokumentationen ska innehålla en klassificering till exempel vilken typ av informationsutbyte det gäller, vilken nivå av interoperabilitet som eftersträvas och om meddelandetypen har någon särskild juridisk status. Den ska också beskriva vilka aktörer som ska använda meddelandetypen. Genom dokumentationen kan du som deltagare se om meddelandetypen är avsedd för din typ av organisation. Du kan också se om den är tänkt för mänsklig läsning, maskin-till-maskin eller båda. Dessutom framgår det om det finns särskilda juridiska eller säkerhetsmässiga krav.

Det är viktigt att alla menar samma sak med de termer som används. Det är också viktigt att alla använder samma struktur för informationen.

En begreppsmodell visar vilka begrepp som ingår och hur de hänger ihop, till exempel ärende, beslut eller handläggare.

En informationsmodell visar vilka fält som finns i meddelandetypen, till exempel ärende-ID, beslutsdatum och beslutsfattare. Informationsmodellen visar också hur fälten ska se ut.

Utan begrepps- och informationsmodeller finns en risk att olika parter tolkar fälten på olika sätt. Det kan leda till att man skickar ofullständiga eller felaktiga uppgifter. Därför säger riktlinjerna att båda modellerna ska finnas och ingå i underlaget för varje meddelandetyp.

Begreppsmodellen handlar om vad vi pratar om. Den visar vilka begrepp som finns, hur de hänger ihop och vad de betyder.

Informationsmodellen handlar i stället om hur vi skriver ner samma saker fast som data. Den beskriver vilka fält som ska finnas, vilka datatyper de har och hur de är strukturerade. Till exempel kan begreppsmodellen beskriva begreppet ”Person”. Informationsmodellen visar då hur en person representeras i ett meddelande, med fält som person-ID, namn och personnummer.

Du som arbetar i verksamheten behöver inte kunna XML eller JSON för att använda nya meddelandetyper. Det kan ändå vara bra att känna till att meddelandetyper ofta definieras i något som kallas XML-schema eller JSON-schema. Riktlinjerna säger att varje meddelandetyp ska ha en maskinläsbar specifikation. Det är främst en fråga för tekniker och leverantörer inte för dig som användare i verksamheten.

Om ni behöver uppdatera er meddelandeklient när en ny meddelandetyp kommer beror på hur klienten fungerar i dag.

Om klienten bara hanterar ostrukturerade SDK-meddelanden kan den ibland ta emot en ny meddelandetyp som ett vanligt meddelande. Då fungerar det tekniskt men ni får inte ut full nytta av den nya typen.

Om den nya meddelandetypen kräver särskilt stöd till exempel en strukturerad vy, guidning eller hjälp med ifyllnad, behöver klienten ofta anpassas. Nyttan blir större om klienten kan leda användaren rätt och kontrollera vissa uppgifter innan meddelandet skickas. Därför kan det bli aktuellt med uppdateringar eller mindre anpassningar i vissa fall.

Det är förvaltaren av meddelandetypen som tar fram schemafilerna för en ny meddelandetyp. Förvaltaren ansvarar både för innehållet och för hur det ska beskrivas. Det innebär att samma part tar fram begreppsmodellen och informationsmodellen och även det tekniska schemat, till exempel XML-schema, schematron eller JSON-schema.

Förvaltaren tar dessutom fram exempelmeddelanden. Riktlinjerna säger att den som bestämmer vad meddelandet ska innehålla också ansvarar för hur det ska fungera tekniskt.

Varje meddelandetyp får ett eget unikt ID ungefär som ett personnummer för meddelanden. ID:t följer med i SDK-meddelandet och visar vilken typ av meddelande det är.

När ert system tar emot meddelandet kan det därför förstå om det är ett vanligt, ostrukturerat SDK-meddelande eller en särskild strukturerad meddelandetyp. Utifrån ID:t kan systemet välja rätt regler för att kontrollera att innehållet är rätt. Exakt hur det här fungerar tekniskt står beskrivet i meddelandetypens specifikation.

Om du behöver göra tekniska anpassningar när nya fält tillkommer beror på hur du använder meddelandet. Om du inte läser eller använder det nya fältet behöver du oftast inte göra något. Det spelar också roll hur din klient eller integration är byggd i dag.

Riktlinjerna säger att nya fält helst ska läggas till som frivilliga när det går. De rekommenderar också att mottagande system är byggda så att de klarar att ta emot fler fält än de själva använder. Då kan systemet bara ignorera det som inte behövs. På det sättet kan meddelandetyper utvecklas vidare utan att era system slutar fungera.

Informationsklassning betyder att man bedömer vilken sorts information en ny meddelandetyp kan innehålla och hur känslig den är. Nya meddelandetyper följer SDK-federationens grundprinciper och använder Transportmodell utökad bas. Det innebär att meddelanden som skickas med de nya typerna är krypterade. En meddelandetyp kan ändå innehålla allt från helt öppna uppgifter till känsliga personuppgifter eller sekretessbelagd information.

Riktlinjerna säger därför att förvaltaren ska göra en informationsklassning och skriva ner den i dokumentationen. Förvaltaren ska också beskriva vilka krav klassningen ger till exempel på kryptering, loggning och vem som får ha åtkomst. Som deltagare använder du den här informationen som stöd när ni bestämmer era egna säkerhetsåtgärder. Den är också ett viktigt underlag för er riskanalys och er interna klassning.

Ja, i praktiken behöver ni nästan alltid göra en egen juridisk bedömning när en ny meddelandetyp införs.

Förvaltaren beskriver de juridiska förutsättningarna på en övergripande nivå, till exempel vilken typ av rättslig grund som kan vara aktuell och om informationen kan omfattas av sekretess. Men varje deltagande organisation måste ändå bedöma sin egen roll och sitt ansvar. Det gäller till exempel om ni är personuppgiftsansvariga eller personuppgiftsbiträden, hur sekretess ska hanteras och vilka regler som gäller för gallring.

Ni behöver också försäkra er om att sättet ni använder meddelandetypen på i er verksamhet följer lagstiftningen. Riktlinjerna är alltså ett stöd, men de kan inte ersätta er egen rättsliga analys.

Ja, nya meddelandetyper kan innehålla känsliga personuppgifter, men det är inte alltid tillåtet. Det beror på vad meddelandetypen ska användas till och vilka regler som gäller inom just det området. Känsliga personuppgifter får bara behandlas om det finns ett tydligt lagstöd och ett korrekt ändamål enligt dataskyddsregler som GDPR.

Förvaltaren av meddelandetypen ska därför beskriva om den är tänkt att kunna bära känsliga personuppgifter. Förvaltaren ska också ange vilka skydd som krävs, till exempel hur informationen ska hanteras och skyddas i praktiken. SDK är byggt för att kunna skicka även känslig eller sekretessbelagd information säkert bland annat genom kryptering, men det förändrar inte kraven på laglighet och rätt hantering.

Som organisation måste ni ändå göra en egen bedömning innan ni använder en sådan meddelandetyp. Ni behöver säkerställa att ändamålet är rätt, att ni har stöd i lag och att rätt skyddsåtgärder finns på plats i er verksamhet. Ni måste också följa både GDPR och eventuell sektorslagstiftning som gäller för era uppgifter.

Nya meddelandetyper kan göra sekretess och GDPR lättare att hantera. De hjälper till att visa tydligt vilka uppgifter som faktiskt skickas. När man ser det klart blir det också enklare att förstå hur personuppgifter behandlas och om något behöver skyddas extra.

Riktlinjerna säger att juridiken ska vara med redan från början när en ny meddelandetyp tas fram. Det ska alltså inte komma som ett tillägg i efterhand. På så sätt kan man tidigt tänka igenom vilka uppgifter som får skickas, hur de får användas och vilka regler som gäller.

För organisationer som deltar innebär det här flera fördelar. Det blir lättare att se vilka fält som kan innehålla känsliga personuppgifter. Det blir också enklare att dokumentera hur uppgifterna behandlas och att följa upp att allt sker enligt GDPR. Sammanfattningsvis kan nya meddelandetyper göra arbetet mer tydligt, mer strukturerat och tryggare ur ett sekretess- och dataskyddsperspektiv.

Det är förvaltaren av meddelandetypen som ansvarar för att en ny meddelandetyp blir definierad och sedan sköts över tid. Förvaltaren kan vara en myndighet som har ansvar för ett visst område, en gemensam förvaltningsorganisation inom en sektor eller någon annan aktör som har mandat att ta fram och bestämma standarden.

Förvaltarens uppgift är att se till att meddelandetypen fungerar som den ska och är tydlig för alla som använder den. Det innebär att förvaltaren bestämmer vilket innehåll meddelandet ska ha, alltså vilka uppgifter som ingår, vad de betyder och vilka regler som gäller för dem. Förvaltaren ansvarar också för hur meddelandet är uppbyggt rent tekniskt så att det går att använda på ett enhetligt sätt.

Om meddelandetypen bara får användas av en viss grupp av avsändare är det också förvaltaren som avgör och beskriver det. Dessutom ska förvaltaren ta fram bra dokumentation med exempel och kontaktvägar så att det är lätt att förstå hur meddelandetypen ska användas. Slutligen ansvarar förvaltaren för att meddelandetypen kan förbättras i framtiden och att eventuella ändringar görs kontrollerat genom tydliga versioner.

Om du har frågor om en meddelandetyp ska du i första hand vända dig till den förvaltare som ansvarar för den. Riktlinjerna säger att varje meddelandetyp ska ha metadata där det står vem förvaltaren är och hur man kan nå dem. Det ska också finnas dokumentation till exempel på en webbsida eller i en PDF, där det tydligt framgår vilken kontaktväg som gäller.

Kontaktvägen kan se lite olika ut. Ibland finns en gemensam funktionsbrevlåda, ibland en namngiven kontaktperson och i vissa fall ett forum eller nätverk där frågor tas upp. Poängen är att du ska kunna hitta en tydlig väg in utan att behöva gissa.

Om du ändå är osäker på vem som är rätt förvaltare kan du ofta börja via Diggs SDK-sidor eller genom din sektorsmyndighet eller motsvarande aktör inom ditt område. Där brukar det finnas hänvisningar vidare.

Sveriges Dataportal Länk till annan webbplats. är också en samlad plats för dig som använder och hanterar data.

Digg har ett övergripande ansvar för att det finns en tydlig ram för hur nya meddelandetyper ska tas fram och användas. Det betyder att Digg tar fram regelverk, riktlinjer och den gemensamma arkitektur som gäller för hela SDK-federationen. Digg ser också till att infrastrukturen har stöd för meddelandetyper, till exempel att det finns fungerande sätt att adressera, beskriva och transportera meddelanden på ett enhetligt sätt.

En annan viktig del av Diggs ansvar är att samordna den övergripande utvecklingen. Digg hjälper till att hålla ihop helheten och ger stöd både till dem som förvaltar meddelandetyper och till de organisationer som använder dem.

Digg är normalt inte förvaltare av alla meddelandetyper. Diggs roll är att skapa och hålla ihop ramen som andra aktörer kan bygga sina meddelandetyper inom.

Innan ni driftsätter en ny meddelandetyp behöver ni testa att den fungerar som tänkt och följer riktlinjerna. Varje meddelandetyp ska ha ett schema som beskriver hur meddelandet ska se ut. I vissa fall finns också extra regler som kontrollerar sådant som inte kan fångas i schemat. Dessutom ska det finnas exempelmeddelanden som visar hur ett korrekt meddelande ser ut i praktiken.

Ett vanligt sätt att testa är att först kontrollera era egna meddelanden mot schemat, så att du ser att de är rätt uppbyggda och innehåller rätt typer av uppgifter. Sedan jämför du med de exempelmeddelanden som förvaltaren har tagit fram. Det hjälper dig att säkerställa att du har tolkat meddelandetypen rätt och att er lösning fungerar på samma sätt som andra förväntar sig. När det ser bra ut går du vidare och testar hela flödet i en testmiljö till exempel genom att skicka meddelanden via en testaccesspunkt. Då ser du att allt fungerar även i praktiken, inte bara på papper. Till sist är det klokt att stämma av med förvaltaren om det finns särskilda testfall eller rutiner som ni behöver följa så att ni inte missar något viktigt innan ni går i drift.

Ja, det finns exempel på meddelanden att utgå ifrån. Riktlinjerna säger att varje meddelandetypspaket ska innehålla minst ett men gärna flera exempel. Ofta är det bra om det finns både enkla exempel som visar grunderna och mer kompletta exempel som visar hur meddelandet kan se ut när man använder fler fält och funktioner.

Exempel på meddelanden är till för att göra det lättare att förstå hur meddelandetypen ska användas. Systemleverantörer kan använda dem när de bygger in stöd i sina lösningar så att allt blir rätt från början. Deltagarorganisationer kan använda dem för att se hur strukturen hänger ihop och vad som förväntas i ett korrekt meddelande. På så sätt blir det enklare för alla att arbeta på samma sätt och undvika missförstånd.

Förvaltaren av meddelandetypen har huvudansvaret för att schemafilerna är korrekta. Det innebär att förvaltaren ska se till att filerna går att kontrollera utan fel och att de följer de standarder som gäller. Förvaltaren ska också publicera schemafilerna på en tydlig och pålitlig plats, till exempel i ett gemensamt arkiv eller via en officiell webbadress, så att alla använder samma version.

Samtidigt kan du själv göra egna kontroller för att ni ska känna er trygga. Du kan testa schemafilerna i dina egna verktyg för att se att de fungerar som de ska. Du kan också lägga in dem i automatiska tester så att fel fångas tidigt om något skulle ändras eller tolkas fel. Om Digg eller förvaltaren har särskilda checklistor eller kvalitetskriterier är det bra att följa dem eftersom de är framtagna för att säkra att allt blir rätt och enhetligt. På så sätt får du både förvaltarens garanti och din egen bekräftelse på att schemafilerna håller måttet.

Ja, nya meddelandetyper kan ha särskilda krav på hur snabbt man ska svara eller när en tjänst ska vara tillgänglig. Riktlinjerna säger att sådana krav kan finnas till exempel om det behövs en viss tillgänglighet, en viss svarstid eller att en kvittens måste skickas inom en bestämd tid. Om en meddelandetyp har sådana regler ska det stå tydligt i dokumentationen för just den meddelandetypen.

Det kan handla om att mottagaren måste skicka en kvittens inom ett visst antal minuter eller timmar, eller att tjänsten bara ska vara öppen och nåbar under vissa tider på dygnet. Därför behöver du som deltar alltid läsa vad som gäller för den meddelandetyp du vill använda och jämföra med hur er egen drift ser ut. På så sätt kan du vara säker på att ni kan leva upp till kraven innan ni tar meddelandetypen i bruk.

Ja, nya meddelandetyper kan påverka både er kapacitet och er driftmiljö. Om en meddelandetyp till exempel innehåller stora bilagor kan ni behöva mer lagringsutrymme än tidigare. Om den dessutom används ofta kan mängden trafik i SDK öka vilket kan belasta era system mer. Vissa meddelandetyper kan också kräva att informationen behandlas snabbt och då kan ni behöva mer datorkraft, bättre övervakning och tydligare rutiner för att allt ska fungera stabilt.

Därför är det klokt att ta med den nya meddelandetypen i era kapacitets- och driftsplanering redan från början. Det är också bra att involvera drift eller IT tidigt i arbetet så att du hinner se över behov och risker innan meddelandetypen tas i bruk. På så sätt minskar du risken för överraskningar när ni väl går i drift.

Nya meddelandetyper bygger på SDK:s vanliga meddelandekvittenser. Det betyder att du får besked om ett meddelande har tagits emot som det ska, om det har blivit avvisat eller om något har gått fel på vägen. Den grunden är alltså densamma som du redan är vana vid.

Samtidigt kan vissa nya meddelandetyper ha egna regler som gör att fel ser lite annorlunda ut. Det kan till exempel finnas särskilda felkoder eller tydligare orsaker till varför ett meddelande inte godkänns som att ett obligatoriskt fält saknas. I några fall kan det också krävas att du agerar på ett visst sätt när kvittensen visar att något gått fel till exempel genom att skicka om meddelandet eller rätta uppgifter innan du försöker igen.

Därför är det bra att se över era interna rutiner för felhantering, incidenter och ärenden när du börjar använda en ny meddelandetyp. På så sätt säkerställer du att du kan tolka kvittenserna rätt och hantera problem snabbt och på ett enhetligt sätt.

Det kan kosta att använda en ny meddelandetyp men kostnaden ser olika ut beroende på vilken meddelandetyp det gäller och hur ni arbetar i dag. Riktlinjerna säger att det kan finnas kostnader både för att ta fram meddelandetyper, för att förvalta dem över tid och för att införa dem i verksamheten. I vissa fall bygger en meddelandetyp på en standard eller ett format som har egna villkor och då kan det också påverka kostnadsbilden.

För er som deltagarorganisation handlar kostnaderna oftast inte om själva meddelandetypen i sig utan om vad ni behöver göra för att kunna använda den. Det kan till exempel vara att du måste anpassa era egna system så att de kan skapa, ta emot och tolka den nya typen av meddelanden. Du kan också behöva lägga tid på förvaltning, alltså att hålla lösningen uppdaterad och fungerande och på utbildning så att rätt personer i organisationen förstår hur meddelandetypen ska användas. Sammanlagt är det alltså främst införandet och det löpande arbetet runt meddelandetypen som kan innebära kostnader.

Vilken licens som gäller för en ny meddelandetyp ska alltid stå tydligt i riktlinjerna och i dokumentationen för just den meddelandetypen. Där ska det framgå under vilken licens specifikationerna och modellerna publiceras och vad licensen betyder för dig som använder meddelandetypen eller vill bygga vidare på den.

Ofta används öppna licenser, så att många kan ta del av meddelandetypen och använda den på samma sätt. Men det är ändå viktigt att inte anta att alla meddelandetyper har samma villkor. Den exakta licensen kan skilja sig åt, och därför behöver du alltid titta i dokumentationen för den specifika meddelandetypen för att se vad som gäller i just det fallet.

Det beror på vilka regler som gäller för just den meddelandetypen. Två saker styr det här. För det första spelar licensen roll eftersom den säger vad du får göra med specifikationen. För det andra påverkar förvaltaren och federationsregelverket vad som är tillåtet inom SDK-federationen.

I praktiken kan du ofta göra egna interna anpassningar för att få meddelandetypen att fungera i era system och ert arbetssätt. Det kan handla om hur ni lagrar uppgifter eller hur ni använder dem i era interna processer. Men om du vill ändra själva meddelandetypen så att förändringen ska gälla även för andra till exempel genom att lägga till nya fält som alla ska följa, då räcker det inte att göra det på egen hand. Sådana ändringar behöver normalt gå via förvaltaren och följa de processer som finns i riktlinjerna. På så sätt säkerställs att meddelandetypen fortsätter vara gemensam, tydlig och kompatibel för alla som använder den.