Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
SW E D I SH E N V IR O N M EN T A L P R OT E C T IO N AG E NC Y
Miljöinformationsenheten (Mi)
2019-08-22 Ärendenr:
NV-02644-17
Arkitekturspecifikation GoS Version 1.2
Kallonen, Kim [Datum]
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
1 (45)
Innehåll 1. Introduktion ......................................................................................................................... 2
1.1. Dokumentets syfte ....................................................................................................... 2
1.2. Ordlista ........................................................................................................................ 2
1.3. Historik – arkitektur för tillgängliggörande – AFT ..................................................... 2
1.4. Nyläge GVU-MCP ...................................................................................................... 6
1.5. Referenser .................................................................................................................... 6
2. Verksamhetsperspektiv ....................................................................................................... 7
2.1. Beskrivning av systemets mål och syfte ...................................................................... 7
2.2. Processbeskrivningar ................................................................................................... 9
2.3. Behörighet och åtkomst ............................................................................................. 15
3. Juridiskt perspektiv ........................................................................................................... 19
3.1. Underrättelse av anläggningsinformation .................................................................. 19
3.2. Identitet och åtkomst ................................................................................................. 21
4. Informationsperspektiv ..................................................................................................... 26
4.1. Övergripande beskrivning ......................................................................................... 26
4.2. Hantering av versioner och historiska data ................................................................ 27
4.3. Beskrivning Bastjänst för anläggningsuppgifter (BTSNA) ....................................... 27
4.4. Beskrivning Bastjänst för aktörsuppgifter (BTAU) .................................................. 28
4.5. Beskrivning Bastjänst för Kodlistor (BTKL) ............................................................ 31
4.6. Beskrivning av sammansatt bastjänst (SSBTSNA) ................................................... 32
4.7. Kontrakt ..................................................................................................................... 33
5. Tekniskt perspektiv ........................................................................................................... 33
5.1. Arkitektur för tillgängliggörande – AFT ................................................................... 34
5.2. Koncept tillfällig lösning åtkomst och behörighet – GoS 1.0/MCP-release. ............ 36
5.3. E-tjänstens integration med extern part – SSBTGU samt Navet ............................... 37
5.4. Översikt lösning BTIU Bastjänst samt BTIU Webb ................................................. 37
5.5. Tjänstebeskrivning Teknisk dokumentation SNA ..................................................... 38
5.6. Informationsutbytesflöden och metoder .................................................................... 38
6. Dokumenthistorik ............................................................................................................. 45
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
2 (45)
1. Introduktion
Dokumentet beskriver, utifrån ett verksamhets-, juridiskt-, semantiskt- och tekniskt perspektiv
det sammantagna arbetet som gjorts inom projekten Gemensamt gränssnitt för
verksamhetsutövare, Steg 1 – MCP (GVU) och Samlade nationella anläggningsuppgifter
(SNA). Därav benämningen GoS (GVU och SNA). Avgränsningen har varit att hålla sig inom
arkitekturdisciplinen samt att delvis beskriva och sammanfatta arbetet utifrån ett
projektperspektiv. I projektens slutrapporter sammanställs samlade projekterfarenheter.
En stor mängd detaljer, t. ex. textbeskrivningar för olika modeller återfinns i Sparx Enterprise
Architect. Likaså kompletta arkitekturella beskrivningar ur olika perspektiv och kontext. I
dokumentet har några få arkitekturella beskrivningar valts ut och ansatsen är att beskriva
perspektiven för GoS 1.0/MCP-release uppdelat inom samma abstraktionsnivå och minimera
hopblandningen av dessa. Inledningsvis beskrivs nylägen såsom målkoncept i stort. Därefter
beskrivs underliggande abstraktionsnivåer om det finns ett behov att sätta GoS 1.0/MCP-
release nivån i ett sammanhang.
Dokumentet beskriver också:
• Det sammantagna arbetet som gjorts vad gäller behörighetsbehov och
åtkomstlösningar – avgränsning är dels GoS (dvs inte hela miljösverige) och dels GoS
1.0/MCP-release.
• Vidareutvecklingen som gjorts inom bastjänst för inlämnade uppgifter, BTIU, och
arkitektur för sammansatt bastjänst för att nå data inkommet till myndighet, SSBTIU. I
denna version fokuseras inlämnande av grunduppgifter för miljöfarlig verksamhet –
även kallat administrativa data för verksamhetsutövare.
Det tekniska perspektivets detaljerade innehåll för GoS 1.0/MCP-release återfinns inte i detta
dokument. För det refereras respektive ingående tjänsts Tjänstebeskrivning Teknisk
Systemdokumentation.
1.1. Dokumentets syfte
Skapa en sammanhållen arkitekturell beskrivning av de fyra olika skikten som kan användas
för att kvalitetssäkra arbete framåt, göra avvägningar inför framtida
verksamhetsprioriteringar, projektavgränsningar, arkitekturella strategival samt utgöra en
grund för framtagande av användarfall och onboarding till nya arkitekturen.
Syftet är också att beskriva viktiga avsteg mot arkitektur inklusive motiveringar för avstegen.
För en fullständig förteckning, se dokumenten som beskriver gap gentemot arkitekturen, [ref
9], samt projektens godkända och beslutade restlista, [ref 10].
1.2. Ordlista
Se Naturvårdsverkets IT-ordlistan:
http://enos:8080/webspace/getdocument/document?id=117717006
1.3. Historik – arkitektur för tillgängliggörande – AFT
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
3 (45)
Arkitektur För Tillgängliggörande (AFT) redovisar vilka komponenter arkitekturen består av
och vilka krav och styrningar som finns på arkitekturen. Arkitekturen vilar på underliggande
definitioner av lösningsmönster för ingående komponenter.
Genom att kombinera arkitekturens komponenter med lösningsmönster kan tydliga vyer
skapas för förståelse av "nuläge/mållösning/målarkitektur".
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
4 (45)
I den mån existerande tekniska lösningar är stabila, redan förankrade och har låg sannolikhet
för utbyte i närtid, kan de också ingå i en mållösningsbeskrivning för att skapa ytterligare
tydlighet.
På lokalt plan (hos respektive myndighet) konkretiseras tekniska lösningar med utgångspunkt
från faktiska behov/initiativ för att beskriva ett nuläge eller ett kommande läge.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
5 (45)
Diagrammet vill påvisa tre stora tekniska områden som definierats och som syftar till att
transformationen mot en mer digitaliserad hantering av information ska kunna genomföras
mer effektivt:
• Stöd för verksamheten (handläggning, in-/utrapportering etc)
• Stöd för tillgängliggörande (delning av gemensamma och öppna resurser)
• Stöd för kommunikation och visualisering (Webbar och sociala medier)
Diagrammet nedan visar en konceptuell digital lösning för försörjning av miljöinformation
genom informationsutbyten med verksamhetsutövare (VU/GVU), berörd allmänhet
(BA/GBA) och andra myndigheter. Konceptet har som målsättning att påvisa alla viktiga
delfunktioner för den samlade informationsförsörjningen och utgöra diskussioner om
funktionalitet, delmål, transitionsplanering etc.
Notera1: en viktig del i AFT är de styrande principerna dokumenterade i Sparx (referens:
Arbetsmaterial.Digitalisering Nv.Krav, Principer, Vägledningar, Guider.Principer säkerhet,
bastjänster, sammansatta bastjänster, information).
Notera2: – Arkitekturspecifikationen lyfter fram flera viktiga avsteg mot
målkonceptarkitekturen. För en komplett lista se dokument GAP_analys_mål_nov2018, [ref
9]. Informationsväxel (ESB) ingår inte i denna release och därför inte heller i gap-analysen.
ESB återstår till stor del att analysera och planera för.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
6 (45)
1.4. Nyläge GVU-MCP
Hur e-tjänster respektive bastjänster i GoS 1.0/MCP-release passar in i denna målarkitektur,
dvs var olika tjänster hör hemma i målarkitekturen framgår av innehållet i avsnitt 5, t. ex.
5.1.2 GVU-MCP koncept och målbild.
1.5. Referenser
Nr. Titel Version Plats
1. Eget utrymme är numera accepterat i
lagmotiv – men vilka juridiska krav
ställs på eget utrymme?
eSam
2. Verksamhetsutveckling inom e-
förvaltning 3.0
eSam
3. Lösningsbeskrivning_MCP_juridik_v1.0 1.0 Modena ärende
NV-02644-17 och
NV-01505-17
4. Rättsliga förutsättningar för digitalt i
första hand.
eSam
5. Referensarkitektur för Identitet och
Åtkomst.
Inera
6. Förstudie om kontaktuppgifter för
privatpersoner – Mina kontaktuppgifter
1.0 eSam
7. Strukturerad omvärldsbevakning inom
arkitektur för digital utveckling
Inera
8. Juridik som stöd för förvaltningens
digitalisering
Statens offentliga
utredningar.
9. GAP_analys_mål_nov2018 1.0 Modena ärende
NV-02644-17 och
NV-01505-17
10. Restlista och synpunkter 1.0 Modena ärende
NV-02644-17 och
NV-01505-17
11. Bilaga Användningsfall SSBTSNA 1.0 Modena ärende
NV-02644-17
12. Checklistetest BTAU infoägarskap Modena ärende
NV-02644-17
13. Tjänstebeskrivning Teknisk
Systemdokumentation SNA
P1.3 Modena ärende
NV02644-17
14. Tjänstebeskrivning Bilaga API-
beskrivning SSBTSNA
1.0 Modena ärende
NV-02644-17
15. BTIU Kontraktdokument
1.1 Modena ärende
NV-01505-17
16. BTIU Systemdokumentation
1.0 Modena ärende
NV-01505-17
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
7 (45)
Nr. Titel Version Plats
17. Funktionsbeskrivning_steg P
1.0 Modena ärende
NV-01505-17
2. Verksamhetsperspektiv
2.1. Beskrivning av systemets mål och syfte
Bastjänster för samlad hantering av anläggningsuppgifter på nationell nivå som möter
framtida behov utifrån den svenska miljölagstiftningen är en grundsten i det digitaliserade
arbetssätt som planeras inom regeringens initiativ Digitalt först - Smartare miljöinformation.
Masterdatahantering av anläggningar och verksamheter inom ramen för miljöbalken och övrig
miljölagstiftning ökar kvalitén på de uppgifter som hanteras inom ramen för prövning, tillsyn
samt nationell och internationell rapportering.
Bastjänsterna kan hålla information om många typer av anläggningar i verksamheter vilka är
anmälnings- eller tillståndspliktiga, registrerings- och/eller rapporteringsskyldiga i enlighet
med olika lagar och direktiv inom miljöområdet.
På sikt ska bastjänsterna innefatta många olika typer av anläggningar inom miljöområdet,
men initialt innefattas miljöfarlig verksamhet så att:
• SMP kan ersättas (A-, B-, IED-, E-PRTR- och andra anläggningar som finns idag)
• EU och nationell rapportering kan hanteras
• MCP-direktivets krav på registrering av anläggningar hanteras.
Tre bastjänster har utvecklats:
• en bastjänst för lagring av uppgifter om anläggningar och verksamheter (BTSNA),
• en bastjänst för lagring av uppgifter om aktörer (BTAU) och
• en bastjänst för lagring av kodlistor (BTKL),
samt en sammansatt teknisk bastjänst (SSBTSNA) som ger ett samlat gränssnitt för att lämna
och hämta uppgifter i de tre bastjänsterna.
På sikt ska bastjänsterna stödja flera olika processer, vilket nedanstående bild visar:
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
8 (45)
Bild. Processer bastjänsterna ska stödja
Uppgifterna som lagras i bastjänsterna har lämnats in av verksamhetsutövaren, till den
operativa tillsynsmyndigheten (en länsstyrelse eller en kommun) via en nationell e-tjänst eller
en lokal e-tjänst – och utgör del av den operativa tillsynsmyndighetens tillsynsobjektregister
(enligt 7 § miljötillsynsförordning (2011:13)).
Genom den sammansatta tekniska bastjänsten (SSBTSNA) kan tillsynsmyndighetens
verksamhetsstödsystem hämta och lämna uppgifter i de enskilda bastjänsterna (BTSNA,
BTAU och BTKL). De olika tillsynsmyndigheternas information hålls separerad med hjälp av
behörighetsstyrning. Rapporteringsansvarig myndighet kan också via SSBTSNA hämta
uppgifter från de enskilda bastjänsterna efter att respektive tillsynsmyndighet som äger
informationen i bastjänsterna BTSNA och BTAU godkänt detta.
2018-02-27 2
VUFöretag
Underrätta om
verksamhet
Lämna in
miljörapport
e-tjänst för
nya &
ändrade
grund-
uppgifter
e-tjänst för
miljörapport
Handläggning
(i Miljöreda, Castor,
Ecos…)
e-tjänst för
Ansökan/
anmälan
av verks-
amhet
GVUB
ehö
rige
t/Säke
rhe
tKomplettera
ansökan/anmälan/
underrättelse
”Skyltfö
nste
r” (We
bb
pla
tse
r)
SNAVerksamheter
AktörerKodlistor
Info
rmatio
nsväxe
l
Rapportera
nationellt och
internationellt
Tillgängliggöra
information publikt
Samlade Nationella Tillständs-
uppgifter
Samlade Nationella Inrapporter
Operativ Tillsynsmyndighet
Rapporteringsansvarigmyndighet
Ansöka/Anmäla
om verksamhet
Process - berörd
Process – del av målbild
IT-komponenter - initierad
Bastjänst - initierad
Bastjänst – ej initieradIT-komponenter – ej initierad
SMP
Handläggning
tillstånd
Prövningsmyndighet
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
9 (45)
2.2. Processbeskrivningar
Konceptvy Miljöskydd
Kapitlet beskriver översiktligt processen vid registrering av MCP-anläggningar, vilket är den
tjänst som realiseras i GoS 1.0/MCP-releasen av GVU/SNA.
2.2.1. IED och MCP direktivet 2018-12-20 (GoS 1.0/MCP-release)
När en verksamhetsutövare (VU) anmäler en anläggning/ansöker om tillstånd har det tidigare
ofta varit länsstyrelsen som skapat objektet/anläggningen i enlighet med prövningsprocessen.
Det är då tydligt vilken tillsynsmyndigheten är från början. Enligt MCPD ska VU underrätta
om medelstora förbränningsanläggningar själv utan Samrådsförfarande. Det betyder att VU
behöver kunna ange tillsynsmyndighet på den inlämnade uppgiften baserat på verksamhetens
geografiska placering. Tillsynsmyndigheten kan vara en kommun eller en länsstyrelse.
2.2.2. Användningsfall för realiserade anrop
Rutiner och logik som behövs för att söka, läsa, och spara data i bastjänsterna beskrivs i
”Bilaga Användningsfall SSBTSNA”,[ref 11].
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
10 (45)
2.2.3. Lämna in uppgifter
1. Logga in
Uppgiftslämnarens identitet kontrolleras med hjälp av e-legitimation.
2. Välj organisation att lämna in uppgifter för
En uppgiftsinlämnare kan ha flera organisationer och anläggningar att lämna in
uppgifter för. Uppgiftslämnaren väljer det engagemang (lagrat som uppdrag i BTAU)
som ska användas. Verksamhetsutövare kan även välja att skapa ett nytt engagemang.
3. Ange uppgifter
Om ett tidigare skapat engagemang används förifylls uppgifter från detta. Uppgifter
kan också hämtas från Bolagsverket. Följande grundläggande uppgifter hämtas då
genom e-tjänsteplattformens Bolagsverkskomponent:
o UD0040 - Belägenhetsadress till företaget
o UD0010 - Belägenhetsadress till företagets arbetsställen
o UD0043 - Benämning på företagets arbetsställen
o UD0023 - Enskild näringsidkares folkbokföringsadress
o UD0003 - Juridisk person postadress
o UD0011 - Kommunkod säte
o UD0009 - Postadress till företagets arbetsställen
o UD0001 - Registrerat företagsnamn
o UD0024 - SNI-koder företag
o UD0023 - SNI-koder för företagets arbetsställe
I övrigt anges uppgifter om anläggningen manuellt enligt nedan:
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
11 (45)
Varje e-tjänst har ett specifikt syfte och vanligtvis en uppsättning specifika uppgifter
som ska fyllas i. Om arbetet med att fylla i uppgifter inte avslutas vid ett och samma
tillfälle finns möjligheten att mellanlagra inmatade uppgifter (arbetsmaterial) i ett sk
"eget utrymme". Arbetsmaterialet kan sedan arbetas vidare med vid ett senare tillfälle.
4. Validera angivna uppgifter
Steget innebär att den som lämnar in uppgifter kontrollerar och verifierar uppgifterna
innan de skickas in (till den grad som tillåts med automatik).
5. Skicka in uppgifter
Efter det att de uppgifterna kontrollerats skickas de in till mottagande myndighet som
registrerar lämplig diariehändelse i förhållande till inrapporteringen. Inlämnade
uppgifter blir därmed en inkommen handling till angiven myndighet.
6. Erhåll kvittens
När underskrift har utförts och uppgifterna har skickats in erhålls kvittens på att
uppgifterna är inkomna till mottagande myndighet.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
12 (45)
2.2.4. Godkänna/avslå.
I MCP-direktivet anges att tillsynsmyndigheter har en månad på sig att ta ställning till
inlämnade uppgifter. Sedan anses uppgifterna vara gällande och informationsstatus för
ingående objekt sätts till ”Granskad” automatiskt. Tillsynsmyndigheten kan inom en månad
begära korrigering/komplettering, se flöde ”Hantera inlämnade uppgifter”, och då inväntas
svar från verksamhetsutövaren.
Funktionen för att automatiskt godkänna uppgifter har inte implementerats.
2.2.5. Hantera inlämnade uppgifter.
1. Tillsynsmyndigheten diarieför inkommen handling och kvitterar till
verksamhetsutövaren.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
13 (45)
Tillsynsmyndigheten som tar emot uppgifterna diarieför och hanterar inkommen
handling.
2. Kvittera till verksamhetsutövaren
Verksamhetsutövaren (och den aktör som eventuellt verkar för dennes räkning) får ett
kvitto på att uppgifterna kommit in via kanal som aktören valt.
I detta steg också hämtas diarienummer från myndighetens ärendehanteringssystem så
att ärendet kan åberopas och följas av aktören. Kompletteras/ändras inlämnade
uppgifter kan uppdaterade uppgifter kopplas till det påbörjade ärendet som ny
inkommande handling. Se även avsnitt 3.1 Underrättelse av anläggningsinformation.
3. Inlämnade uppgifter OK?
Tillsynsmyndigheten kan granska inlämnade uppgifter och avgöra om ändringar eller
kompletteringar behövs.
Kontroll av uppgifter som lämnas in kan avse kontroll av att obligatoriska fält i
formuläret är ifyllda och att innehållet har rätt format. Kontrollen kan också avse att
lämnade uppgifter är rimliga, t.ex. att givna koordinater ligger i Sverige.
Normalflöde: Tillsynsmyndigheten granskar och accepterar uppgifterna.
Alternativflöde: Tillsynsmyndigheten begär komplettering eller korrigering av
inlämnade uppgifter.
4. Komplettera/ändra inlämnade uppgifter
Trots automatiserade kontroller av uppgifterna kan det finnas anledning att begära
ändringar eller kompletteringar. Ändring eller komplettering leder till att ny handling
inkommer och hanteras i Aktivitet 1.
5. Registrera inlämnade uppgifter
Då uppgifterna behandlats av tillsynsmyndigheten och godkänts, registreras
uppgifterna genom att status ändras i registret.
2.2.6. Behörighetsperspektiv - användarscenario: Lägga upp företagarkonto inkl.
verksamhetskomplex första gången.
Aktivitetsdiagrammet nedan matchar processen beskriven i avsnitt 2.2.3 Lämna in uppgifter
och är en temporär första version på lösning för aktörshantering.
Inget data migreras från SMP i denna release av SNA. GVU levererar inte heller en
”Ombudsfunktion” för delegering av uppdraget att underrätta om MCP till annan
uppgiftslämnare än juridiskt ansvarig. Det innebär att en användare som har loggat in med e-
legitimation kan lämna in uppgifter utan att ha ”juridisk/avtalad rätt att göra så”. För att
underlätta tillsynsmyndigheters handläggning och eventuellt behov av verifiering märks den
inlämnade handlingen med en status, som anger om aktörsuppgifter har förifyllts eller
angivits manuellt.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
14 (45)
E-legitimeringen identifierar en fysik person. Är uppgiftslämnarens bolagsuppgifter förifyllda
via Bolagsverket (SSBTGU) och grunduppgifter för bolagsfälten är låsta för modifiering
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
15 (45)
anses kontot vara verifierat eftersom uppgifterna är registrerade hos Bolagsverket.
Uppgiftslämnarens uppgifter kan därmed taggas som kvalitetssäkrade.
Då valideringen ”finns företag att knyta till person” båda har samma utgång oavsett om
personen är firmatecknare eller inte är behovet av att tillåta företrädare att lämna in
anläggningsinformation hanterat. Informationen om personen som lämnat in uppgiften är
behörig att göra detta eller inte läggs automatiskt inbäddat i den inlämnade handlingen.
Handlingen”stämplas” med information om status på förifyllnad. (Notera att informationen
om förifyllnad inte läggs som metadata i syfte att hålla BTIU generell). Tillsynsmyndigheten
ges därmed information om personen validerats eller inte och kan kontrollera
uppgiftslämnaren genom att ringa till personen eller företaget.
Attribut/status för inlämnad handling sätts default till ”Inlämnad” (=NY) på handlingens
metadata vid inlämnande. Tillsynsmyndigheten kan sedan uppdatera status till "Granskad"
(=OK) respektive "Borttagen" (=NOK) på metadatat. (Notera att handlingen i sin helhet får
statusen). Den status som sätts på den inlämnade handlingen sätts också på
Verksamhetkomplex och Uppdrag via SSBTSNA. Väljer Tillsynsmyndigheten att inte
godkänna den inlämnade handlingen motsvarar det att ”avveckla administratörkonton” i
avsnitt 2.3.3 Administrera användare nedan. Notera att personuppgifterna i BTAU inte tas
bort, det är endast tillhörande uppdrag och verksamhetskomplex som sätts som makulerade.
Det beror på att samma person kan hantera flera anläggningar.
E-tjänsten GVU/MCP stödjer inte andra språk än svenska, vilket behövs för att stödja eIDAS.
Anledningen är tidsbrist såväl vad gäller att ändra hanteringen av svenska personnummer till
generiskt ID som att komplettera med stöd för andra språk, t.ex. engelska. Konsekvensen är
att även om en giltig e-legitimation valideras för en utländsk verksamhetsutövare tilldelas inte
verksamhetsutövaren åtkomst till e-tjänsten för MCP. Verksamhetsutövaren hamnar istället i
ett väntrum där det framgår kontaktinformation.
2.2.6.1 Diariehantering
Eftersom lösningen i GoS 1.0/MCP av GVU/BTIU endast stödjer att skicka in nya
handlingar i sin helhet samt att grafiskt gränssnittsstöd för aktörsadministration av
behörigheter och kontaktinformation saknas blir eventuella uppdateringar av uppgifter som
inte betraktas som ”väsentliga” enligt MCPD-direktivet ändå diarieförda och hanterade som
inkommen handling hos myndigheten.
2.3. Behörighet och åtkomst
Naturvårdsverket ska tillhanda IT-baserade funktioner för inloggning åt EU-medborgare,
verksamheter och andra myndigheter.
2.3.1. Behoven
är bl.a. att:
1. Hantera federativ/distribuerad administration av behörigheter. För utförliga detaljer, se
”Referensarkitektur för Identitet och Åtkomst, [ref 5]. T.ex. avsnitt 3.2 och styrande
principer där IA4 t. ex. säger att:
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
16 (45)
”e-tjänster använder federerad identitetsdata och behörighetsgrundande information i
utgivet identitetsintyg som bas för en behörighetsprofil i e-tjänsten.
Vid behov kompletterar e-tjänsten med ytterligare uppgifter kopplat till användaren för att
avgöra de rättigheter användaren ska ha till information och funktioner i e-tjänsten. Motiv:
en gemensam bas för identitet och behörighet skapar förutsättning för god skalbarhet och
minskad administrativ börda i verksamheterna. Identitets- och behörighetsadministration
kan konsolideras till en funktion där en användare samlat kan ges grundläggande
rättigheter att arbeta med de IT-system och den information som hens arbete eller
individuella behov kräver. Även borttag av rättigheterna (t.ex. när medarbetare slutar
anställning) underlättas.”
1.1. Logga in en gång – single sign on (SSO)
1.2. Maskin-till-maskin (M2M). I GoS 1.0/MCP endast för GVU och manuell hantering
av åtkomst – se avsnitt 5.2.1 Tillfällig API-säkerhetslösning.
2. Support för e-legitimation – s.k. ”stark autentisering”, tvåfaktorsautentisering.
3. Självbetjäning avseende administration av behörigheter är ett viktigt behov som saknas i
GoS 1.0/MCP. Att ha kontroll över behörigheter, att administrera och presentera vem
som har vilka behörigheter, kommer att behöva realiseras inom kort. Se vidare avsnitt
2.3.3 Administrera användare nedan.
4. Mellan myndigheter stödja lösningsmönstret för ”Utlämnande på medium för
automatiserad behandling”, [ref 2], och möjligheten för informationsägande myndighet att
”reagera”. Tolkningen av lösningsmönstret för ”utlämnande på medium…” är att
”reagera” görs automatiskt vid behörighetsverifiering vid varje anrop (fortsatt giltig access
eller inte) tillsammans med loggning av vem som gjort vad.
2.3.2. Ändamål
Ändamålet vad gäller aktörsuppgifter i GoS 1.0/MCP är att:
1. Hantera grunduppgifter för verksamhetsutövare och
Tillsynsmyndigheter/Handläggare. Hanteringen av aktörsuppgifter i denna version
görs inte direkt i ett administrationsgränssnitt för aktörsuppgifter enligt punkt 4 nedan
utan sker inbäddat i flödet ”Behörighetsperspektiv - användarscenario: Lägga upp
företagarkonto inkl. verksamhetskomplex första gången”. Se avsnitt 2.2.6 ovan
inklusive 2.2.6.1 Diariehantering.
Ändamålen vad gäller aktörsuppgifter efter GoS 1.0/MCP är att hantera:
2. Årlig Miljörapport.
3. Naturvårdsverkets rapportering till bl.a. EU, som sannolikt kommer att innehålla
aktörsuppgifter.
4. Administration av aktörer.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
17 (45)
4.1. Naturvårdsverket tillhandahåller (och finansierar) stödfunktionalitet avseende
aktörers behörighet (roll) och information (”visitkort”).
2.3.3. Administrera användare
Administration av användare inom IED och MCP direktivet 2018-12-20 release GoS
1.0/MCP innebär att:
1. Användaridentiteter för administratörer läggs upp och kopplas till aktuellt
verksamhetskonto med tillhörande uppgift samt roller.
2. Avveckling av administratörkonton handlar (minst) om att:
2.1. Stänga av administrativa användaridentiteter och alla de användaridentiteter som
ärver rättigheter via den administrativa användaridentiteten.
Administration av användare efter IED och MCP direktivet 2018-12-20 release GoS 1.0/MCP
innebär att avveckling av administratörkonton handlar om att:
2.2. Ta reda på om och vad som behöver bevaras i förhållande till den administrativa
användaridentiteten.
2.3. Ta bort all överskottsinformation (gallring).
Diagrammet visar identifierat behov av huvudsakliga administrationsflöden med ytterligare
uppdelning i delaktiviteter.
2.3.4. Användarscenario och aktiviteter.
Användarscenario som supportas inom IED och MCP direktivet 2018-12-20 release GoS
1.0/MCP:
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
18 (45)
(De utgråade elementen representerar fler användarscenarios som behöver supportas efter release GoS
1.0/MCP.)
2.3.4.1 Aktiviteter i samband med MCP underrättelse.
Lägga upp företagarkonto inklusive verksamhetskomplex första gången, se avsnitt 2.2.6
Behörighetsperspektiv - användarscenario: Lägga upp företagarkonto inkl.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
19 (45)
verksamhetskomplex första gången. som är en temporär lösning för GoS 1.0/MCP. I
framtiden är VUAdmin respektive Uppgiftslämnare två olika roller, en roll lämnar in
uppgifter och den andra rollen lägger upp i VU-konto. Detta ska kunna göras separat eller
ihop.
3. Juridiskt perspektiv
Se ”Lösningsbeskrivning MCP juridik v1.0”, [ref 3], för juridisk beskrivning av respektive
tjänst. Kommande avsnitt i detta kapitel syftar till att lyfta fram vad som levereras i GoS
1.0/MCP och behov av vidareutveckling i kommande releaser.
3.1. Underrättelse av anläggningsinformation
3.1.1. Utveckling kort och lång sikt
Aktiveten avser utveckla – kort sikt:
• En bastjänst för inlämnade uppgifter (BTIU), som utgör tillsynsmyndigheternas och
Naturvårdsverkets delade anvisade mottagningsställe för inkommande handlingar och
som stödjer lösningsmönstret för ”Utlämnande på medium för automatiserad
behandling”.
o Anvisat mottagningsställe=en funktion där den som tillhandahåller en
servicetjänst eller en bastjänst mottar handlingar, ankomstregistrerar dem och
sänder kvittens.
Aktiveten avser utveckla – längre sikt.
• När andra myndigheter har publicerat API:er att integrera mot kan en sammansatt
bastjänst för inlämnade uppgifter (SSBTIU) utvecklas. En sammansatt bastjänst som
möjliggör egen hämtning till eget utrymme av tidigare inlämnade uppgifter samt
initierar en diariehändelse om inkommen handling hos rätt tillsynsmyndighet eller vid
inlämning automatiskt skapar diariehändelse där olika ärendeidentiteterna matchas.
Bastjänst BTIU registrerar handlingens inkommandetidpunkt och lagrar inlämnade uppgifter
på strukturerad form (det formulär som använts för insamlingen) och en PDF-
sammanställning över inlämnande uppgifter. Används eUnderskrift vid inlämnandet lagras
den också. För avsteg från detta, se vidare avsnitt 3.1.4 Avsteg från BTIU målarkitektur.
Den sammansatta bastjänsten SSBTIU lagrar ingen information.
Både SSBTIU och BTIU ingår i den tekniska tjänst som Naturvårdsverket håller endast som
led i teknisk bearbetning eller lagring för tillsynsmyndigheternas räkning. Samtidigt är BTIU
mottagnings- och lagringsställe för inkommande handlingar till Naturvårdsverket där
lösningsmönstret matchar ”Utlämnande på medium för automatiserad behandling”.
Behörigheter separerar åtkomsten till handlingar så att Naturvårdsverket kommer åt
handlingar inkomma till Naturvårdsverket och respektive tillsynsmyndighet sina handlingar.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
20 (45)
3.1.2. Legalitetsprincipen
Naturvårdsverket erbjuder de nationella bastjänster BTSNA, BTAU, BTKL, BTIU och
SSBTSNA samt den nationella e-tjänsten som tekniska tjänster utifrån sitt särskilda ansvar
för att utveckla, följa upp och samordna arbetet med miljöinformationsförsörjning
(Förordning (2012:989) med instruktion för Naturvårdsverket) och är en följd av den
myndighetssamverkan på miljöområdet som pågått sedan 2014 inom ramen för IED-
programmet och sedan 2016 inom ramen för Naturvårdsverkets regeringsuppdrag Digitalt
Först – Smartare Miljöinformation. Naturvårdsverket ansvarar i egenskap av teknisk
tjänsteleverantör för att tillhandahålla det samlade tjänsteerbjudandet.
Förordning (2018:471) om medelstora förbränningsanläggningar (FMF) genomför
huvuddelen av direktiv 2015/2193/EU (MCP-direktivet) om begränsning av utsläpp till luft av
vissa föroreningar från medelstora förbränningsanläggningar. Direktivet innehåller krav för
utsläpp till luft av stoft, kväveoxider och svaveldioxid. Det finns också krav på registrering
och att medlemsstaterna ska föra ett register över alla medelstora förbränningsanläggningar.
FMF trädde i kraft den 1 juni 2018.
Enligt 18 § FMF ska den som driver eller avser att driva en medelstor förbränningsanläggning
informera tillsynsmyndigheten om anläggningen. Informationen ska lämnas i en e-tjänst som
tillsynsmyndigheten anvisar och
innehålla vissa uppgifter.
I Naturvårdsverkets rapport om förslag till genomförande av MCP-direktivet ingår att
Naturvårdsverket utvecklar och tillhandahåller en nationell e-tjänst och en nationell databas
där de inhämtade uppgifterna lagras för tillsynsmyndigheternas räkning. Databasen utgör den
gemensamma tekniska lösningen för de register över medelstora förbränningsanläggningar
som tillsynsmyndigheterna är skyldiga att föra.
Enligt 21 § FMF får en medelstor förbränningsanläggning inte vara i drift utan att vara
registrerad. Hur bestämmelsen tillämpas framgår av övergångsbestämmelserna.
Enligt 23 § FMF ska tillsynsmyndigheten offentliggöra uppgifter ur registret på en webbplats
som tillhör myndigheten och som allmänheten har tillgång till. Uppgifter om personnummer,
födelsedatum och bostadsadresser får dock inte offentliggöras.
3.1.3. Personuppgiftsansvar
Tillsynsmyndigheten, som bestämmer syfte och ändamål med hanteringen av
anläggningsuppgifter MCP, är personuppgiftsansvarig för information som samlas in via de
nationella e-tjänsterna och lagras i BTIU. Naturvårdsverket, som tillhandahåller en teknisk
tjänst, blir personuppgiftsbiträde åt Tillsynsmyndigheten.
3.1.4. Avsteg från BTIU målarkitektur.
3.1.4.1 Juridiskt lösningmönster
Då BTIU är en driftsatt tjänst har projektet utgått från att det juridiska lösningsmönstret är
beskrivet korrekt och att andra kvalitetsegenskaper är säkerställda i redan driftsatt lösning.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
21 (45)
3.1.4.2 Inga underskrifter
Då e-tjänsten GVU/MCP inte levererar stöd för underskrifter kommer följaktligen dessa inte
att lagras. MCPD ställer inte krav på e-underskrifter, men i kommande versioner av BTIU
behöver stöd för e-underskrifter utvecklas.
3.1.4.3 Strukturerad formulärdata.
Detsamma gäller även inlämnade uppgifter på (semi)strukturerad form (förutom PDF). Det
formulär som använts för insamling skickas inte med i form av XML-representation i GoS
1.0/MCP. BTIU sparar objekt och data i form av key-value-pairs. XML-representationen
kommer att behöva utvecklas i kommande versioner.
Notera1 att versionen (2.0) av BTIU som levereras i GoS 1.0/MCP stödjer lagring av XML
(och PDF).
Notera2 att kommande versioner för t.ex. inlämning av miljörapporter där det finns beroende
till gällande regelverk/lagar är det nödvändigt att skicka med formulär-XML för att kunna
hämta föregående års rapporter i sin helhet. Analyser under projektet pekar på att flödet och
mellanlager blir ett annat – asynkront via SHS-tjänsten.
3.1.4.4 Vidareförmedlingstjänst SSBTIU.
Åtkomst via GUI istället för tekniskt gränssnitt/API. Tjänsten för Plastbärkassar i förvaltning
anpassades till att även hantera inlämning av MCP-underrättelser.
*Notera: BTIU anropas av SSBTSNA och inte av SSBTIU. Se även utvecklingsbehov längre
sikt ovan.
3.2. Identitet och åtkomst
3.2.1. BTAU – release GoS 1.0/MCP
BTAU tillhandahålls av Naturvårdsverket för förvaring av handlingar endast som ett led i
teknisk bearbetning eller lagring för de operativa tillsynsmyndigheternas räkning.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
22 (45)
3.2.2. BTAU – utmaning framåt
Användningsfallet ovan, ”P5 Hantera administrativa konton”, påverkar lösningsmönstret i
release GoS 1.0/MCP, eftersom delade konton (konton för hela
verksamheten/organisationen/företaget) hanteras. Frågan är vilket juridiskt lösningsmönster
som gäller för delade konton.
Användaridentiteter för administratörer ska kunna läggas upp och kopplas till aktuellt
verksamhetskonto.
Likaså ska administratörskonton kunna avvecklas. Att avveckla administratörkonton handlar
(minst) om att:
- Stänga av administrativa användaridentiteter och alla de användaridentiteter som ärver
rättigheter via den administrativa användaridentiteten.
- Ta reda på om och vad som behöver bevaras i förhållande till den administrativa
användaridentiteten.
- Ta bort all överskottsinformation (gallring).
Aktörsuppgifter är antagligen två delar:
1. En ”stödtjänst” för teknisk funktionalitet med behörigheter, dvs drifts- och
säkerhetsrelaterad information.
2. Ett ”verksamhetssystem”, dvs nyttoinformation som används i ändamålen enligt avsnitt
2.3.2.
Hur ska detta diariehanteras? Jämför t.ex. med Skatteverkets tjänst för att ändra sitt personliga
bankkonto kopplat till skattekontot för utbetalning. Vem är informationsägare här? Ska
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
23 (45)
ändringen betraktas som en inkommen handling? Dvs, inkommen handling vid uppdatering
av inrapportörs uppgifter, inkl. kontaktinformation (visitkortsinformation)? Ändras uppgifter
frekvent blir det många inkomna handlingar.
Idag uppdaterar också Tillsynsmyndigheten kontaktuppgifter för verksamhetsutövaren. Hur
ska de få åtkomst till uppgifterna framdeles? Krävs separat överenskommelse/samtycke?
3.2.2.1 Rekommendation
Matcha juridiskt lösningsmönster för BTAU med ”Servicetjänst”/”Eget utrymme” som
beskrivs i ”Rättsliga förutsättningar för digitalt i första hand”, [ref 4] – se även avsnitt
3.2.2.2 nedan om ”Förstudie om kontaktuppgifter för privatpersoner – Mina
kontaktuppgifter”.
”Eget utrymme tillhandahålls som en service åt användaren. Ingen annan ska få insyn i det
material som användaren har där. Utrymmet ska samtidigt, genom stöd och service, såsom
förifyllnad, automatiska och logiska avstämningar, hjälptexter, etc. underlätta för användaren
att upprätta och ge in korrekta och fullständiga ansökningar, deklarationer och andra
handlingar. Det förekommer också utrymmen som ger stöd åt användare utan att något
skickas in till den som tillhandahåller utrymmet. Utkast och liknande handlingar förblir
användarens egna handlingar och blir inte att anse som allmänna enligt
tryckfrihetsförordningen eller inkomna enligt förvaltningslagen så länge de finns i utrymmet
och kriterierna för sådant utrymme är uppfyllda. Uppgifter som finns där ska inte heller
annars riskera att röjas genom åtgärder av myndigheten eller myndighetens personal. Genom
egna utrymmen skapas således en allmän tillit till elektroniska tjänster samtidigt som de
erbjuder en tillräcklig säkerhet för användaren och förenklar dennes vardag.”
Det innebär t.ex. att tillsyns- och/eller prövningsmyndigheter inte direkt ska hantera
verksamhetsutövarens aktörsuppgifter. De ska endast kunna hantera sina egna aktörsuppgifter
och uppgifter kopplade till anläggningen via maskin-maskin kommunikation. Notera att även
om tillsyns- och/eller prövningsmyndigheter inte direkt ska hantera verksamhetsutövarens
aktörsuppgifter kommer aktörsuppgifternas giltighet indirekt att hanteras, se även
beskrivningen i avsnitt 2.2.6 ovan.
Om BTAU är ett eget utrymme kan en framkomlig väg för myndigheterna att ändå få ta del
av uppgifter vara att företagarna/personerna i BTAU, ger sitt samtycke till att uppgifter
(främst kontaktuppgifter) får användas av myndigheterna i situationer då myndigheter
behöver ha korrekta roll- och kontakt-uppgifter för att de ska kunna fullgöra sina respektive
åtaganden gällande företagen.
Rättsfiguren (kombinationen av rättsregler, händelser och fakta) för delar av aktöruppgifter
kan liknas vid ett serviceskede, dvs. ett skyddat förlopp där en användare hanterar uppgifter
för att service ska kunna ges enligt förvaltningslagen. Ingen utomstående avses då ha insyn
(notera utan samtycke) i de uppgifter som behandlas och det sker inte heller någon
ärendehandläggning.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
24 (45)
Om aktörer är (och kan vara?) informationsägare i analogi med ”eget utrymme” (se även
”Checklistetest för BTAU infoägarskap”, [ref 12],) skulle en framkomlig väg kunna vara
endast uttag med stöd av ”Utlämnande på medium för automatiserad behandling” inkl.
samtycke enligt ovan även om det är konflikt med beskrivningen i avsnitt 3.2.2.6?
3.2.2.2 ”Förstudie om kontaktuppgifter för privatpersoner – Mina kontaktuppgifter”?
Se förstudie ”Förstudie om kontaktuppgifter för privatpersoner – Mina kontaktuppgifter”,
[ref. 6]. Där nämns ”Rättsliga förutsättningar för genomförande” och ”Modell kring eget
utrymme för privatpersonens egen administration av kontaktuppgifter.” Från slutsatsen
hämtas följande citat. ”Den juridiska analys som utförts under förstudien har inte kunnat
påvisa tillvägagångssätt som med stor sannolikhet inte skulle medföra risk för
offentliggörande. Det verkar här som lagstiftningen på ett paradoxalt sätt försvårar eller
kanske till och med omöjliggör införandet av en frivillig delningstjänst för kontaktuppgifter.”
Vi avvaktar därefter behov av bättre juridiska förutsättningar/lagändring – bevaka/förbereda
2018-2020, se [ref. 7].
I ett nyläge kunde BTAU spegla beskrivningarna i förstudierapportens avsnitt 5.5.2.b där det
beskrivs: ”Ett alternativ skulle kunna vara att använda eget utrymme för en individs
kontaktuppgifter. I så fall måste emellertid individen sannolikt själv lämna ut uppgifterna ur
utrymmet för att innehållet inte ska bli allmän handling. Tjänstekonsumenterna använder
delningstjänsten på ett sådant sätt att det krävs svar direkt, utan att en reaktion från den
registrerade individen kan avvaktas. Det är idag ännu inte prövat i domstol om individens
utlämnande av uppgifter från Eget utrymme får ske genom automatiserad behandling av
regler som den enskilde upprättat och förvarar i tjänsten.” Dessa regler skulle kunna vara
samtycke med tillhörande beskrivande texter i e-tjänster.
3.2.2.3 Rättspraxis
Se ”Eget utrymme är numer accepterat i lagmotiv – men vilka juridiska krav ställs på eget
utrymme?”, [ref 1], där följande text återfinns.” I propositionen (2016/17:198 s. 16) har
regeringen anfört att det finns stöd i praxis för att myndigheter tillhandahåller digitala tjänster
som uppfyller kraven i 2 kap. 10 § första stycket TF. Regeringen har därvid hänvisat till RÅ
1994 ref. 64 och HFD 2011 ref. 52 samt förklarat att myndigheternas möjlighet att själva
besluta om utformningen av sina tjänster innebär att de kommer att kunna utveckla och
anpassa sina tjänster efter eventuell ytterligare rättspraxis.
Samtidigt har regeringen noterat att det inte finns vägledande avgöranden som ger tydligt
besked, i fråga om vilka av de egna utrymmen som myndigheter tillhandahåller, som uppfyller
kraven enligt 2 kap. 10 § första stycket TF. Regeringen har emellertid hänvisat till en dom den
26 oktober 2015 av Kammarrätten i Stockholm (mål nr 7369-15) där handlingar som förvarats
i en CV-databas hos Arbetsförmedlingen, ansetts vara förvarade hos myndigheten endast som
led i teknisk bearbetning eller teknisk lagring för annans räkning.”
Som ytterligare exempel på att juridiken här har brister, se även ”Juridik som stöd för
förvaltningens digitalisering”, [ref. 8], där följande text återfinns ” Exempel: De ärendeslag
som hanteras inom en och samma myndighet kan spänna över ett stort och mångfacetterat
område. Om personuppgifter som enskilda lämnat till myndigheten inom ramen för ett
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
25 (45)
ärendeslag ska kunna behandlas inom ramen för ett annat ärendeslag behöver det finnas
rättsligt stöd i dataskyddsregleringen för behandlingen för det nya ändamålet.”
3.2.2.4 Frågor att beakta
Vilken information avseende åtkomst är eventuellt nyttoinformation och behovet av en
mottagningsfunktion:
1. Det är svårt att påvisa att objektet "Representationsuppdrag" i BTAU, som innehåller
uppgifter om hur företagarna delegerar sina uppgifter mot myndigheterna, är en
information som myndigheterna har behov av. I olika situationer är naturligtvis
kontaktuppgifter av intresse, men de skulle kunna inhämtas från andra håll.
2. En annan oklar frågeställning är till vilken myndighet åtkomstuppgifterna ska inkomma.
Samma persons kontaktuppgifter kan ju t. ex. relateras till flera anläggningar i olika
län/kommuner. Till vilket län/kommun ska uppgifterna då inkomma?
3. Delegering av uppgifter är något myndigheterna inte bör ha något att göra med.
Delegeringen bör därför sannolikt inte ses som en inkommen handling till myndighet där
myndigheten måste ta beslut om delegeringen är korrekt, varken manuellt eller
automatiskt.
3.2.2.5 Personuppgiftsansvar
Från ”Verksamhetsutveckling inom e-förvaltning 3.0”, [ref 2], hämtas följande text.
”Sammanfattning: De aktörer som berörs av it-baserade tjänster och tillhörande kanaler för
att nå egna utrymmen eller transportkanaler för att ge in handlingar behöver klargöra mellan
sig vem eller vilka som har personuppgiftsansvaret för respektive del och vad ansvaret
innebär i olika avseenden, bl.a. säkerhetsmässigt och när underleverantörer anlitas”.
Om en tjänst kan bygga på att samtycke ges för personuppgiftsbehandling eller för att
sekretessreglerade uppgifter ska få lämnas ut måste rutinerna för samtycke utformas så att
giltiga samtycken uppkommer.
Vidare från [ref 2].”Att särskilt observera: En myndighet som tillhandahåller eget utrymme
åt enskilda bör införa sådana tydliga förbud för befattningshavare mot att ta del av eller annars
använda innehållet i enskilds eget utrymme att den som bryter mot förbudet gör sig skyldig
till dataintrång.”
”Det kan emellertid också behövas ett skydd för material som blir tillgängligt för den som
arbetar med utveckling och drift av egna utrymmen så att han eller hon inte får röja uppgifter
som finns i ett sådant utrymme. I verksamhet för enbart teknisk bearbetning eller teknisk
lagring för någon annans räkning gäller också en bestämmelse om förbud mot att lämna ut
handlingar och om tystnadsplikt för befattningshavare (40 kap. 5 § OSL). Skyddet gäller
visserligen bara för uppgift om en enskilds personliga eller ekonomiska förhållanden men det
är från år 2018 inte längre begränsat till personuppgifter – även t.ex. företagsuppgifter
skyddas (se prop. 2016/17:198).” Här betraktar projekten det som beställning ur
Naturvårdsverkets servicekatalog och är redan reglerat.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
26 (45)
3.2.2.6 BTAU, BTIU, BTSNA
Se ”Lösningsbeskrivning_MCP_juridik_v1.0”, [ref 3], för beskrivning av bl. a.
personuppgiftsansvaret. Tillsynsmyndigheten, som bestämmer syfte och ändamål med
hanteringen av anläggningsuppgifter MCP, är personuppgiftsansvarig och att
Naturvårdsverket som tillhandahållare av en teknisk tjänst blir personuppgiftsbiträde åt
Tillsynsmyndigheten.
4. Informationsperspektiv
Övergripande informationsmodell med fokus på ”anläggning”:
(Notera: svenska begrepp visas – detta gäller informationsmodeller, för datamodeller ska svenska vara ”alias” då engelska termer matchande Inspire används som r egel.)
4.1. Övergripande beskrivning
Bastjänsterna är informationskällor som innehåller uppgifter inom ett antal områden:
anläggningar, aktörer, och koder. En bastjänst innehåller en databas samt viss logik bl.a. för
anrop och valideringar. Tjänsterna anropas med fråga-svarstyp maskin-till-maskin där
uppgifter om anläggningar med tillhörande kodlistor och aktörsuppgifter kan efterfrågas samt
uppdateras av behörig användare för tjänsten.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
27 (45)
För att underlätta användning av bastjänsterna finns en sammansatt bastjänst etablerad. Den
sammansatta bastjänsten har logik för att anropa flera bastjänster, och hålla ihop transaktioner
så att alla delar genomförs eller rullas tillbaka vid fel – detaljerad beskrivning i
”Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA”, [ref 14]. Den sammansatta
bastjänsten exponeras utåt så att olika kategorier av användare, även utanför Naturvårdsverket
kan använda den. De enskilda bastjänsterna exponeras enbart via den sammansatta
bastjänsten, alternativt genom andra sammansatta bastjänster som kan tillkomma i framtiden.
4.2. Hantering av versioner och historiska data
Bastjänsterna ska innehålla historiska data. Det ska vara möjligt att hämta de uppgifter som
gäller/gällde vid en viss tidpunkt i dåtid, nutid och i viss mån även framtid med data som lagts
in i förväg.
Databasen är uppbyggd så att inlagda instanser av respektive objekt aldrig tas bort vid
förändringar. De ersätts istället av nya instanser, vilket möjliggör hämtning av historiska data
och också att i förväg lagra kommande förändringar. Vid arbete med data behövs då tydliga
sökkriterier som alltid returnerar rätt instans av ett objekt, eftersom det kan finnas flera
instanser lagrade. Följande kriterier styr att rätt instans returneras:
• Start- och end date anger inom vilket tidsintervall en instans av ett objekt är gällande.
Det finns alltid bara en instans av objektet som gäller vid varje tidpunkt.
• Uppgiftsstatus anger den inlämnade uppgiftens läge i processen. Den kan vara
inkommen, granskad eller borttagen. Borttagen uppgift visas normalt inte i sökningar.
• Teknisk status anger i vilket tillstånd utrustningen och platsen är vid en viss tidpunkt,
men påverkar inte vilka objekt som hämtas vid en sökning, om man inte specifikt
väljer att ange kriterier för teknisk status.
• Legal status finns också på vissa objekt, men påverkar inte vilka objekt som hämtas
vid en sökning.
För de fysiska objekten verksamhetskomplex, anläggningsplats, installation och
installationsdel är den instans där efterfrågat datum ligger mellan start och end-date den som
hämtas vid utsökningar. Om instansen gäller tills vidare är inte end-date satt. Data som lagras
i andra tabeller - som status, geografi, och koder - ska kopplas till instansen. Det betyder att
man måste ha med alla uppgifter som ska gälla i anropet som skapar den nya instansen.
Geografi, adress och koder som kopplats till tidigare instanser gäller inte längre. De måste
vara med i anropet även om uppgiften i sig är oförändrad.
4.3. Beskrivning Bastjänst för anläggningsuppgifter (BTSNA)
4.3.1. Syfte
BTSNA är en bastjänst som innehåller uppgifter om anläggningar och tekniska installationer
som är involverade i miljöfarlig verksamhet.
4.3.2. Funktion
BTSNA har information om anläggningar i flera nivåer: Verksamhetskomplex,
Anläggningsplats, Installation och Installationsdel. Alla lagrade objekt får unika ID. De får
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
28 (45)
dels ett ObjektID och dels får objekt av ovanstående typ dessutom ett Inspire-ID som används
vid rapportering till EU samt vid publicering av geodata. Detta ger möjlighet att koppla
beskrivande information till rätt nivå i modellen.
Den beskrivande information som anges på respektive nivå är geodata, adresser,
administrativa uppgifter och miljörelaterade koder av olika slag. Installationsdel är olika
bestyckat med attribut beroende på vilken typ av installationsdel det är. Pannor och
utsläppspunkter av olika slag har en grunduppsättning av information, men utöver detta har
t.ex. MCP-pannor ett tiotal attribut som är specifika för denna typ av installationsdel.
Verksamhetskomplex, installation och anläggningsplats är däremot i stort sett helt generella.
4.3.3. Beskrivning av databasmodell
4.4. Beskrivning Bastjänst för aktörsuppgifter (BTAU)
4.4.1. Syfte
BTAU är en bastjänst som innehåller uppgifter om de organisationer och företag (aktörer) och
personer som är involverade i tjänster som erbjuds. En persons eller aktörs uppdrag definierar
vilken roll denne har och förhållandet till andra objekt. Ett representationsuppdrag kan
innehålla rättigheter att behandla data i någon eller några tjänster, men det måste inte vara så
(se t.ex. uppdraget ”Kontaktperson”).
4.4.2. Funktion
För att förstå hur BTAU är tänkt att användas är funktionen beskriven i form av “User
stories”. Det finns tre typer av representationsuppdrag:
Aktörsuppdrag
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
29 (45)
En aktör är en juridisk person som verkar i relation till verksamhetskomplex (eller annat
objekt).
User story:
Som aktör ska jag kunna ha uppdrag i förhållande till ett eller flera verksamhetskomplex för
att avspegla ansvarsförhållanden.
Acceptanskriterier:
Varje verksamhetskomplex ska ha en aktör med rollen verksamhetsutövare och en aktör med
rollen tillsynsmyndighet kopplade till sig.
Exempel:
SSAB (aktör) är verksamhetsutövare för Oxelösunds stålverk (verksamhetskomplex), och
Länsstyrelsen Södermanlands län (aktör) är tillsynsmyndighet.
Personuppdrag
En person (fysisk) kan ha uppdrag gentemot ett verksamhetskomplex.
User story:
Som person vill jag kunna ha uppdrag i förhållande till ett eller flera verksamhetskomplex så
att det framgår vem som har ansvar för olika uppgifter.
Acceptanskriterier:
När man hämtar information om en anläggning ska det framgå vem som är kontaktperson.
En person som har behörighet som uppgiftslämnare ska kunna rapportera för ett
verksamhetskomplex.
Exempel:
Peter Persson (person) är uppgiftslämnare för Oxelösunds stålverk och har rättighet att
rapportera för detta verksamhetskomplex.
Administrationsuppdrag
En fysisk person kan ha i uppdrag att administrera en aktör. (För att arbeta i den typen av
uppdrag krävs att det finns en e-tjänst för administration av aktörer, vilket inte ingår i GoS
1.0/MCP-releasen).
User story:
Som person med administratörsroll vill jag kunna administrera alla uppdrag som gäller en viss
aktör så att självservice uppnås, och myndigheter slipper en onödig administrativ börda.
Acceptanskriterier:
Det ska alltid finnas minst ett administratörsuppdrag kopplat till varje aktör.
Administratören kan administrera uppdrag av alla slag som kopplade till aktuell aktör.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
30 (45)
Administratören kan även lägga upp en annan administratör om han vill lämna över sin
administratörsroll.
Administratören kan inte ändra sin egen roll. Det måste någon annan administratör göra.
Exempel:
Det är Hugo Bylund som är administratör för SSAB, och är den som har lagt upp Peter
Persson som uppgiftslämnare för Oxelösunds stålverk. Han kan vid behov lägga upp en ny
uppgiftslämnare parallellt med Peter och om han så önskar avsluta Peters uppdrag.
4.4.3. Vid förändringar i data
Uppgifter i andra bastjänster, t.ex. uppgifter om verksamhetskomplex i BTSNA ska kunna
ändras utan att uppgifter i BTAU berörs.
Om uppgifter i något objekt i BTAU ändras ska kopplingarna mellan objekt i BTAU och
kopplingar till objekt i andra bastjänster, t.ex. BTSNA bibehållas.
4.4.4. Beskrivning av databasmodell
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
31 (45)
4.4.5. Beskrivning av anrop
Se dokumentet ”Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA”, [ref 14].
4.5. Beskrivning Bastjänst för Kodlistor (BTKL)
4.5.1. Syfte
BTKL är en bastjänst som innehåller kodlistor av olika typ som ska kunna användas av olika
formulär. BTKL är utformad för att kunna hantera förändringar i kodlistors innehåll över tid.
Det ska vara möjligt att retroaktivt arbeta med formulär som har gällt tidigare och i dessa ska
de kodlistevärden som gällde då formuläret var aktuellt presenteras.
4.5.2. Funktion
BTKL har skapats utifrån följande funktionella krav:
1. BTKL ska innehålla de kodlistor som är generella och används i flera tjänster.
2. Som administratör ska jag kunna lägga till nya kodlistor, inklusive de värden som ska
gälla.
3. Som administratör ska jag kunna lägga till nya värden som gäller från ett visst datum i
en befintlig lista.
4. Som administratör ska jag kunna ta bort ett värde ur en lista from ett visst datum.
5. Som uppgiftslämnare ska jag kunna hämta olika versioner av en kodlista med hjälp av
att ange kodlistans ID alternativt namn, samt datum, så att t.ex. en listruta i ett
formulär som gäller för fjolåret innehåller de värden som gällde då.
6. Som uppgiftslämnare ska jag kunna hämta ett värdes benämning på engelska.
7. Som uppgiftslämnare ska jag kunna hämta ett värdes alternativa benämning på
svenska.
8. Som uppgiftslämnare ska jag kunna hämta ett värdes beskrivande text.
9. Som uppgiftslämnare ska jag kunna hämta kodlistor med flera nivåer, t.ex. för län som
har kommuner som underindelning. Om län är valt ska endast kommuner inom valt
län vara valbara.
10. (Krav som tillkommit, och ännu inte realiserats. En kodlista ska endast kunna
administreras av en utpekad ägare och en övergripande systemadministratör.)
4.5.3. Datamodell för kodlistor
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
32 (45)
Det är möjligt att välja ut en kodlista, hämta alla de värden som är gällande och visa dem som
valbara alternativ i ett formulär.
Om kodlistan har flera nivåer kan man välja ut värden som är sorterade under ett visst värde
som valts (tabellen värderelation ovan), t.ex. alla kommuner som är sorterade under ett län.
4.6. Beskrivning av sammansatt bastjänst (SSBTSNA)
4.6.1. Övergripande beskrivning
Sammansatt bastjänst för samlade nationella anläggningsuppgifter (SSBTSNA) innehåller ett
sammanhållet API för åtkomst till data i bastjänsterna. SSBTSNA håller samman
transaktioner så att alla delar genomförs eller rullas tillbaka vid fel. SSBTSNA döljer viss
funktionalitet för anropande part. T.ex. kan ett uppdrag skapas genom ett anrop, men i
realiteten krävs att det sker kontroll att berörd person eller aktör finns i BTAU, annars skapas
personen eller aktören, och först när dess objekt-ID har returnerats skapas själva uppdraget.
Här sker även loggning av transaktioner – detaljerad beskrivning i ”Tjänstebeskrivning Bilaga
API-beskrivning SSBTSNA”, [ref 14].
Förutom åtkomst till bastjänsterna BTSNA, BTAU, och BTKL kan Bastjänst för inlämnade
uppgifter (BTIU) anropas. BTIU är en befintlig tjänst som hanterar inkommande uppgifter
från andra e-tjänster, men har anpassats något för att kunna hantera även MCP-underrättelse
och registrering.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
33 (45)
4.6.2. Funktion
SSBTSNA tar emot anrop via sitt API. Tjänsten anropar i sin tur de berörda bastjänsterna. I
vissa fall vidarebefordras inkommande anrop, och i andra fall krävs flera anrop till
underliggande bastjänster för att åstadkomma efterfrågad funktion. Tjänsten svarar via API
om anropet har lyckats eller ej. Om anropet har misslyckats återställer SSBTSNA alla
påbörjade bastjänstanrop. Anrop loggas.
4.6.3. Omgivning
I huvudsak ska SSBTSNA anropas från e-tjänster och handläggarsystem internt och externt
Naturvårdsverket. SSBTSNA ska i sin tur kommunicera med bastjänster.
I dagsläget finns ett undantag, som antas vara tillfälligt. BTIU får idag svar från
tillsynsmyndigheter som kan leda till att status för anläggningar i BTSNA ska ändras. I
nuläget anropar BTIU SSBTSNA för att åstadkomma detta. Detta är ett avsteg från
arkitekturen, som förväntas återställas i och med att tillsynsmyndigheternas handläggarsystem
börjar anropa via API.
4.6.4. Beskrivning av datamodell
Datamodell för API beskrivs i Tjänstebeskrivning SSBTSNA, och Kontraktdokumentation
SSBTSNA, [ref 14].
4.6.5. Beskrivning av anrop
Anrop och svar beskrivs i Tjänstebeskrivning SSBTSNA, [ref 14].
4.6.6. Beskrivning av integrationer till andra applikationer
Bastjänsterna är passiva komponenter i en arkitektur där andra system och komponenter ska
kunna läsa och uppdatera bastjänsternas data med hjälp av API-anrop.
4.7. Kontrakt
Se Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA, [ref 14].
5. Tekniskt perspektiv
Syftet med detta kapitel är förutom det tekniska perspektivet av projektstatus och arkitektur
att matcha Obligatoriska artefakter vid milstolpar och ”Avsteg från teknikstrategi med
motiveringar”. I avsaknad av aktuell teknikstrategi antas att beskrivningarna här matchar
följande citat från IT Strategi: "Utveckla och tillgängliggör en ändamålsenlig arkitektur för
digital samverkan inom miljösverige" samt "Använd arkitekturstyrning och löst kopplade
komponenter för återanvändning och effektiv utveckling". Nedan följer det tekniska
perspektivet och hur det är konstruerat.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
34 (45)
5.1. Arkitektur för tillgängliggörande – AFT
5.1.1. Hur hänger alla "e-tjänster" och bastjänster (BT/SSBT) ihop?
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
35 (45)
5.1.2. GVU-MCP koncept och målbild
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
36 (45)
För detaljerade beskrivningar rekommenderas bl.a. dokumentet ”Funktionsbeskrivning_steg
P”, [ref 17].
5.2. Koncept tillfällig lösning åtkomst och behörighet – GoS 1.0/MCP-release.
En NV-ägd IdP har ännu inte realiserats. I den tillfälliga lösningen gör istället e-
tjänsten/sammansatt bastjänst ett extra anrop mot Aktörs-tjänsten för att läsa upp rollerna och
lagra dem i ett eget ”user”-objekt. Det innebär att e-tjänsten gör behörighetsdelar av IdP-
jobbet men utanför SAML.
Det är steg nr 4 ovan som istället för SAML-transport/paketering använder ”vanlig”
SOAP/XML där personnr är attribut/parametrar. Det som förloras är delad tillit/SSO, men i
vårt fall innebär det inga extra inloggningar och så länge alla bokomliggande system är i
Naturvårdsverkets kontroll kan tjänsteanropen göras pålitligt. Trafiken är skyddad med
SSL/TLS.
5.2.1. Tillfällig API-säkerhetslösning
För AFT bör API-säkerheten definieras för att säkerställa tillit, i sin enklaste form API-
nycklar. Det arbetet återstår, eftersom det prioriterades bort p g a tidsbrist. Lösningen ”IP
låsning med SSL/TLS”, bedömdes vara acceptabel.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
37 (45)
5.3. E-tjänstens integration med extern part – SSBTGU samt Navet
Se konceptuellt diagram i avsnitt 5.2 ovan.
5.3.1. Navet
E-tjänsten GVU/MCP anropar Navet via webserviceanrop och kommunikation mellan
parterna i infrastrukturen krypteras med hjälp av TLS/HTTPS med domäncertifikat utfärdat
av en betrodd certifikatutfärdare.
För informationer om Navet, se Skatteverket och ”Navet – hämta uppgifter om
folkbokföring”.
5.3.2. SSBTGU
E-tjänsten GVU/MCP anropar SSBGTU via CGI:s konsumentadapter. Kommunikation
mellan parterna i infrastrukturen krypteras med hjälp av TLS/HTTPS med domäncertifikat
utfärdat av en betrodd certifikatutfärdare. Konsumentanslutningen autentiseras med hjälp av
organisationscertifikat utfärdat av betrodd certifikatutfärdare. Organisationscertifikatet, som
används även för SHS och koppling till Navet, uppdateras av CGI vid behov.
E-tjänsten GVU/MCP anropar SNA-tjänsterna. I anropen skickas Personnummer med.
För informationer om SSBTGU se Bolagsverket och t.ex. ”Anslutningsguide för it-
leverantörer”.
5.4. Översikt lösning BTIU Bastjänst samt BTIU Webb
Generellt tillåts ingen applikation direktåtkomst till bastjänsten BTIU och all kommunikation
sker krypterat över HTTPS/SSL.
*Notera: används även för ”Plastbärkasselösningen” hos Naturvårdsverket.
BTIU API
API:t är exponerat som en SOAP/XML tjänst. BTIU tjänsten är nedlåst och kan bara anropas
från SSBSTNA, EF1 tjänsten* och från Naturvårdsverkets interna nät. Tidigare version av
BTIU tjänsten har anpassats för att ta hänsyn till nya roller och behörigheter, se avsnitt 5.4.1.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
38 (45)
Webb GUI
Webben består av en ASP.NET MVC applikation som idag bara används internt av
Naturvårdsverkets supportfunktion. Inför GoS 1.0/MCP-releasen anpassades GUI:t att
hantera olika behörigheter och anropen mot BTIU- tjänsten nyttjar nu
auktoriseringsfunktioner så att rätt information visas för rätt roll. Webb-delen har
kompletterats med funktioner för SNA.
USER DB
En vanlig Asp.Net Membership databas, med username/Epost + Lösenord och Roll. Tidigare
var det bara ”Plastpåsehandläggare” i detta system. För GoS 1.0/MCP-releasen har rollerna
byggts ut så att det nu går att lägga in såväl Naturvårdsverkets supportpersonal som användare
på tillsynsmyndigheter vid behov.
BTIU DB
En enkel SQL Server databas där vi kan spara ner JSON objekt i key-value pairs och rena
binärobjekt så som en fil (pdf, word, bild m.m.).
Alla objekt har ett antal metadata-attribut för att beskriva dem. Objekten har också en
tillhörighet som kan användas vid behörighetsfiltrering.
5.4.1. Förändringar av realiserad lösning för åtkomst och behörighet – BTIU – temporär
lösning för GoS 1.0/MCP-release
För systemdokumentation se ”BTIU Kontraktdokument”, [ref 15] och ”BTIU
Systemdokumentation”, [ref 16].
Behörighetskonfigurationer lagras internt i BTIU (tabell/roll), vanliga username + password
lagras i en databas för sök-btiu-webben.(Notera att det är ett avsteg från AFT där BTAU är
den tänkta platsen för behörighetskonfiguration för utpekade aktörer, dvs
Tillsynsmyndigheterna i det här fallet). Rollerna är lokala för lösningen, som valdes p g a
tidsbrist.
5.5. Tjänstebeskrivning Teknisk dokumentation SNA
Se dokumentet ”Tjänstebeskrivning Teknisk Systemdokumentation SNA”, [ref 13].
5.6. Informationsutbytesflöden och metoder
Se även dokumentet ”Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA”, [ref 14].
5.6.1. Användningsfallsrealisering: Registrera anläggningsuppgifter i SNA
Sekvensdiagrammet nedan visar översiktligt meddelandeflödet mellan de
komponenter/bastjänster som samverkar för att realisera registrering av anläggningsuppgifter.
Klassdiagrammet visar vilka komponenter/bastjänster som medverkar i realiseringen, samt
hur dessa är sinsemellan relaterade
SW E D I SH E N V IR O N M EN T A L P R OT E C T IO N AG E NC Y
Miljöinformationsenheten (Mi)
2019-08-22 Ärendenr:
NV-02644-17
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
40 (45)
Figur 1: Sekvensdiagram för realisering av användningsfallet Registrera anläggningsuppgifter i SNA.
SW E D I SH E N V IR O N M EN T A L P R OT E C T IO N AG E NC Y
Miljöinformationsenheten (Mi)
2019-08-22 Ärendenr:
NV-02644-17
Figur 2: Klassdiagram för realisering av användningsfallet Registrera anläggningsuppgifter i
SNA.
5.6.2. Registrera anläggningsuppgifter i SNA - detaljering
I Figur 1 beskrivs mer i detalj kommunikationen mellan en klient och SSBTSNA.
Sekvensdiagrammet illustrerar vilken typ av metoder som bör användas för att realisera olika
verksamhetshetskrav på klientsidan. Det finns fler metoder än de som visas i diagrammen.
Diagrammen skall verka som best practice för alla aktörer som vill utbyta information med
SNA-systemet.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
42 (45)
Figur 2: Kommunikation mellan klient, t.ex. GVU, och SSBTSNA vid registrering av
anläggningsuppgifter.
Nedan beskrivs ett typexempel på hur kommunikationen bör ske mellan en SNA-klient och
den yttre tjänsten för SNA, CompositeService (SSBTSNA), när en anläggning ska registreras
för första gången.
Flödet kan beskrivas enligt:
• Inloggning
o 1. I klienten antas det ske någon typ av autentisering av slutanvändaren,
exempelvis med bankId.
o 2. Klienten frågar SNA om personen existerar i SNA.
o 3. Om klienten finns registrerad, vilket vi antar här, hämtas Person-objektet till
klienten och eventuella personuppgifter kan presenteras.
• Populering av drop-down-listor
o 1. Slutanvändaren väljer att registrera nya anläggningsuppgifter.
o 2. Klienten hämtar olika kodlistor för att bistå slutanvändaren i deras val
genom att populera drop-down-listor, som t.ex listor för:
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
43 (45)
▪ BTKL_BranchCode_Maingroup
▪ BTKL_monitoring_authorities (Innehållande tillsynsmyndigheter)
▪ BTKL_Installation_Type
▪ BTKL_MCP_type
▪ Etc.
o 3. Efter steg 2 kan nu slutanvändaren göra sina val och minst ange obligatorisk
information samt ange viss information i tillhörande inmatningsfält. Här
registrerar slutanvändaren kontaktperson och anläggningsuppgifter inklusive
uppgifter om installationer och installationsdelar, väljer tillsynsmyndighet och
verksamhetsutövare.
• Validering av inmatningsfält – I det här steget skickas all anläggningsinformation
klienten har samlat upp från slutanvändaren till SNA-systemet. Vidare gör klienten
anrop till SNA för att skapa upp personer och aktörer som inte redan existerar i
BTAU-databasen. SNA validerar nu all information via CompositeService.
Valideringen innebär att en verifiera att obligatoriska parametrar har skickats med
samt att personer och aktörer som återanvänds existerar i BTAU-databasen.
• Skapa objekt – Om valideringarna är ok i föregående steg, kommer objekt att skapas
upp i SNA-systemet, anläggningsuppgifter i BTSNA-databasen och person- samt
aktörsuppgifter i BTAU-databasen.
• Skapa uppdrag och rapportera till BTIU – I sista steget skapar CompositeService
upp fyra uppdrag, se avsnitt Fel! Hittar inte referenskälla., som är knutna till a
nläggningen som registreringen gäller för. CompositeService skickar sedan vidare en
sammanställning av de registrerade uppgifterna från klienten till BTIU, för att berörda
personer skall få notiser i form av mailutskick om att ändringar har skett.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
44 (45)
5.6.3. Uppdatera befintliga anläggningsuppgifter i SNA
Figur 3: Kommunikation mellan klient, t.ex. GVU, och SSBTSNA vid uppdatering av
anläggningsuppgifter.
Här beskrivs uppdatering av befintliga anläggningsuppgifter. Endast skillnader relativt
huvudflödet i Figur 2, där anläggningsuppgifter skapas för första gången, tas upp.
Avvikelserna kan beskrivas i följande punktlista:
• Inloggning & Hämta uppdrag – I det här steget sker även hämtning av
slutanvändarens uppdrag, som denna är knuten mot, vilket görs genom att klienten
anropar GetPersonalAssignments,
• Populera drop-down-listor – I samband med att slutanvändaren har valt ett specifikt
uppdrag som är knutet till en specifik anläggning i föregående steg, kan klienten nu
hämta all anläggningsinformation samt person- och aktörsinformation genom att
använda metoden GetActorsAndPersonsByFacilityId, se avsnitt.
• Uppdatera objekt – I det här steget används en update-metod istället för create. Det
är viktigt att klienten i det här steget sätter objectId korrekt på alla objekt som
existerar sedan tidigare. Detta för att SNA inte ska tappa historiken,
versionshanteringen.
Projekt
Naturvårdsverket Dokumentnamn
Arkitekturspecifikation GoS
Skapat av
Miljöinformationsenheten (Mi)
Godkänt av
Miljöinformationsenheten (Mi) Version
1.2
Sparat
2019-08-21
Sida
45 (45)
• Rapportera till BTIU – Eftersom SNA redan har alla anläggningsuppgifter, uppdrag
samt person- och aktörsuppgifter sparat i databaserna, räcker det nu att klienten
skickar med pdf:en och anger vilken anläggning som är uppdaterad.
6. Dokumenthistorik
Version Datum Författare Huvudsakliga ändringar och kommentarer
<1.0 Löpande Projekten
GVU, SNA
Första arkitektspecifikation (SAD)
GoS 1.0
1.0 2019-01-24 Projekten
GVU, SNA
Granskad och justerad enligt
”Granskningsprotokoll
Arkitekturspecifikation GoS 1.0”
(finns i Modena, ärende NV-02644-
17) inkl. Tomas Strands och Tomas
Sundins uppdateringar samt
mailkonversation ”Från: Norén, Michael Skickat: den 3
januari 2019 14:31” och ”Ämne: RE: EA granskningsmöte
Arkitektspecifikation GoS
1.0”.
1.01 2019-02-24 PL SNA Språklig uppdatering av dokumentet
efter överenskommelse med EA.
1.2 2019-06-13 Jan Widegren
(EA)
Lagt till sekvens- och klassdiagram
för MCP-flödet i avsnitt 5.6.
1.2 2019-08-21 Sofie Lindblad Lade till försättsblad och sidhuvud i
enlighet med övrig dokumentation.