Uppdaterad dokumentation 20220914

johantjader

@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)?

johantjader

--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)

@johantjader sa i Uppdaterad dokumentation 20220914:

@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)?

Jag är nog ute och cyklar igen trodde du pratade om det API framework som togs fram av @jonass

Sorry

johantjader

@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

johantjader

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?

jonass

@johantjader Jag skulle nog ändå råda er att se över om det verkligen är nödvändigt att använda HTTP POST för läsoperationer. Tänker att HTTPS är grunden för en säker kommunikation och det viktigaste, och sedan går det alltid går att undvika att logga hela förfrågnings-URL. Sen finns det andra småtips som "Referrer hiding" etc. Kan säkert finnas fog för valet. Men att bryta mot grundläggande principer om hur internet är uppbyggt bör noga övervägas, små beslut tenderar till att leda till problem med interoperatbilitet om flera gör olika i dessa frågor.

jonass

Sen har jag en metapoäng om att namnet "mina ärenden" är något förvirrande. Jag får mer känslan av att byggblocket hanterar "Mina Notifieringar". Kanske inte är önsvärt att ändra det såklart. Men när jag läser dokumentationen så får jag förhoppningen om att nu äntligen kommer ett förslag på det "slutgiltiga" schemat och begreppsmodell för hur en myndighet bör representera informationsmängden ärende.

Jakob Fransson

@jonass
Hej Jonas! Schema och begreppsmodell för hundratals autonoma offentliga aktörer på verksamhetsprocessområdet är en rejäl utmaning. Håller helt med om att det skulle ha varit bra om det fanns. Vi har avgränsat oss till ärendeåterkoppling och tror det finns ett stort värde att hämta om offentliga aktörer kan mappa sina processer till standraden och tillgängliggöra sk. kundhändelser, då det ger ökan insyn och kontroll för den det berör. Här ligger fokus initialt och vi tror det kommer vara ett minst sagt omfattande arbete att ensa på ärendeåterkopplingsområdet. Det skulle kunna vara en början på det du efterfrågar, det får tiden utvisa. Håller också med om att namnet Mina ärenden kan vara missvisande, vi tar med oss den.

Fredrik Ferm

@jonass Hej Jonas

Ja du har rätt, detta bryter mot grundläggande REST-principer, vilket i sig är ett problem.

Men att exponera personnummer är också ett problem som till en början kan tyckas vara lite banalt. Men vi vill att standarden för Mina ärenden skall kunna användas i många verksamheter och därför måste vi tänka lie kring de värsta fallen. I vissa fall av offentlig förvaltning bara vetskapen om att någon frågar om en viss person till en viss producent ett säkerhetshål. Till exempel kan man tänka sig att vetskapen om att många frågor ställs till en viss kommun om en person med skyddad identitet säger någonting om var denna person befinner sig. Eller att vetskapen om att frågor ställs om en viss person till en specifik vårdinrättning (cancerbehandling, könsbyte etc) exponerar information om personens medicinska hemligheter.

Så här behöver vi välja mellan två dåliga alternativ. Antingen bryta mot REST-principer och komplicera lösningen eller potentiellt exponera skyddsvärd information. I den sammanvägda bedömningen har vi landat i att skyddet är viktigare än principerna i detta fall och därför har vi ändrat till POST.

jonass

@Jakob-Fransson Många projekt börjar med för stora omfång och kommer aldrig till det konkreta. Att som ni börjar med att leverera något konkret och avgränsat är ju en viktigt för att det ska bli något vettigt. Så det var inte kritik. Snarare så kanske "mina ärenden" har en solid strategi. Kommer någon myndighet att göra ett formellt åtagande att börja använda det ni kommer fram till? Tänker att någon måste vara först ut.

jonass

@Fredrik-Ferm Tror många med er resonerar på liknande sätt. Delar er riskbedömning, men jag är inte helt övertygad att åtgärderna behöver vara att lämna GET.

johantjader

@jonass Hej Jonas
Vi tolkade det som inte kritik och vi håller med dig till 100% tror det är en framgångsfaktor att avgränsa sig och våga testa att vara så konkret det går - även om det gör ont eller inte att allt inte riktigt hänger hop.

Först ut är Skatteverket som siktar på att ha ett kundhändelse-API i produktion v.44. Vi kommer lägga ut mer information om det inom kort.

Sen håller vi på att starta upp piloter med ett antal olika kommuner på bygglovsområdet. Intressant där är att verksamhetsprocessen "söka bygglov" är i stort likadan i varje enskild kommun vilket skapar en del nya utmaningar som vi vill lära oss mer om.

Därutöver håller några av myndigheterna som har koppling till verksamt.se att jobba med kundhändelser - dels att generera ärendeåterkopplingen och dels att göra informationen tillgänglig på ett standardiserat sätt.

Skjut gärna på med mer inspel och fortsätt följa Mina ärenden, vi är fortfarande i en utvecklande fas där all input är uppskattad

Jonas Nordqvist

@johantjader är det nån kommun från Stockholmsregionen som ska vara med i piloten kring bygglov?

johantjader

@Jonas-Nordqvist
Hej Jonas
Värmdö är med på piloten tillsammans med Boverket och så ser vi också ut att få med en norrlandskommun på den här första kommunpiloten.

Men vi söker fler piloter och ser gärna att fler kommuner sätter sig in i de lösningar som vi håller på att ta fram för att se vad som fungerar bra och mindre bra. Har du spontant förslag på någon/några kommuner som skulle kunna vara intresserade eller forum där vi skulle kunna nå ut med att berätta närmare om initiativet Mina ärenden?

Jonas Nordqvist

@johantjader

@johantjader sa i Uppdaterad dokumentation 20220914:

Har du spontant förslag på någon/några kommuner som skulle kunna vara intresserade eller forum där vi skulle kunna nå ut med att berätta närmare om initiativet Mina ärenden?

Ja, det har jag. Kontakta mig på jonas.nordqvist@storsthlm.se

johantjader

@Jonas-Nordqvist Du har mail

Fredrik Forsberg

@Fredrik-Ferm
Jag instämmer i @jonass tankar och det är synd att ett behov av att bryta mot REST finns. Men ser att detta iaf stämmer väl överens med vad som står angivet i den tekniska dokumentationen för Mina Ärenden på skatteverket (https://skatteverket.entryscape.net/store/9/resource/1667) och det är det absolut viktigaste. Att samtliga myndigheters ärenden/händelser och api:er för dessa fungerar likadant
Sen svider det alltid lite i själen när avsteg från väletablerade mönster behöver göras

Ska försöka följa det här forumet, superbra om ni kommer med information kring detta allt eftersom!

Vill någon eller några myndigheter/kommuner ha input tidigt, framför allt om det gäller företag, även på skiss-stadie så är det bara att höra av sig. Oftast mycket lättare att komma med konkret feedback när man har något att "ta" på.

Fredrik Axelsson Forsberg
/VISMA Spcs

johantjader

@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

Dennis_Priskorn

@johantjader Hej. Jag läste lite i begreppsmodellen. Det verkar vara en hel del där som är på svenska. Hur tänker ni kring språk?

Om vi lyfter blicken, skulle man då kunna tänka sig att andra EU-länder skulle ha nytta av att kunna förstå eran begreppsmodell och kopiera det som passar till sina system/byggblock?

Finns det någon tungtvägande skäl till att inte bara köra allt på engelska nu när i princip alla moderna programspråk och ramverk ändå i princip endast har dokumentation på engelska?

För mig personligen verkar det ganska främmande och onödigt inlåsande att välja svenska när jag skriver kod (jag jobbar internationellt i allt jag gör)

Skulle det inte vara kul om tex. Tjeckien börjar kopiera svenska statens högkvalitativa byggblock för att ni gjort så himla bra förarbete? Ni kanske även släpper era implementationer som öppen källkod så det enda de behöver göra är att översätta UI:n och sen kan de lansera till sina medborgare.

Min gissning är att tröskeln för spridning bliver onödigt stor om allt är inkodad i svenska. Ni riskerar att tappa värdefull input från andra aktörer (tex internationella företag).

(ni kan såklart publicera svenska översättningar på alla begrepp också alla vet vad som är vad och kan prata om det på svenska internt eller mellan myndigheterna)

Fredrik Ferm

@Dennis_Priskorn Hej Dennis och tack för din fråga.

Det finns en enkel och i vår mening tungt vägande anledning till att begreppen är på svenska och det är att verksamheten bedrivs på svenska inom i stort sett all offentlig förvaltning i Sverige. Mjukvarusystemen är primärt till för att stödja verksamheten och när den bedrivs på svenska bör även systemen använda svenska begrepp när man representerar saker ifrån verksamheten. Om vi istället skulle göra en översättning av verksamhetsbegrepp till engelska riskerar vi att olika översättningar på olika ställen (även utanför Mina ärenden) sker på olika sätt för samma begrepp.

Sedan har du helt rätt i att mjukvaruutveckling och kodande i sig självt är en verksamhet som oftast görs på engelska. Det är ofta ’kutym’ och kulturellt riktigt för utvecklare att använda engelska som språk när man kodar men risken för ihopblandning av begrepp är i vår mening ett större problem än den diskrepans som finns mellan språken vid utvecklingstillfället.

Mycket av arbetet som kommer att ske när man implementerar Mina ärenden hos olika offentliga producenter och olika konsumenter handlar om att förstå och beskriva de faktiska processer som sker inom olika myndigheter och andra offentliga förvaltningar. Sedan skall denna förståelse kodas in i system och kundhändelser skall skickas ut vid lämpliga tillfällen. Detta är specialiserat för den verksamhet som kundhändelserna handlar om. Då blir det ändå svårt att dela implementationen med andra länder och därför blir översättningsproblematiken vid en eventuell sådan delning mindre.

Men, allt handlar om avvägningar och kompromisser. Inom Mina ärenden har vi gjort bedömningen att direktmappning till verksamhetsbegrepp är viktigare än kodnings-kutym och eventuell delning av lösningar.