Delar senaste nyhetsbrevet från NOSAD som också är en årskrönika: https://nosad.se/nyhetsbrev

Halloj!
Tänkte kolla här om det finns någon eller några som testat att implementera och använda SIARD?
Är framförallt intresserad att höra om erfarenheter gällande version 2 (+2.1 och 2.2) där man ska kunna hantera blob:ar och externa filer.

Mer info om SIARD finns här: https://github.com/DILCISBoard/SIARD

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.

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.

Ett exempel: Lantmäteriet är en myndighet, och när jag vill kontakta myndigheten t.ex. här https://www.lantmateriet.se/sv/om-lantmateriet/kontakta-oss/ står det "Få svar på dina frågor genom att mejla oss på kundcenter@lm.se" och det hänvisas även till myndighetens "kundcenter".

För mig verkar det här fel, jag är inte "kund". Har Lantmäteriet alls något som kan kallas "kunder"?

Det här är inte menat som ett påhopp på just Lantmäteriet utan jag är ute efter den mer allmänna frågan om det är rimligt att myndigheter (och kommuner, regioner, osv) pratar om att de har "kunder". En anledning till att det är problematiskt tänker jag är att en myndighet har större ansvar mot medborgarna jämfört med vad ett företag har i förhållande till sina kunder. Bland annat när det gäller sådant som bara berör ett mindre antal människor, företag kan strunta i det när det inte är lönsamt, men en myndighet kan ha ett ansvar att göra vissa saker ändå.

Inte direkt feedback men bildbyrån som DIGG använder är med som exempel på en artikel hos Digiteket. Ett tips kan vara att använda fritt licensierade bilder.

Här presenteras arbetet med en ny nationell strategi för digitalt kulturarv – https://youtu.be/jtYLCU-9tzA

Det har funnits strategier tidigare men nu "kraftsamlar" man igen med nya(?) digitala visioner – Digitalt kulturarv (2011)

Här en presentation av Riksantikvarien om bakgrund och förutsättningar – Riksantikvarieämbetet och digitalisering av kulturarvet

Vad kan man ge för goda råd och tips till det här projektet som ska koppla samman hela det svenska kulturarvet och göra det enkelt digitalt tillgängligt för alla?

Nu har vi i den nationella dataverkstaden tagit fram ett första utkast på datamodell och specifikation för lediga kommunala tomter. Detta avser både tomtmark för olika former av verksamheter och bostäder. Syftet är att denna specifikation ska kunna användas som grund när kommuner publicerar öppna data för sina lediga tomter.

Vi skulle nu behöva er hjälp med att tycka till om specifikationen. Finns det något som saknas, behöver något justeras eller kanske helt tas bort?

Vi ber er skriva era synpunkter och förslag direkt i GITLAB där specifikationen finns publicerad;
https://gitlab.com/sarskilt-viktiga-datamangder/lediga-tomter/-/issues/7

Om ni inte har möjlighet att/vill skapa ett konto på GITLAB kan ni mejla in era synpunkter och förslag till GITLAB genom denna mejladress;
contact-project+sarskilt-viktiga-datamangder-lediga-tomter-40753891-issue-@incoming.gitlab.com

Vi önskar att ni tillför era synpunkter och förslag senast den 31 december 2022.

Är du intresserad att veta mer om vad som händer kring EU:s Interoperabilitetsarbete?

Vill du få bättre koll på Interoperability European Act som ligger som förslag?

Gå in på https://joinup.ec.europa.eu/interoperable-europe

Nu har vi publicerat dataverkstadens lägesrapport för december FYI; https://www.vgregion.se/ov/dataverkstad/aktuellt-lista-notissidor/lagesrapport-december-2022/