Arkitekturspecifikation GoS version 1 · 2019. 8. 22. · Projekt Naturvårdsverket Dokumentnamn...

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)

[email protected]

2019-08-22 Ärendenr:

NV-02644-17

Arkitekturspecifikation GoS Version 1.2

Kallonen, Kim [Datum]

Projekt

Naturvårdsverket Dokumentnamn

Arkitekturspecifikation GoS

Skapat av


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



Skapat av


Godkänt av


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

http://enos:8080/webspace/getdocument/document?id=117717006

Projekt



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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

http://www.esamverka.se/download/18.1dbd59341602b7503f15b65a/1513071420258/PM_Eget%20utrymme_november%202017.pdf



http://esamverka.se/download/18.38902f9b1636d04cc5845390/1526900634902/PENS0054_E-sam_Jur.verksamhetsutv_Final.pdf

http://esamverka.se/download/18.38902f9b1636d04cc5845390/1526900634902/PENS0054_E-sam_Jur.verksamhetsutv_Final.pdf

http://www.esamverka.se/download/18.5c941007162f6338fa536a9b/1524828770326/V%C3%A4gledning_R%C3%A4ttsliga%20f%C3%B6ruts%C3%A4ttningar%20f%C3%B6r%20digitalt%20i%20f%C3%B6rsta%20hand.pdf

http://www.esamverka.se/download/18.5c941007162f6338fa536a9b/1524828770326/V%C3%A4gledning_R%C3%A4ttsliga%20f%C3%B6ruts%C3%A4ttningar%20f%C3%B6r%20digitalt%20i%20f%C3%B6rsta%20hand.pdf

https://www.inera.se/globalassets/projekt/infratsruktur-for-identitets-och-atkomsthantering/referensarkitektur_identitet_och_atkomst.pdf

https://www.inera.se/globalassets/projekt/infratsruktur-for-identitets-och-atkomsthantering/referensarkitektur_identitet_och_atkomst.pdf

http://www.esamverka.se/download/18.6bfda2711612def98f65bbbb/1517325457941/F%C3%B6rstudierapport_Mina_kontaktuppgifter%20Version%201.0.pdf

http://www.esamverka.se/download/18.6bfda2711612def98f65bbbb/1517325457941/F%C3%B6rstudierapport_Mina_kontaktuppgifter%20Version%201.0.pdf

https://www.inera.se/digitalisering/arkitektur/strukturerad-omvarldsbevakning/

https://www.inera.se/digitalisering/arkitektur/strukturerad-omvarldsbevakning/

https://www.regeringen.se/495f60/contentassets/e9a0044c745c4c9ca84fef309feafd76/juridik-som-stod-for-forvaltningens-digitalisering-sou-201825.pdf

https://www.regeringen.se/495f60/contentassets/e9a0044c745c4c9ca84fef309feafd76/juridik-som-stod-for-forvaltningens-digitalisering-sou-201825.pdf

Projekt



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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.

https://naturvardsverket.sharepoint.com/:w:/s/EAMiljosverige/ES2OOr-AywJMk8EtuuJ8JzcBwC-LrUFjTumGJivHyUqYZg?e=f6sfdh

http://internt/Aktuellt/Alla-nyheter/Ovrigt/IT-strategin-forlangd-till-och-med-2017/

Projekt



Skapat av


Godkänt av


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



Skapat av


Godkänt av


1.2

Sparat

2019-08-21

Sida

35 (45)

5.1.2. GVU-MCP koncept och målbild

Projekt



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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.

https://www.skatteverket.se/foretagochorganisationer/myndigheter/informationsutbytemellanmyndigheter/navethamtauppgifteromfolkbokforing.4.18e1b10334ebe8bc80001754.html

https://www.skatteverket.se/foretagochorganisationer/myndigheter/informationsutbytemellanmyndigheter/navethamtauppgifteromfolkbokforing.4.18e1b10334ebe8bc80001754.html

https://bolagsverket.se/om/oss/samverkan/sammansatt-bastjanst/anslutningsguider-ti/anslutningsguide-for-it-leverantorer-1.15550

https://bolagsverket.se/om/oss/samverkan/sammansatt-bastjanst/anslutningsguider-ti/anslutningsguide-for-it-leverantorer-1.15550

Projekt



Skapat av


Godkänt av


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



[email protected]


NV-02644-17

Projekt



Skapat av


Godkänt av


1.2

Sparat

2019-08-21

Sida

40 (45)

Figur 1: Sekvensdiagram för realisering av användningsfallet Registrera anläggningsuppgifter i SNA.



[email protected]


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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



Skapat av


Godkänt av


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.

Arkitekturspecifikation GoS version 1 · 2019. 8. 22. · Projekt Naturvårdsverket Dokumentnamn...

Documents

Transcript of Arkitekturspecifikation GoS version 1 · 2019. 8. 22. · Projekt Naturvårdsverket Dokumentnamn...