@Jonas-Nordqvist Bra fråga! Standarden för den tekniska utformningen av kundhändelserna ägs av byggblocket Mina ärenden och förvaltas inom Ena. Den tekniska standarden för att tillgängliggöra kundhändelser bygger i sin tur på REST API-profilen som byggblocket API-hantering tagit fram. På sikt ska Mina ärendens standard närmare kopplas mot andra byggblock i takt med att de blir mer mogna - t.ex. auktorisation/identitet och hur man autentiserar och auktoriserar system och organisation.

Den specifika implementationen av ett producentärendeflöde och tillgängliggörandet av dessa, likt det Värmdö nu gör på samhällsbyggnadsomårdet, ägs av respektive producent (i detta fall Värmdö). Hur vi ska hantera och kunna återanvända det som tas fram av kommuner behöver växa fram i samarbete med de utvecklande kommunerna och SKR.

Inom Mina ärenden har vi sett behov av något vi kallar för kundhändelsetypskatalog där respektive producents producentärenden och tillhörande kundhändelsetyper finns publikt beskrivna (de ursprungliga tankarna bakom en sådan katalog finns beskrivet i byggblocksbeskrivningen kap. 2.2.2). Det är en del i att göra det enkelt för kommande kommuner att ta del av det arbete som gjorts, samtidigt som att det måste finnas frihet och flexibilitet för respektive kommun att själva ta fram de kundhändelsetyper utifrån de behov och förutsättningar som finns inom den kommunen.

@Kenneth-Zetterberg har du något du vill komplettera ovanstående svar med?

Mina ärenden har uppdaterat delar av lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som gjorts kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

2022-09-14

Tjänstebeskrivning

• Indata ska skickas i body till POST-anrop istället för GET. Skälet till ändringen är att möjliggöra kryptering av t.ex. personnummer som anses vara extra skyddsvärda personuppgifter.
• Två nya indataparametrar "kund.identifierare" och "kund.typ" ersätter tidigare "kund". Syftet är att möjliggöra för fler typer av identifierare än personnummer och organisationsnummer

Verksamhetsguide

• Nytt avsnitt i kapitel 1 med rubriken "Kundsituation" har tillkommit som närmare beskriver begreppet och kundsituationsperspektivet.
• Nytt avsnitt i kapitel 2 med rubriken "Mappning från kundärende till producentärenden".
• Ändrad utformning av avsnittet "Kundhändelser och hur du formulerar dem (mikrocopy)" i kapitel 3 i syfte att göra det mer lättläst.
• Nytt innehåll i kapitel 4 med exempel på hur kundhändelser kan användas i gränssnitt i tjänst hos en Konsument.
• Mindre språkliga justeringar

Begreppsmodell

• En begreppsmodell har publicerats i PDF-format. Ambitionen är att göra begreppsmodellen tillgänglig i ett mer lämpligt format framöver.

Enkel Kundhändelsetjänst

• Uppdaterad enligt senaste tjänstebeskrivning (sker inom kort)

@elias förstår din fundering och att man som privatperson eller företagare absolut inte ser sig som kund till t.ex. en myndighet. Eftersom jag blev intaggad så skriver jag lite kortfattat om hur vi ser på kundbegreppet på Skatteverket där jag själv jobbar.

Saxar in kort information från Skatteverket ang. kundbegreppet nedan:

När vi på Skatteverket diskuterar "kundens möte med Skatteverket så används genomgående begreppet ”kund”, oavsett om det är fråga om en individ, ett företag, en representant för ett företag eller en organisation.

Vi använder begreppet kund för att hjälpa oss att ha rätt fokus och tydligare visualisera förflyttningar som behöver göras i vårt agerande och vårt förhållningssätt för att nå intentionerna i Skatteverkets riktning och verksamhetsplan.

Kundbegreppet har sitt naturliga ursprung i det privata näringslivet och är inte alltid ett självklart begrepp på Skatteverket eller ens lämpligt att använda i alla sammanhang. Ofta är det naturligt att använda begreppet kund, men ibland kan det vara bättre att använda andra begrepp som företagare, skattebetalare, fastighetsägare eller medborgare."

--Uppdaterat med ID--

Mina ärenden har uppdaterat lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som görs kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Du hittar Mina ärendens lösningsdokumentation på Sveriges dataportal.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

ID	Vart	Beskrivning
2022-09-14-01	Tjänstebeskrivning	Indata ska skickas i body till POST-anrop istället för GET. Skälet till ändringen är att möjliggöra kryptering av t.ex. personnummer som anses vara extra skyddsvärda personuppgifter.
2022-09-14-02	Tjänstebeskrivning	Två nya indataparametrar kund.identifierare och kund.typ ersätter tidigare kund. Syftet är att möjliggöra för fler typer av identifierare än personnummer och organisationsnummer.
2022-09-14-03	Verksamhetsguide	Nytt avsnitt i kapitel 1 med rubriken "Kundsituation" har tillkommit som närmare beskriver begreppet och kundsituationsperspektivet.
2022-09-14-04	Verksamhetsguide	Nytt avsnitt i kapitel 2 med rubriken "Mappning från kundärende till producentärenden".
2022-09-14-05	Verksamhetsguide	Ändrad utformning av avsnittet "Kundhändelser och hur du formulerar dem (mikrocopy)" i kapitel 3 i syfte att göra det mer lättläst.
2022-09-14-06	Verksamhetsguide	Nytt innehåll i kapitel 4 med exempel på hur kundhändelser kan användas i gränssnitt i tjänst hos en Konsument.
2022-09-14-07	Verksamhetsguide	Mindre språkliga justeringar.
2022-09-14-08	Begreppsmodell	En begreppsmodell har publicerats i PDF-format. Ambitionen är att göra begreppsmodellen tillgänglig i ett mer lämpligt format framöver.
2022-09-14-09	Enkel kundhändelsetjänst	Uppdaterad enligt senaste tjänstebeskrivning (sker inom kort)

@johantjader sa i Uppdaterad dokumentation 20220914:

Mina ärenden har uppdaterat delar av lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som gjorts kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

2022-09-14

Tjänstebeskrivning

• Indata ska skickas i body till POST-anrop istället för GET. Skälet till ändringen är att möjliggöra kryptering av t.ex. personnummer som anses vara extra skyddsvärda personuppgifter.
• Två nya indataparametrar "kund.identifierare" och "kund.typ" ersätter tidigare "kund". Syftet är att möjliggöra för fler typer av identifierare än personnummer och organisationsnummer

Verksamhetsguide

• Nytt avsnitt i kapitel 1 med rubriken "Kundsituation" har tillkommit som närmare beskriver begreppet och kundsituationsperspektivet.
• Nytt avsnitt i kapitel 2 med rubriken "Mappning från kundärende till producentärenden".
• Ändrad utformning av avsnittet "Kundhändelser och hur du formulerar dem (mikrocopy)" i kapitel 3 i syfte att göra det mer lättläst.
• Nytt innehåll i kapitel 4 med exempel på hur kundhändelser kan användas i gränssnitt i tjänst hos en Konsument.
• Mindre språkliga justeringar

Begreppsmodell

• En begreppsmodell har publicerats i PDF-format. Ambitionen är att göra begreppsmodellen tillgänglig i ett mer lämpligt format framöver.

Enkel Kundhändelsetjänst

• Uppdaterad enligt senaste tjänstebeskrivning (sker inom kort)

@Fredrik-Forsberg

Vi håller med och förösker vara trogen REST så långt som möjligt men valde att införliva detta avsteg efter input av myndigheter som vi haft dialog med.

Dokumentationen på Skatteverkets utvecklarportal för Mina ärenden är detsamma här på dataportal.se då det är exakt samma. Tänker att jag passar på att skriva några rader om Skatteverkets olika "hattar" på området då det finns en risk för att hopblandning (även internt ).

Skatteverket är byggblocksansvarig för Mina ärenden, d.v.s. leder arbetet med att ta fram en standard för ärendeåterkoppling. Standarden ska utgå från de behov och förutsättningar som finns ute hos samtliga aktuella producenter och konsumenter så det inte blir "Skatteverkifierad" lösning.

Skatteverket är också s.k. producent och håller nu på att ta fram ett kundhändelse-API i enlighet med den nationella standarden som planeras att lanseras v.44. Skatteverket kommer publicera tjänstebeskrivning och information om API:et och hur man ansluter till det på Skatteverkets Utvecklarportal. Jag tänker att vi (Mina ärenden) ser till att slänga upp ett nytt ämne om detta även i denna forumdel så snart det är klart.

I byggblocket Mina ärenden ser vi att det finns ett värde att ta fram en struktur för hur de olika producenterna beskriver sina datamängder - i detta fall kundhändelser och tillhörande producentprocesser. Därför har vi bett producenten Skatteverket att inledningsvis beskriva dessa i något vi kallar för "kundhändelsetypskatalog". Nu inititalt är det endast en enkel excelfil men på sikt ska det bli en maskinläsbar teknisk komponent som beskriver alla producenters kundhändelser och producentprocesser. Vi publicerade denna på dataportal.se i slutet på förra veckan. Där finns vilka kundhändelsetyper som Skatteverket kommer göra tillgängliga via kundhändelse-API:et.

För den intresserade så har vi kortfattat beskrivit behovet av vissa centraliserade förmågor, bl.a. kundhändelsetypskatalogen, inom Mina ärenden i den byggblocksbeskrivning som togs fram under våren 2022. Avsnitt 2.2 i byggblocksbeskrivningen som finns på www.skatteverket.se/minaarenden

Er input är oerhört värdefull, vi ska försöka involvera dig och andra programvaruleverantörer i takt med att vi får fler myndigheter och kommuner på tråden

Mina ärenden har den 20 oktober 2022 uppdaterat lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som gjorts kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

ID	Vart	Beskrivning
2022-10-18-01	Tjänstebeskrivning	Lagt till möjlighet att fråga på ärende utöver kund efter önskemål från Bolagsverket.
2022-10-18-02	Tjänstebeskrivning	Ensat attributnamn kundhandelseRequest och kundhandelseResponse. Bytt bokstaven ä mot a i kundhändelse-attribut i svar.
2022-10-18-03	Tjänstebeskrivning	Attributet kundhandelsekategori ersatt med producentarendetKraverKundatgard och producentarendetKlart. Tidigare lösning med kundhandelsekategori har vållat en del osäkerhet hos producenter mot vilket värde man ska mappa en kundhändelsetyp mot. Eftersom det ursprungliga behovet är att det ska vara tydligt "vem som har bollen", eller snarare "behöver jag som kund agera" så bedöms det bli enklare och renare med dessa två booleans.
2022-10-18-04	Verksamhetsguide	Uppdaterat kap.2 "Att utforma en kundhändelse" och kap. 2 "Att skriva en kundhändelse" med anledning av att attributet kundhandelsekategori ersatts.
2022-10-18-05	Verksamhetsguide	Nytt avsnitt "Notifiering av kundhändelser" i kap. 2. Beskriver behovet av att avisera kundhändelser och kort om relationen kundhändelse - meddelande.
2022-10-26-06*	Tjänstebeskrivning	Lagt till information om vilken URL skall användas.

Eftersom ändringen innebär ett attrbut utgår (kundhandelsekategori) i den tekniska standarden så har vi valt att skapa en ny plats för tidigare versioner -> Mina ärenden - tidigare versioner.

Befintlig plats på dataportalen kommer istället alltid innehålla den aktuella versionen.

---

*Tillagd efter urspungligt inlägg postades

Mina ärenden har den 21 december 2022 uppdaterat lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som gjorts kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

ID	Vart	Beskrivning
2022-12-21-01	Verksamhetsguide	Språkliga justeringar och flyttat runt innehåll. Avsnittet om notifering har flyttats till kap. 5 "Kommunikationstaktik och kanalsamordning"
2022-12-21-02	Verksamhetsguide	Uppdaterat språkguide med anledning av ändring av lösning för "referenser och mönster för tvåvägskommunikation"
2022-12-21-03	Tjänstebeskrivning	Uppdatering med anledning av nytt angreppssätt för att tillgodose mönster för tvåvägskommunikation. Nytt informationsobjekt "referenser" har lagts till i Tjänstebeskrivning.
2022-12-21-04	Verksamhetsguide	Mönster för tvåvägskommunikation beskrivs kap. 2 avsnitt "Mönster för tvåvägskommunikation - referenser"
2022-12-21-05	Tjänstebeskrivning	Nytt attribut "version" i "kundhandelsResponse" som informerar vilken version av Mina ärenens standard som producenten implementerat
2022-12-21-06	Enkel kundhändelsetjänst	Svaren i enkel kundhändelsetjänst har uppdaterats i enlighet med senaste versionen av Tjänstebeskrivning
2022-12-21-07	Kom igång med Mina ärenden	En kom igång-guide som tagits fram utifrån de frågor och diskussioner som väckts i samband med att Värmdö kommun börjat sätta sig in i byggblocket Mina ärenden. Kom igång-guiden avser att ge stöd för hur en producent steg-för-steg kan närma sig området med att lämna ärendeåterkoppling på ett standardiserat sätt
2022-12-21-08	Prototyp Kundhändelsetypskatalog	En första enkel prototyp för att bättre kunna kommunicera hur en kundhändelsetypskatalog kan utformas för att få input i den fortsatta utvecklinen. Behandlas i en separat tråd här på communityt.
2022-12-21-09	Versionshantering av Mina ärendens standard och Producenters API:er	Dokument som beskriver Mina ärendens versionshantering och hur byggblocket förhåller sig till producenternas versionshantering.

Det kan dröja till imorgon innan de nya versionerna och nya resurser "skördats" till dataportalen, vill man se dessa nu så går de hitta på Skatteverkets utvecklarportal.

I och med att vi genomför en förändring av Tjänstebeskrivningen som innebär att ett nytt informationsobjekt "referenser" tillkommer dit bl.a. attributet producentReferens och "konsumentReferens" läggs så blir detta en ny version av standarden för kundhändelser - version 3.

Är man intresserad av att ta del av tidigare versioner finns dessa samlade på dataportal Mina ärenden - Tidigare versioner

På dataportal.se finns senast uppdaterade dokumentation.

Övrig info:

• Skatteverket har tagit fram ett första kundhändelse-API som möjliggör för en användare att via en s.k. konsumenttjänst hämta kundhändelser från Skatteverket.  API:et lanserades v.50 och bygger på Mina ärendens första standard (v.1). Läs mer om API:et på Skatteverkets utvecklarportal.
• Digg har publicerat byggblocksbeskrivningar för flera byggblock, inkl. Mina ärenden. De finns att läsa på Diggs webbplats.

---

Uppdaterade tråden m.a.a. vi lade till nytt dokument "Versionshantering av Mina ärendens standard och Producenters API:er" samt inte beskrivit nytt attribut "version" i Tjänstebeskrivning.

@Magnus-Sälgö Ingen fara. Vi uppskattar all input så delta gärna i fortsatta diskussioner så får vi på sikt förhoppningsvis fram en standard för ärendeåterkoppling från det offentliga som möter upp de behov och förutsättningar som finns därute

@Magnus-Sälgö Bra synpunkter. Lägger till ID för varje förändring så det går att hänvisa till så får vi utvärdera längs vägen om det här är ett bra sätt eller om det ska justeras mer.

Ang. GET vs POST
Intressant synpunkt. Skulle du kunna utveckla vad du ser för användningsområde mellan Wikidata och kundhändelser (Mina ärenden)?

Bra input, här kommer ett tråkigt svar men vi är begränsade kring val av verktyg i dagsläget till de . Självklart ska dock se hur vi kan göra vårt arbete ännu mer transperent och inbjudande till samskapande. Tänker att vi kan lägga upp den road map som vi jobbar efter här på Communtyt så snart den är förankrad med samverkande myndigheter.

Har någon av er haft möjlighet att ta del av den dokumentation vi lagt upp och har ni några spontanta synpunkter på innehållet?

@Stefan-Wallin bra och relevant fråga!
När vi fick behov av att publicera och tillgängliggöra dokumentation och specifikationer så undersökte vi vilka möjligheter som stod till buds. På Skatteverket används idag ingen av de lösningar du nämner utan istället är det framförallt Utvecklarportalen som används och som sen skördas till Dataportalen.

Vi ville inte skapa konton i eget (privat) namn på t.ex. Github av flera skäl, dels vill vi inte att det ska finnas någon tveksamhet vem som är avsändare (Skatteverket som byggblocksansvarigt), dels kommer det komma fler byggblock i Ena som har ungefär samma behov som BB Mina ärenden där man kommer vilja tillgängliggöra tekniska förmågor, tjänster, standardiserade modeller, ramverk och mönster enkelt, tillgängligt och med en fungerande versionshantering.

Vi tror att det bästa är att vi inom Ena tar ett större grepp kring frågan så att de lösningar som tas fram av vårt och andras byggblock blir enkelt och sammanhängande att både hitta och använda för tänkta användare.

Mot bakgrund av ovanstående valde vi att köra med det som fanns tillhands idag med Utvecklarportalen och medvetna om en del av de brister som ett sådant val medför. Viktigast för oss har varit att tidigt få vår dokumentation publik så det finns möjlighet för andra att ta del och tycka till. Med sagt så kvarstår dock ambitionerna att hitta bättre sätt framöver - helst på ett inom Ena enhetligt sätt

Trevlig fortsättning!

Mina ärenden har den 21 december 2022 uppdaterat lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som gjorts kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

ID	Vart	Beskrivning
2022-12-21-01	Verksamhetsguide	Språkliga justeringar och flyttat runt innehåll. Avsnittet om notifering har flyttats till kap. 5 "Kommunikationstaktik och kanalsamordning"
2022-12-21-02	Verksamhetsguide	Uppdaterat språkguide med anledning av ändring av lösning för "referenser och mönster för tvåvägskommunikation"
2022-12-21-03	Tjänstebeskrivning	Uppdatering med anledning av nytt angreppssätt för att tillgodose mönster för tvåvägskommunikation. Nytt informationsobjekt "referenser" har lagts till i Tjänstebeskrivning.
2022-12-21-04	Verksamhetsguide	Mönster för tvåvägskommunikation beskrivs kap. 2 avsnitt "Mönster för tvåvägskommunikation - referenser"
2022-12-21-05	Tjänstebeskrivning	Nytt attribut "version" i "kundhandelsResponse" som informerar vilken version av Mina ärenens standard som producenten implementerat
2022-12-21-06	Enkel kundhändelsetjänst	Svaren i enkel kundhändelsetjänst har uppdaterats i enlighet med senaste versionen av Tjänstebeskrivning
2022-12-21-07	Kom igång med Mina ärenden	En kom igång-guide som tagits fram utifrån de frågor och diskussioner som väckts i samband med att Värmdö kommun börjat sätta sig in i byggblocket Mina ärenden. Kom igång-guiden avser att ge stöd för hur en producent steg-för-steg kan närma sig området med att lämna ärendeåterkoppling på ett standardiserat sätt
2022-12-21-08	Prototyp Kundhändelsetypskatalog	En första enkel prototyp för att bättre kunna kommunicera hur en kundhändelsetypskatalog kan utformas för att få input i den fortsatta utvecklinen. Behandlas i en separat tråd här på communityt.
2022-12-21-09	Versionshantering av Mina ärendens standard och Producenters API:er	Dokument som beskriver Mina ärendens versionshantering och hur byggblocket förhåller sig till producenternas versionshantering.

Det kan dröja till imorgon innan de nya versionerna och nya resurser "skördats" till dataportalen, vill man se dessa nu så går de hitta på Skatteverkets utvecklarportal.

I och med att vi genomför en förändring av Tjänstebeskrivningen som innebär att ett nytt informationsobjekt "referenser" tillkommer dit bl.a. attributet producentReferens och "konsumentReferens" läggs så blir detta en ny version av standarden för kundhändelser - version 3.

Är man intresserad av att ta del av tidigare versioner finns dessa samlade på dataportal Mina ärenden - Tidigare versioner

På dataportal.se finns senast uppdaterade dokumentation.

Övrig info:

• Skatteverket har tagit fram ett första kundhändelse-API som möjliggör för en användare att via en s.k. konsumenttjänst hämta kundhändelser från Skatteverket.  API:et lanserades v.50 och bygger på Mina ärendens första standard (v.1). Läs mer om API:et på Skatteverkets utvecklarportal.
• Digg har publicerat byggblocksbeskrivningar för flera byggblock, inkl. Mina ärenden. De finns att läsa på Diggs webbplats.

---

Uppdaterade tråden m.a.a. vi lade till nytt dokument "Versionshantering av Mina ärendens standard och Producenters API:er" samt inte beskrivit nytt attribut "version" i Tjänstebeskrivning.

@elias förstår din fundering och att man som privatperson eller företagare absolut inte ser sig som kund till t.ex. en myndighet. Eftersom jag blev intaggad så skriver jag lite kortfattat om hur vi ser på kundbegreppet på Skatteverket där jag själv jobbar.

Saxar in kort information från Skatteverket ang. kundbegreppet nedan:

När vi på Skatteverket diskuterar "kundens möte med Skatteverket så används genomgående begreppet ”kund”, oavsett om det är fråga om en individ, ett företag, en representant för ett företag eller en organisation.

Vi använder begreppet kund för att hjälpa oss att ha rätt fokus och tydligare visualisera förflyttningar som behöver göras i vårt agerande och vårt förhållningssätt för att nå intentionerna i Skatteverkets riktning och verksamhetsplan.

Kundbegreppet har sitt naturliga ursprung i det privata näringslivet och är inte alltid ett självklart begrepp på Skatteverket eller ens lämpligt att använda i alla sammanhang. Ofta är det naturligt att använda begreppet kund, men ibland kan det vara bättre att använda andra begrepp som företagare, skattebetalare, fastighetsägare eller medborgare."

Mina ärenden har lagt ut en första enkel prototyp på en s.k. kundhändelsetypskatalog på dataportalen. Kundhändelsetypskatalogen tror vi är är förutsättningsskapande för att t.ex.

• ärendeåterkoppling producenter emellan ska bli mer likartad då producenter får insyn i hur andra utformat sin ärendeåterkoppling, detta bör på sikt leda till att upplevelsen av s.k. "mydighetska" minskar,
• det ska bli överskådligt för en konsument vilken ärendeåterkoppling som finns tillgänglig och ha förutsättningar för att kunna ta beslut huruvida relevant information finns för att realisera vissa tjänster
• få förståelse för vilken typ av ärendeåterkoppling som finns, men också saknas, för att tillgodose behov av ärendeåterkoppling inom t.ex. en viss livssituation
• för en konsument att förstå hur kundhändelsetyper förhåller sig till varandra i ett prpducentärende och hur ärendeåterkopplingen är utformad

Realiserandet av katalogen som en teknisk komponent är inget som ligger i planerna i närtid. Men vi har valt att ta fram en enkel prototyp för att kunna ha något mer konkret att diskutera utifrån för att bättre förstå behov och krav på en ev. framtida lösning.

Prototypen finns tillgänglig via Mina ärenden på dataportal eller via denna länk.

Vi tar gärna emot synpunkter, tankar och ideér i tråden nedan.

För den som vill veta mer så beskrivs tankarna bakom kundhändelsetypskatalogen närmare nedan.

---

Varför en kundhändelsetypskatalog?

En konsument-tjänst kommer med hjälp av standardiserade tjänster inom Mina ärenden kunna hämta kundhändelser ifrån en eller flera producenter. Det finns vissa urvalsmöjligheter i dessa hämtningar, men i slutändan kommer konsument-tjänsten ändå att ha en lista med kundhändelser av olika typer.

Om konsument-tjänsten erbjuder en mer sofistikerad vy över kundhändelserna än bara en kronologisk lista så behöver kundhändelserna grupperas och sorteras in i de producentärenden som de tillhör. Dessutom kan det vara så att vissa kundhändelser 'saknas', dvs konsument-tjänsten hade förväntat sig att få dem, men de dök inte upp i listan av kundhändelser som hämtades. Hur vet konsument-tjänsten att vissa kundhändelser 'saknas'?

Låt oss ta ett enkelt exempel, återigen med Pias Tacotruck och vår fiktiva företagstjänst.

Företagstjänsten har tidigare kommit fram till att Pia behöver genomgå fyra producentärenden (exakt hur det har gått till och hur den informationen är lagrad har inte med kundhändelsetypskatalogen att göra utan beskrivs på andra ställen):

• Anmäla verklig huvudman hos Bolagsverket
• Registrera sig som arbetsgivare hos Skatteverket
• Registrera varumärke hos Patent och registreringsverket
• Anmäla fettavskiljare hos Stockholms stad.

Företagstjänsten har nu hämtat följande lista med kundhändelser ifrån några producenter (och sedan lagt ihop svaren ifrån respektive konsument till en och samma lista). Notera att alla dessa värden är påhittade för exemplets skull. I verkligheten kan kundhändelser av dessa typer ha andra id:n, andra kundhändelsetyper och andra rubriker.

Id	Tidpunkt	Producent	Kundhändelsetyp	Rubrik
1	2022-06-20 15:12:32	Skatteverket	SKV.ARBETSGIVARE.ANSOKAN	Ansökan mottagen för arbetsgivarregistrering
2	2022-06-21 09:32:12	Patent och registreringsverket	PRV.VARUMARKE.ANSOKAN	Ansökan mottagen för varumärkesregistering
3	2022-06-21 14:12:49	Stockholms stad	KOMMUN.FETTAVSKILJARE.ANSOKAN	Ansökan mottagen för fettavskiljare
4	2022-07-01 09:03:05	Skatteverket	SKV.ARBETSGIVARE.HANDLAGGNING	Handläggning påbörjad för arbetsgivarreigstrering
5	2022-07-04 11:32:54	Stockholms stad	KOMMUN.FETTAVSKILJARE.HANDLAGGNING	Handläggning påbörjad för fettavskiljare
6	2022-07-04 13:21:15	Skatteverket	SKV.ARBETSGIVARE.BESLUT	Beslut fattat för arbetsgivarregistrering
7	2022-07-04 14:12:35	Patent och registreringsverket	PRV.VARUMARKE.KOMPLETTERING	Komplettera din ansökan för varumärke

Om detta var all information som företagstjänsten kände till så hade den iofs kunnat placera in dessa kundhändelser i respektive producentärende, men den hade inte kunnat förstå om producentärendena är klara eller om det är kundhändelser som borde ha hänt men ännu inte gjort det.

För att få en fullödig bild av hur det går för Pia med sina producentärenden behöver företagstjänsten också förstå hur respektive producentärende borde gå till och vilka kundhändelser som borde komma. Alltså behöver den förstå för respektive typ av producentärende, vilka typer av kundhändelser som kommer då och i vilken ordning. Dessutom behöver den förstå vilken kundhändelsetyp som indikerar att respektive producentärende är klart (åtminstone såsom producenten ser det).

Vilken information finns i katalogen?

Kundhändelsetypskatalogen innehåller information om följande entiteter:

• Kundhändelsetyper
• Producentärendetyper.

För varje producentärendetyp (Arbetsgivarregistrering, varumärkesregistrering, fettavskiljare, verklig huvudman i exemplet ovan) innehåller kundhändelsetypskatalogen information om:

• Namn på producentärendetypen
• Producentärendetypens identifierare (den text som står i mitten-fältet av kundhändelsetypsnamnet i tabellen ovan, alltså ARBETSGIVARE, VARUMARKE etc)
• Flödet av kundhändelsetyper som skapas när en kund genomgår en instans av producentärendet. I flödesbeskrivningen ingår:
  • Startpunkt
  • Vilka kundhändelsetyper en kund kan passera och i vilken ordning
  • Vilken/vilka kundhändelsetyp som indikerar att producenten anser att flödet är klart och producentärendet därmed är avslutat
    (kundhändelser av dessa kundhändelsetyper har värdet true på attributet producentarendetKlart)
  • Vilka kundhändelsetyper som indikerar att kunden behöver göra någonting för att flödet skall fortskrida
    (kundhändelser av dessa kundhändelsetyper har värdet true på attributet producentarendetKraverKundatgard)

Flödet kan illustreras i ett flödesschema som skulle kunna se ut så här:

Exemplet ovan visar hur producentärendetypen för momsdeklaration skulle kunna se ut hos Skatteverket. Observera att det är endast ett exempel. Den riktiga processen kan absolut se annorlunda ut med andra kundhändelsetyper och ett annat flöde.

Producentärenden av denna typ börjar i pricken längst upp i diagrammet. Varje ruta beskriver kundhändelser som skickas när producentärendet fortlöper. Pilarna representerar möjliga ordningar mellan kundhändelsetyperna. Pricken med ram längst ned visar att när sista kundhändelsetypen kommit (i detta exempel Moms betalad) så anser producenten (i exemplet Skatteverket) att producentärendet är avslutat. Kunden kan mycket väl ha en annan uppfattning och vilja fortsätta handläggningen via ett överklagande eller liknande. Överklagandet kan tänkas ingå i samma producentärende och i så fall bör flödet illustrera det. I detta exempel hanteras istället ett eventuellt överklagande i en annan producentärendetyp.

För varje kundhändelsetyp som finns i kundhändelsetypskatalogen SKALL följande information finnas lagrad:

• Namn
• Identifierare (kundhändelsetyp med de 3 fälten för Aktör, Producentärendetyp och Steg)
• Relationer till övriga kundhändelsetyper via flödesdiagrammen för respektive producentärendetyp.
• Vilken behörighet som krävs för att få ta del av kundhändelser av denna typ
• URL/Pekare till producentens API där man kan hämta kundhändelser av denna typ

Dessutom KAN följande information finnas lagrad

• Rubrik
• Beskrivning
• URL/Pekare till producentens dokumentation över kundhändelser av denna typ

Skapa förståelse för information och flöden i kundhändeltypskatalogen

Med hjälp av informationen som finns i kundhändelsetypskatalogen kan en konsumenttjänst skapa förståelse för listan av kundhändelser som den har fått ifrån producenterna. Tabellen ovan med kundhändelser kan placeras in i respektive producentärende och konsumenttjänsten kan också förstå vilka kundhändelser som ännu inte kommit för respektive producentärende. På så sätt kan konsumenttjänsten avgöra status i respektive producentärende, se vilka som är färdiga och vilka som ännu ej påbörjats.

Med informationen om kundhändelser som faktiskt inträffat (instanserna i tabellen ovan) och vilka som borde komma i respektive producentärende (kundhändelsetyper i respektive producentärendetyp i från kundhändelsetypskatalogen) kan en konsumenttjänst skapa användargränssnitt som liknar vårt exempel i företagstjänsten:

I exemplet ser vi 4 instanser av producentärenden som kunden (Pia) behöver genomgå. Detta är de 4 producentärenden som beskrevs längst upp i detta dokument:

• Anmäl verklig huvudman (BV)
  Eftersom listan av kundhändelser som hämtats inte innehåller någon kundhändelse ifrån denna producentärendetyp vet konsumenttjänsten att detta producentärende ännu ej är påbörjat.
• Registrera dig som arbetsgivare (SKV)
  Ifrån kundhändelsetypskatalogen förstår konsumenttjänsten att denna producentärendetyp har tre steg med tre kundhändelser. Alla dessa finns det instanser ifrån i listan av kundhändelser och därmed kan alla visas som genomförda
• Registrera varumärke (PRV)
  Ifrån kundhändelsetypskatalogen kan konsumenttjänsten förstå att det finns ett alternativflöde där komplettering krävs (liknande moms-exemplet ovan). Det finns en kundhändelse av rätt typ för komplettering och denna har en kundhändelsekategori som indikerar att bollen ligger hos kunden. Konsumenttjänsten kan därför välja att visa alternativflödet och dessutom med en ikon indikera att bollen ligger hos kunden.
• Anmäl fettavskiljare (Sthlm stad)
  I kundhändelsetypskatalogen ser konsumenttjänsten att det finns tre kundhändelser som skall komma för att producentärendet skall anses vara klart. Dock finns bara två av dessa representerade i listan av kundhändelser som faktiskt kommit och därför kan konsumenttjänsten visa att de två första är genomförda, men inte den sista

Flera producenter med samma typer (kommuner eller regioner)

Kundhändelser som kommer ifrån myndigheter är (i det här sammanhanget) enkla eftersom myndigheten har 'monopol' på sitt verksamhetsområde och därför finns det endast en producent (myndigheten) som producerar kundhändelser i de producentärendetyper som myndigheten ansvarar för.

Men i fallet kommuner och regioner blir det lite mer komplicerat. Här finns flera producenter som har ansvar för samma verksamhetsområde. Det är till exempel flera kommuner som hanterar samhällsbyggnadsprocessen och därför skapar kundhändelser för till exempel hantering av bygglov. Dessutom finns ett självstyre som gör att kommunerna eller regionerna har rätt att organisera sin verksamhet såsom de själva finner bäst. Förutsättningarna för att bygga IT-stöd varierar också kraftigt mellan olika kommuner och regioner. Detta kan leda till att samma producentärendetyp (t ex hantera bygglov) har olika grad av digitalisering hos olika producenter.

Det är därför inte sannolikt att dessa producentärendetyper kommer att han en och samma bild över vilka kundhändelser som uppstår i dem hos olika producenter (samma producentärendetyp hos olika kommuner eller olika regioner). Kundhändelsetypskatalogen behöver alltså kunna hantera denna situation.

Vi tror dock att det finns ett värde för kommuner och regioner att samordna sig så att åtminstone vissa delar av deras producentärendetyper har samma kundhändelser. Vissa delar kommer att sammanfalla, medans vissa kommer att se olika ut. Arbetet att standardisera och samordna kommer att leda till en harmonisering mellan kommuner eller mellan regioner i hur definitionerna av kundhändelser ser ut, även om det inte kommer att vara en 100-procentig överensstämmelse.

Bilden ovan illustrerar situationen för en specifik producentärendetyp. Vi tänker oss ett hypotetiskt exempel där det finns två producenter (t ex två kommuner) som hanterar samma prducentärendetyp. Flödesschemat i mitten av bilden och till höger i bilden visar de två kommunernas definition. Vi kan här se att båda kommunerna har samma kundhändelsetyper för typ 1 och 3, medan 2, 4 och 5 skiljer sig åt.

Kundhändelsetypskatalogen behöver hålla reda på denna information och förstå hur producentärendetypen är implementerad hos de två producenterna. Kundhändelsetypskatalogen kommer att innehålla en sammanlagd bild (den vänstra i bilden) ur vilken den kan göra urval eller utsnitt för respektive producent.

Implementation

Kundhändelsetypkatalogen kommer att implementeras på central nivå, men informationen i den kommer att ägas av respektive producent.

Bilden ovan visar en skiss över vilka funktioner/komponenter som behövs i en kundhändelsetypskatalog. Vi skall gå igenom dem var för sig.

API
Den centrala delen av kundhändelsetypskatalogen är ett API som kan svara på frågor om informationen som är lagrad i kundhändelsetypskatalogen. API:et behöver innehålla endpoints för (åtminstone) följande frågor

• Lista vilka producentärendetyper som en specifik producent stödjer
• Beskriva flödet av kundhändelsetyper i en specifik producentärendetyp, både hur den ser ut generellt (över flera producenter) men även specifikt för en producent
• Beskriva detaljer av en eller flera specifika kundhändelsetyper

API:et kommer att vara ett REST-baserat API som levererar information i JSON-format. Informationen i kundhändelsetypskatalogen är på typnivå och inte instansnivå, vilket borde betyda att informationen är öppen. Därför behövs inte alltför hårda säkerhetskontroller för att komma åt informationen. Exakta detaljer får vi återkomma till.

Lagring
Informationen i kundhändelsetypskatalogen lagras i systemet, förmodligen i en databas av något slag. Viss information (se nedan i diskussionen om synkning med producenter) kommer också att finnas hos producenterna själva.

GUI för att uppdatera data
När producenter ansluter nya producentärendetyper eller när de ändrar i befintliga kommer informationen i kundhändelsetypskatalogen behöva ändras. I sin enklaste form kan detta göras via ett GUI där representanter ifrån producenterna kan editera informationen som finns lagrad i kundhändelsetypskatalogen. Det är dock viktigt att man i detta fall kommer ihåg att ändra även här (utöver att ändra i sin lokala verksamhet) och detta riskerar att glömmas bort.

Det finns dessutom ett antal andra liknande initiativ där producenter behöver hålla information om sina processer uppdaterade så det vore önskvärt med någon sorts samordning så att producenterna inte behöver hålla flera informationsmängder uppdaterade. Ett sådant exempel som identifierats är uppgiftskrav.se. Det finns mycket att vinna på att samordna uppdateringar av uppgiftskrav.se och kundhändelsetypskatalogen.

Åtkomst till detta GUI kräver en specifik behörighet per producent. Vem som helst skall inte få ändra på informationen och man skall inte heller få ändra informationen för någon annan producent än den man representerar.

GUI för att titta på data
Informationen som finns lagrad i kundhändelsetypskatalogen är inte bara intressant för system att ta del av. Även människor är intresserade av att förstå hur olika producenter har definierat sin verksamhet och vilka kundhändelser som uppstår vid vilka tillfällen. Därför behövs ett GUI som exponerar denna information.

Åtkomst till detta GUI bör vara relativt öppen. Informationen är inte känslig eftersom den endast är på typnivå.

Synkning med producenter
Vissa producenter kommer att vilja ha en egen lokal variant på en kundhändelsetypskatalog, dvs ett tekniskt system som håller reda på metadata om sina kundhändelsetyper och producentärendetyper. De behöver detta för sina egna behov. Detta gäller till exempel Skatteverket och Värmdö kommun. I dessa fall behöver inte informationen i den centrala kundhändelsetypskatalogen uppdateras manuellt utan istället kan man bygga en synkningslogik som hämtar data ifrån de lokala katalogerna via något API hos dem och sedan synkar den informationen med datat som finns lagrad centralt. En sådan synkning kan sedan köras regelbundet, t ex varje natt.

Man skulle kunna tänka sig en lösning där kundhändelsetypskatalogen inte lagrar den lokala information utan hämtar den vid behov ifrån aktuella producenter. Bedömningen är dock att detta blir komplicerat då man skulle behöva hålla reda på vilken del av informationen som finns lokalt i kundhändelsetypskatalogen och vilken som finns ute hos någon producent och i så fall vilken producent. Det blir enklare att se en helhet av informationen om allting finns på samma ställe, i kundhändelsetypskatalogen. Nackdelen med att göra så här är att vi behöver en mer komplex synkningslogik, men komplexiteten i detta fall är samlad endast hos synkningslogiken och sprider sig inte över hela kundhändelsetypskatalogen.

@Jonas-Nordqvist Det är som du skriver syftet med Mina ärenden. Sen hur vi kommer dit är nog inte givet då det finns lite av en hönan eller ägget-aspekt i det hela. Om det inte finns några producenter som tillgängliggör kundhändelser så finns litet incitament för konsumenter att bygga tjänster som mer utgår från att stödja en användare i en livsshände/kundsituation samtidigt som att värdet att för en producent kan te sig mindre när potentialen inte lika tydligt framgår i brist på konsumenttjänster som visar vägen.

Men jag känner igen detta från Mina meddelanden/digital post som hade lite samma utmaningar till en början med varför man skulle ha en digital brevlåda när man ändå inte får någon post samtidigt som avsändare såg liten nytta att hämta när det var fanns få mottagare av digital post.

Jag tror också en framgångsfaktor är att det blir lätt(are) att komma igång för en producent och här får vi vara lyhörda kring vilka tröskelsänkande åtgärder som går att genomföra. Även här finns nog en del lärdomar att hämta från t.ex. Mina meddelanden och hur bl.a. existerande printleverantörer gjorde det enkelt för kommuner och myndigheter att börja skicka digital post. Även SKR gjorde ett fint jobb i att ta ett grepp och sänka tröskeln för komma igång med digital post genom att ta fram bl.a. kravunderlag och vägledning för kommunerna. Här är värt att undersöka vilka motsvarande grepp som går att ta för Mina ärenden.

Passar på att säga att vi uppskattar engagemanget. Jag ska ge mig på att återkomma på ditt mail under morgondagen, tror att det kommer bli tydligare längs vägen och viktigt att håller igång dialogen samt får igång fler att engagera sig i Mina ärenden

@Jonas-Nordqvist Läser återigen det jag tidigare svarade och inser att det kanske låter som vi att landat den här frågan helt och hållet vilket vi inte har. Det är respektive producent som ansvarar för identifiera och definiera sina producentärenden och kundhändelsetyper. Kundhändelsetypskatalogen är ett sätt att aggregera och göra informationen om dessa strukturerade och publika när kundhändelserna finns tillgängliggjorda av en producent (d.v.s. när producenten har ett kundhändelse-API på plats)

Sen kanske (?) det är önskvärt om det finns en likartad utformning av den återkoppling man ger i olika producentärenden mellan producenter som hanterar samma typ av producentärenden - d.v.s. typiskt sett hos kommuner eftersom detta inte är aktuellt hos de producenter som är "ensamma om sitt uppdrag, t.ex. myndigheter. Om det är önskvärt att det finns en likartad utformning (likartad, INTE identiskt lika - vi tycker oss förstått att det måste finnas ett ganska stort utrymme för flexibilitet i hur man definierar sina producentärenden och tillhörande ärendeåterkoppling mellan kommunerna) hur delar en kommun med sig av det man gör så att andra kommuner kan ta tillvara av det arbete som görs och kommer göras på området?

Här kan man tänka sig massa olika lösningar där kundhändelsetypskatalogen inte är (hela) svaret på hur man drar nytta av det arbete som görs hos en kommun. Särskilt inte till en början då en kundhändelsetypskatalog inte kommer innehålla särskilt mycket information eftersom det finns inga eller få producenter hos kommunerna.

Det finns därför ett behov av att dela med sig av erfarenheter och definitioner i utvecklingsfasen, t.ex. genom forum/referensbibliotek eller liknande. Behovet av att dela med sig och samordna över kommungränserna är nog också större än just för definitioner av producentärenden och kundhändelsetyper då många andra frågor också aktualiseras när man närmar sig området. T.ex. hur skapar man förmågan att överhuvudtaget skapa kundhändelser? Hur gör man dessa tillgängliga och hur visar man på bästa sätt ärendeåterkoppling på mina sidor? Här kan man nog dra nytta av att hjälpa varandra då kommunerna till viss del sitter på liknande lösningar och har liknande förutsättningar.

Jag ser inte att det är Mina ärenden som löser alla kommunens behov av hur man ska samordna sig eller i alla avseenden förhålla sig till en nationell standard för ärendeåterkoppling, här finns ett arbete att göra och ett ansvar att ta som är mer kommunnära. Men i piloten med Värmdö så börjar vi med att de delar med sig av sitt arbete och sina erfarenheter här på communityt för att komma igång. Här ser vi gärna att man kommer med konstruktiva förslag kring hur det skulle gå att göra bättre.
Vi tror också mycket på att lösa problem i takt med att de uppstår och jag tror vi kommer förstå mer i takt med att fler kommuner börjar närma sig Mina ärenden.

Hej @Jonas-Nordqvist

De kundhändelsetyper som en kommun identifierar och definierar kommer inom Mina ärenden komma till uttryck i en kundhändelsetypskatalog som är publik för alla att ta del av. Sen är det fritt fram för en kommun att följa redan existerande kundhändelsetyper eller om man ser behov av att komplettera/skala bort vissa kundhändelsetyper.

Hej @jonass

Bra fråga, delar upp svaret i två delar:

URL:er för kundhändelse-API:
Det finns absolut ett värde att ensa URL:en för de kundhändelse-API:er som tas fram. Dock blir det svårt att standardisera annat än sista delen av URL:em eftersom respektive producenter redan har etablerade lösningar för hur deras URL:er ska se ut. Vi tar dock med oss detta och lägger till i Mina ärendens tjänstebeskrivning att sista delen av URL:en ska heta "/kundhandelser". Vi slänger upp en ny version pronto som borde synas på dataportal inom kort.

Med "sista delen av URL:en" menar vi:
Skv.se/…/…./…./kundhandelser

Mönster för tvåvägskommunikation
Du lyfter även behovet för en användare att kunna agera på informationen den får till sig i en kundhändelse. Vi har för det behovet valt att prata om behovet av "mönster för tvåvägskommunikation". Vi tror att det kommer finnas behov av olika lösningar beroende på vad man som producent har att erbjuda kunden för lösningar samt i vilket sammanhang användaren tar del av en kundhändelse.

Exempel:
Scenario 1 - en användare (privatperson) tar del av en kundhändelse "du behöver komplettera ditt bygglovsärende" på Mina sidor hos en kommun. I denna kontext kanske behovet är att kunna hänvisa användaren till en e-tjänst där användaren kan komplettera med efterfrågat underlag.
Scenario 2 - en användare (företagare) tar del av en kundhändelse "du ska lämna in momsdeklaration senast 12 september" i användarens affärssystem. Skatteverket som producerat kundhändelsen skulle då kunna erbjuda möjligheten att lämna momsdeklaration direkt från affärssystemet via ett API istället för att hänvisa till t.ex. en e-tjänst.

D.v.s. lösningarna för att möta behovet kan variera beroende på situation och kontext varför det blir mer naturligt att prata om mönster för tvåvägskommunikation.

Vi har på inget sätt en färdig lösning utan har för avsikt att börja titta närmare på det här, helst tillsammans med de som först går ut och börjar ta utforska området (deltagare i Verksamt, Värmdö och potentiella konsumenter att SKV:s KH-API). Området adresseras kort i Verksamhetsguiden i sista avsnittet i kap 3 - "Länkar och mönster för tvåvägskommunikation"

@Jonas-Nordqvist Bra fråga! Standarden för den tekniska utformningen av kundhändelserna ägs av byggblocket Mina ärenden och förvaltas inom Ena. Den tekniska standarden för att tillgängliggöra kundhändelser bygger i sin tur på REST API-profilen som byggblocket API-hantering tagit fram. På sikt ska Mina ärendens standard närmare kopplas mot andra byggblock i takt med att de blir mer mogna - t.ex. auktorisation/identitet och hur man autentiserar och auktoriserar system och organisation.

Den specifika implementationen av ett producentärendeflöde och tillgängliggörandet av dessa, likt det Värmdö nu gör på samhällsbyggnadsomårdet, ägs av respektive producent (i detta fall Värmdö). Hur vi ska hantera och kunna återanvända det som tas fram av kommuner behöver växa fram i samarbete med de utvecklande kommunerna och SKR.

Inom Mina ärenden har vi sett behov av något vi kallar för kundhändelsetypskatalog där respektive producents producentärenden och tillhörande kundhändelsetyper finns publikt beskrivna (de ursprungliga tankarna bakom en sådan katalog finns beskrivet i byggblocksbeskrivningen kap. 2.2.2). Det är en del i att göra det enkelt för kommande kommuner att ta del av det arbete som gjorts, samtidigt som att det måste finnas frihet och flexibilitet för respektive kommun att själva ta fram de kundhändelsetyper utifrån de behov och förutsättningar som finns inom den kommunen.

@Kenneth-Zetterberg har du något du vill komplettera ovanstående svar med?

Mina ärenden har den 20 oktober 2022 uppdaterat lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som gjorts kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

ID	Vart	Beskrivning
2022-10-18-01	Tjänstebeskrivning	Lagt till möjlighet att fråga på ärende utöver kund efter önskemål från Bolagsverket.
2022-10-18-02	Tjänstebeskrivning	Ensat attributnamn kundhandelseRequest och kundhandelseResponse. Bytt bokstaven ä mot a i kundhändelse-attribut i svar.
2022-10-18-03	Tjänstebeskrivning	Attributet kundhandelsekategori ersatt med producentarendetKraverKundatgard och producentarendetKlart. Tidigare lösning med kundhandelsekategori har vållat en del osäkerhet hos producenter mot vilket värde man ska mappa en kundhändelsetyp mot. Eftersom det ursprungliga behovet är att det ska vara tydligt "vem som har bollen", eller snarare "behöver jag som kund agera" så bedöms det bli enklare och renare med dessa två booleans.
2022-10-18-04	Verksamhetsguide	Uppdaterat kap.2 "Att utforma en kundhändelse" och kap. 2 "Att skriva en kundhändelse" med anledning av att attributet kundhandelsekategori ersatts.
2022-10-18-05	Verksamhetsguide	Nytt avsnitt "Notifiering av kundhändelser" i kap. 2. Beskriver behovet av att avisera kundhändelser och kort om relationen kundhändelse - meddelande.
2022-10-26-06*	Tjänstebeskrivning	Lagt till information om vilken URL skall användas.

Eftersom ändringen innebär ett attrbut utgår (kundhandelsekategori) i den tekniska standarden så har vi valt att skapa en ny plats för tidigare versioner -> Mina ärenden - tidigare versioner.

Befintlig plats på dataportalen kommer istället alltid innehålla den aktuella versionen.

---

*Tillagd efter urspungligt inlägg postades