17 Referensimplementation, förslag till prototyp
Ett standardiserat gränssnitt som kan användas för att fylla indexeringsbehoven föreslås tas fram. De funktionella kraven på en sammanhållet index är generellt väldigt lika för olika tillämpningar. Det som skiljer är specifika krav beroende på vilken informationsdomän som hanteras. Det är möjligt att ta fram en standardprodukt som kan konfigureras och driftas i den domän den skall användas.
Fördelarna med att separera index mellan olika domäner är många;
- Dataseparation – olika domäner och olika indexhållare har varierande juridiska möjligheter att erbjuda indexeringsfunktion. Genom att separera datan och använda sig av olika indexhållare blir de juridiska förutsättningarna bättre.
- Skalbarhet – Genom att etablera olika index för resp. område får vi en lösning som skalar bättre, det står varje område fritt att skala upp eller skala ned lösningen. T.ex. skulle ”Mina ärenden” indexet som i skrivande stund har hundratals olika händelsetyper som behöver indexeras kunna dela upp dessa index i flera vid behov.
- Prestanda – Med individuella tjänster ökar prestandan och man eliminerar risken att en domän med stort behov försämrar prestandan för en annan domän under kraftig belastning.
- Säkerhet – Olika lösningar för säkerhet kan sättas upp genom att nyttja olika tjänster. Vid ett eventuellt dataläckage minimeras även skadan till ett enskilt område.
En sådan referensimplementation förväntas skapa större förståelse över hur en indexeringslösning kan byggas upp.
17.1 Lagring
Indexeringslösningen har en databas där indexerad information och kringliggande nödvändig data (t.ex. producenter, konsumenter, metadata) lagras. Informationstyper sätts upp via konfiguration av indexhållaren baserat på den domän där lösningen skall användas. Identifierare är inte hårt typat i lösningen utan bestäms även det utifrån domänen och kan variera från t.ex. personnummer/ärendenummer eller ett registreringsnummer på ett fordon. För identifierare som räknas till kategorin persondata rekommenderas användning av pseudonymisering, se kapitel för rättslig analys för vidare vägledning.
17.2 Funktioner
Lösningen är separerad i tre olika gränssnitt, ett API för producenter, ett API för konsumenter och ett gränssnitt för filhantering. Säkerhetsmässigt är det en fördel att separera hanteringen beroende på roll, det ger bra förutsättningar för att begränsa tillgång till enbart nödvändiga funktioner, att inte exponera mer funktionalitet än nödvändigt samt att ha separata säkerhetslösningar utifrån de förutsättningar som finns.
17.2.1 Producent endpoint
Denna endpoint är avsedd för producenter. För att indexeringslösningen skall fungera behöver producenter löpande säkerställa att indexet är aktuellt. Detta görs lämpligen i realtid via API i takt med att uppgifter registreras via denna endpoint.
17.2.1.1 Registrera information
API-funktion för att addera ny information till index.
17.2.1.2 Ta bort information
API-funktion för att radera uppgifter från index.
17.2.1.3 Avisering uppdatering av information
API-funktion för att notifiera om att information som redan finns indexerad har uppdaterats. Via prenumerationsförmågan kan då indexeringslösningen vidarebefordra denna notifiering till intresserade konsumenter.
17.2.2 Filgränssnitt
Vid onboarding av nya producenter som inte har möjlighet till API-kommunikation är det lämpligt att erbjuda ett gränssnitt för att ta emot uppgifter i batch via fil. Samma filformat kan användas för att lägga till och ta bort information men även för aviseringar om uppdateringar.
17.2.3 Konsument endpoint
Denna endpoint är avsedd för konsumenter.
17.2.4 Sök information
Konsumenter kan via denna funktion efterfråga vart information av en viss typ samt tillhörighet finns att hämta.
17.2.5 Sök informationstyp
Konsumenter kan via denna funktion efterfråga information om vart olika typer av information finns. Dessa typer är orelaterade från individuella informationers tillhörighet men bygger på att minst en (1) sådan uppgift finns registrerad. Exempelvis kan funktionen returnera att producent ”Halmstad kommun” är en producent av informationstyp ”BygglovsAnsökan” förutsatt att denna producent rapporterat in minst en (1) sådan uppgift, det är däremot irrelevant vilken identifierare denna uppgift hör till.
17.3 Datamodell
Föreslagen datamodell är förenklad för att hålla detta dokument på en övergripande nivå.
17.3.1 Producent
Register över de producenter som ansluts och registrerar information i indexlösningen.
Kolumnnamn | Beskrivning |
|---|---|
ProducentId | Unik nyckel som identifierar en producent. |
Benämning | En benämning på producenten, kolumnen är inte nödvändig för lösningen men underlättar förvaltningsprocessen. |
Kolumnnamn | Beskrivning |
|---|---|
ProducentId | 1001 |
Benämning | Halmstad bygglovsnämnd |
17.3.2 InformationsTyp
Register över olika informationstyper som skall indexeras. Tabellen är unik för varje domän och konfigureras upp av indexhållaren.
Kolumnnamn | Beskrivning |
|---|---|
ProducentId | Unik nyckel som identifierar en informationstyp. |
Benämning | Beskrivning av informationstypen, kolumnen är inte nödvändig för lösningen men underlättar förvaltningsprocessen. |
Kolumnnamn | Beskrivning |
|---|---|
ProducentId | BygglovsAnsökanInkommen |
Benämning | Händelse som skapas i samband med att en ny bygglovsansökan har registrerats. |
17.3.3 Information
Register över olika informationer som indexerats. Detta är huvudtabellen där den indexerade informationen lagras.
Kolumnnamn | Beskrivning |
|---|---|
Identifierare1 | Identifierare för vem eller vad informationen avser. För enskild domän behöver man komma överens om hur denna identifierare skall användas och hur den skall formateras. Indexhållaren äger ansvaret för detta. |
Identifierare2 | Identifierare för vem eller vad informationen avser. För varje enskild domän behöver man komma överens om hur denna identifierare skall användas och hur den skall formateras. För vissa områden kommer det inte finnas behov av multipla identifierare men för somliga är det ett måste. Indexhållaren äger ansvaret för detta. |
InformationsTypId | Referenskolumn till de olika informationstyperna som kan indexeras. |
ProducentId | Referenskolumn till vilken producent informationen avser. |
URI | URI till producentens API där konsumenten kan hämta önskad information. |
Giltighetstid | Giltighetstid på den indexerade informationen. Kolumnen är inte helt nödvändig för huvudsaklig funktionaliteten men den möjliggör förmågan till gallring. |
Kolumnnamn | Beskrivning |
|---|---|
Identifierare1 | 123e4567-e89b-12d3-a456-426655440000 I detta exempel en GUID men värdet bestäms av resp. område, andra exempel kan vara hashvärde av personnummer, organisationsnummer, kundnummer, ärendenummer, interna nycklar från resp. producent eller annat. |
Identifierare2 | Se beskrivning av Identifierare1. |
InformationsTypId | BygglovsAnsökanInkommen |
ProducentId | Halmstad bygglovsnämnd |
URI | https://halmstadkommun.se/bygglovsnämnden/API/ |
Giltighetstid | 2032-11-03 16:32:00 |
17.4 Åtkomst till uppgifter i Index
Indexerad information kan i en viss uppsättning vara att betrakta som känslig. Blotta existensen av vissa datatyper kan vara att betrakta som känslig information även om indexering inte har ytterligare detaljer. Följaktligen behövs en modell för att avgöra huruvida fråganden har rätt att ta del av den indexerade informationen eller inte. Ansvaret för denna bedömning ligger alltid hos producenten. Verkställigheten av denna kontroll kan göras på olika sätt som beskrivs i kommande kapitel;
- Lokal bedömning i indexeringslösningen
- Distribuerad bedömning hos producenten
- Kombinerad bedömning
En modell för denna bedömning kan vara enkel eller mer komplicerad, den kan vara enkel att förutspå och statisk över tid eller mer komplex och föränderlig över tid.
17.4.1 Lokal bedömning i indexeringslösningen
Indexeringslösningen bedömer autonomt varje förfrågan från en konsument vilka informationsmängder som kan lämnas ut. För att detta skall vara möjligt behöver information om hur denna bedömning skall göras biläggas vid registreringstillfället av information till indexet vid varje enskilt tillfälle. Man kan även tänka sig att ett och samma regelverk alltid tillämpas för information från en viss producent.
Scenario:
- Data som indexeras kommer med behörighetsinformation från producenten.
- Vid förfrågan från konsument nyttjas behörighetsinformation från steg 1 för att avgöra om informationen kan lämnas ut till konsumenten.
17.4.1.1 Fördelar
- Lösningen blir effektiv och svarstiden på förfrågningar hålls ner.
- Lösningen blir robust och är inte beroende av andra tjänster
- Onboarding av producenter förenklas
17.4.1.2 Nackdelar
- Lösningen är antagligen inte heltäckande och kommer inte till fullo stödja alla framtida önskemål
- Behörighetsmodellen kan bli komplicerad att bygga som en standard modell som skall fungera för många olika producenter.
17.4.2 Distribuerad bedömning hos producenten
I samband med att en konsument efterfrågar information kontaktar indexeringslösningen producenten via ett dedikerat API. Detta sker i realtid och producenten bedömer huruvida fråganden har rätt att ta del av informationen. Således behöver indexerade uppgifter inte biläggas med information om bedömningsmodellen vid registreringstillfället utan istället behöver producenten tillgängliggöra ett API enl. specifikation som tas fram av byggblock indexering.
Scenario:
- Data som indexeras kommer helt utan behörighetsinformation från producenten.
- Vid förfrågan från konsument identifierar indexlösningen relevant information.
- Indexlösningen kontaktar varje enskild producent för informationen från steg 2 och ber de olika producenterna att bedöma om fråganden har rätt att ta del av uppgifterna.
- Producenterna gör bedömningen och svarar jakande eller nekande.
- Indexlösningen returnerar information med jakande svar från producenterna.
17.4.2.1 Fördelar
- Enklare implementation av prototypen.
- Lösningen är framtidssäker och kommer till fullo täcka olika behov av bedömningsmodeller.
17.4.2.2 Nackdelar
- Varje producent behöver finnas tillgänglig via API för indexeringslösningen.
- Varje producent behöver bygga API för bedömning av rättigheter i realtid.
17.4.3 Kombinerad bedömning
En kombination av de båda varianterna för bedömning är att rekommendera. Genom att kunna välja alternativ per producent eller per indexerad information kan man välja den bästa lösningen för varje scenario
Fördelar
- Mer flexibel lösning där varje producent kan välja den modell som passar dem bäst.
Nackdelar
- Inga nackdelar noterade
Ditt svar hjälper oss att förbättra sidan
Senast uppdaterad: