SvarUt hadde en driftsforstyrrelse i dag. Vi ser at 25 innsendinger til SvarUt har feilet mellom kl 09:41 og 11:03. Tjenesten er nå oppe igjen og innsendinger blir levert som de skal.

Ta kontakt med service desk om dere ønsker at vi skal manuelt kjøre innsendinger på nytt.

Oppdatering 13:10: Vi har varslet alle søknadssystemene og har på forespørsel kjørt noen innsendinger på nytt.

Her er en foreløpig skisse for datamodell, vedlegg og underskjema, samt utskrift (PDF) for supplering av søknad.

Skriv en kommentar her eller send oss en sak på service desk dersom dere har innspill. Vi ønsker å starte utviklingen så raskt som mulig, og ber derfor om at kommentarer sendes innen fredag 9. april.

Innlegget er delt opp i følgende temaer:

Datamodell

Utkast til datamodell vises under. Dere kan også laste ned XSD-fila:

Navngivingen av feltene vil justeres litt.

En grundigere gjennomgang av datamodellen kan også ses på opptaket fra dialogmøtet 16. mars i år.

Supplering

Supplering består av to valg: mangelbesvarelse og ettersending:

mangelBesvarelse:

ettersending:

Annen informasjon

I tillegg har vi “vanlige” objekter for eiendomByggested, tiltakshaver, signatur, ansvarligSoeker, kommunensSaksnummer og metadata:

Vedlegg og underskjema

I utgangspunktet ønsker vi at alle vedlegg og underskjema skal være tillatt.

Dersom noe data er bedre for søker og kommunen å svare ut og motta strukturert, kan vi utvikle egne underskjema med validering. Et eksempel på et underskjema vi ønsker å tilby, er arealregnskap.

Gi gjerne innspill på hvilke andre underskjema dere eventuelt ønsker at vi skal lage.

Utskrift (PDF)

Beskrivelse av oppsett

Vi ser for oss visning av søknaden med disse elementene:

Søknaden gjelder

[KommunensSaksnummer]

[eiendomByggested]

Svar på mangler

Mangelbesvarelsen vil bestå av en liste med følgende elementer:

[tittel] fritekstfelt, brukes som overskrift

[tema] kun ved strukturerte mangler i første omgang

[erMangelBesvaresSenere] vises dersom true

[kommentar] denne eller filvedlegg må være fylt ut

[filvedlegg] viser både vedlegg og underskjema dersom de er lagt ved

Det er med andre ord en del felter fra datamodellen vi ikke bruker i første omgang. Vi ønsker likevel å holde datamodellen litt vid i tilfelle vi ser behov for å bruke flere felter på sikt.

Ved strukturerte mangler, ønsker vi også at dere sender med mangelId. Vi kommer tilbake med grundigere dokumentasjon etter innspillrunden.

Ettersending

Ettersending vil bestå av en liste med følgende elementer:

[tittel] fritekstfelt, brukes som overskrift

[kommentar] denne eller filvedlegg må være fylt ut

[filvedlegg] viser både vedlegg og underskjema dersom de er lagt ved

Søker og signatur

[ansvarligSoeker] eventuelt tilltakshaver dersom tiltaket er uten ansvarsrett

[signatur]

Eksempelutskrift

Under viser vi et eksempel på hvordan en visning kan være, gitt oppsettet over.

Supplering av søknad

etter plan- og bygningsloven § 20-1.

Kommunens saksnummer (år, sekvensnummer): 2020 123

Søknaden gjelder

EIENDOM/BYGGESTED

Gårdsnr.: Bruksnr.: Festenr.: Seksjonsnr.:

148 55

Bygningsnr.: Bolignr.:

123456789 H0301

Kommune: Lunde

Adresse: Nygate 33, 3825 Lunde

Svar på mangler

ADRESSE PÅ BYGGESTED MANGLER

Tema: Generelt

Skal mangelen besvares senere? Ja

Kommentar:

Byggestedet har ikke en adresse ennå.

ALLE NABOER ER IKKE VARSLET

Tema: Nabovarsel

Kommentar:

Jeg har varslet alle naboer nå. Se vedlegg.

Vedlegg:

• KvitteringNabovarsel

• Gjenpart nabovarsel

• Nabomerknader

• KommentarNabomerknader

IVARETAKELSE AV KRAV TIL UNIVERSELL UTFORMING OG ARKITEKTONISK UTFORMING I REGULERINGSPLANEN

Kommentar:

Her er en nærmere beskrivelse for at tiltaket tilfredsstiller kravene til arkitektonisk utforming og visuelle kvaliteter, både i seg selv og i forhold til omgivelsene.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris iaculis, mauris nec commodo ornare, libero erat sagittis ligula, a volutpat justo dui sit amet mauris. Pellentesque volutpat malesuada pretium. Nullam in auctor neque. Quisque venenatis ligula in mauris ullamcorper volutpat. Duis arcu dolor, ornare vitae aliquet sed, vestibulum ac lacus. Cras accumsan nunc egestas metus tempus luctus. Morbi sodales neque nisl, nec laoreet velit convallis ac. Duis nec lectus orci. Cras non tortor eros.

Ettersending

NY SITUASJONSPLAN

Kommentar:

Se vedlegg.

Vedlegg:

• Situasjonsplan

OPPDATERT AREALREGNSKAP

Vedlegg:

• Arealregnskap

Søker

Navn: Arkitekt Flink AS

Telefon: 95939392

23234949

E-postadresse: arkitekt@flink.no

Adresse: Storgata 5, 7003 Trondheim

Organisasjonsnr.: 904939234

Kontaktperson: Ludvig Moholt

Telefon: 40464554

22393939

E-postadresse: ludvig@flink.no

SIGNERT AV

LUDVIG MOHOLT på vegne av ARKITEKT FLINK AS

Vi har hatt en gjennomgang av valideringsreglene etter skjemaendringene før jul og innspill mottatt på servicedesken. Endringen om gårds- og bruksnummer er produksjonssatt, mens de øvrige er tilgjengelige i test og trer i kraft 6. april.

Feil i sjekklistepunkt

Endring i sjekklistepunkt for skred og flomfare. Valideringsregelen har en liten feil i sjekklistepunktet og endres fra '11.09' til ‘11.9’: “Det er valgt at byggverket skal plasseres i et område med fare for skred. Da må vedlegget ‘Redegjørelse skred og flomfare’ legges ved, jfr. nasjonal sjekkliste punkt 11.9.” Frem til endringen trer i kraft lever 11.09 og 11.9 parallelt. Dette gjelder følgende tjenester:

• Søknad om rammetillatelse

• Søknad om tillatelse i ett trinn

• Søknad om endring

Sjekklistereferanse ‘2.2’ har hatt en tegnsettingsfeil og er rettet fra ‘2.2.’. Disse vil leve parallelt frem til endringene iverksettes. Dette gjelder for:

• Søknad om tiltak uten ansvarsrett

Vannforsyning

Valideringsregelen “Du må svare på om vannforsyning skal ledes over annens grunn, jfr. nasjonal sjekkliste punkt 9.5” skal ikke slå ut dersom kodeverdien BerorerIkkeVannverk brukes. Les mer om bakgrunnen for dette her: Endring i kodelister for beregningsregel og vanntilknytning

Endringen gjelder følgende tjenester:

• Søknad om rammetillatelse

• Søknad om tillatelse i ett trinn

Arealregnskap

Arealregnskap skal ikke slå ut dersom 'beregningsregelGradAvUtnytting' er ingenKrav. Bakgrunnen for endringen er dokumentert her: Endring i kodelister for beregningsregel og vanntilknytning

Endringen gjelder for følgende tjenester:

• Søknad om rammetillatelse

• Søknad om tillatelse i ett trinn

• Søknad om tiltak uten ansvarsrett

• Søknad om endring

Løfteinnretninger

Endring i sjekklistepunkt for informasjon om løfteinnretninger. Valideringsregelen har henvist til sjekklistepunkt ‘18.17’ i søknad om ferdigattest. Vi har nå opprettet tilsvarende sjekklistepunkt i søknad om rammetillatelse og ettrinnssøknad, med referanse ‘18.22’. Teksten er endret til: “Du må svare på om det er løfteinnretninger som omfattes av TEK i bygningen, jfr. nasjonal sjekkliste punkt 18.22.” Dette gjelder følgende tjenester:

• Søknad om rammetillatelse

• Søknad om tillatelse i ett trinn

Gårds- og bruksnummer

Endring av validering slik at gårds- og bruksnummer kan være 0 eller større. Tidligere har regelen ført til feil dersom verdien var 0. Regelen er samtidig splittet opp i to, en for gårds- og en for bruksnummer: “Gårdsnummer '{0}' for eiendom/byggested må være '0' eller større.” og “Bruksnummer '{0}' for eiendom/byggested må være '0' eller større.“ Endringen er tilgjengelig i produksjon, og gjelder følgende tjenester:

• Samsvarserklæring (direkte opprettet)

• Kontrollerklæring (direkte opprettet)

• Distribusjonstjeneste for kontroll og samsvarserklæring

• Søknad om Arbeidstilsynets samtykke v1

Dette er en oppfølging til blogginnlegget om samme tema fra 16.09.2020: Schrems II-dommen og Fellestjenester BYGG

Bakgrunn

Grunnen til at vi følger opp denne saken er at det er et felles ansvar for alle behandlingsansvarlige og databehandlere å sikre at behandling og evt overføring av personopplysninger skjer i tråd med regelverket. I tillegg er sentrale deler av Fellestjenester BYGG, og Fellestjenester PLAN, som kjent, bygd opp på tjenester og funksjonalitet i Microsoft Azure.

Vurdering fra Digitaliseringsdirektoratet

DiBK har hatt kontakt med Digitaliseringsdirektoratet(Digdir) og Altinn om deres vurdering av effektene av Schrems II-dommen. Det er naturlig, siden Digdir er å anse som premissgiver, i denne sammenhengen, at DiBK legger seg tett opp til deres vurderinger og følger deres anbefalinger.

Man har dels vurdert den umiddelbare betydningen av dommen generelt, dels sett på hva den betyr for løsninger som kjører i skyløsninger hos amerikanske leverandører og endelig vurdert betydningen for Altinn 3.0

Sammenfattende kan vi si at Digdir/Altinn sine vurderinger og tilnærming er i trådd med DiBK sin holdning slik den fremgår av tidligere blogginnlegg (se link ovenfor), som kort fortalt er å se tiden litt an inntil det kommer en avklaring fra Datatilsynet som vi kan forholde oss praktisk til.

Problematikk og tiltak

Problematikken er konkret at det pga sikkerhetslover i USA, som alle amerikanske skyleverandører er underlagt, ikke er mulig for dem å garantere samme personvernbeskyttelse som i EU/EØS. Det er et krav etter GDPR og dermed en forutsetning for at man som behandlingsansvarlig og databehandler kan bruke deres tjenester. Samtidig er det praktisk utfordrende å tilrettelegge ytterligere, beskyttende tiltak, som for eksempel kryptering av personopplysninger, siden krypteringsrutinen ikke kan kjøres i samme løsning og krypteringsnøkler ikke kan lagres i samme miljø som krypterte data.

I dagens versjon av Fellestjenester BYGG krypteres alltid fødselsnummer når det er i trafikk eller lagres, men det må dekrypteres når det skal brukes i prosess med Altinn, f.eks. distribusjon av nabovarsel. Kryptering/dekryptering skjer i miljøet vårt på MS Azure plattformen.

Det vurderes også om man kan velge en risikobasert tilnærming, der man ser på risikoen for den registrertes personvern knyttet til de enkelte personopplysningene som behandles. Det kan virke som en fristende løsning hvis man vurderer at risikoen som så liten, at man trygt kan fortsette med sin skytjenesteleverandør, evt. med noen tiltak.

Motforstillingen er at man som behandlingsansvarlig eller databehandler med en amerikansk leverandør ikke kan vurdere tryggheten reelt, fordi det etter amerikanske sikkerhetslover, kan forbys leverandørene å opplyse om myndighetenes brudd på personvernet. Behandlingsansvarlig er dermed ikke i en situasjon der man har kontroll. I tillegg betyr det at den registrertes rett - en menneskerett - til å få prøvd sin klage for retten ikke kan oppfylles.

Praktiske tiltak

Digdir og Altinn foreslår tre praktiske tiltak:

1. Skaffe oversikt hvilke skytjenester og hvilke funksjoner i tjenestene man bruker i sine løsninger

2. Skaffe oversikt over hvilke typer personopplysninger som lagres

3. Vurdere om eksisterende databehandleravtaler er tilstrekkelige

Til punkt 2; man bør ikke kun se på hva som lagres, men hva som i det hele tatt prosesseres.

Det å ha oversikt og kontroll over data og tjenester er allerede et krav etter Personopplysningsloven som bl.a. oppfylles ved å føre en behandlingsprotokoll, etter artikkel 30 i GDPR.

Altinn-miljøet

Altinn 3.0, som er det fremtidige grunnlaget for en del offentlige fellestjenester, utvikles og driftes i Microsoft Azure-miljø i datasentre i Norge og EØS-land. Det er lagt vekt på at løsningene er leverandøruavhengige og det vurderes om man skal teste portabiliteten.

Fellestjenester BYGG er bygd for integrasjon med Altinn 2.0, men vil gradvis bli utviklet til å basere seg på integrasjon med Altinn 3.0. Fellestjenester PLAN bygger dels på Fellestjenester BYGG-plattformen dels på Altinn 3.0.
Det vurderes å være hensiktsmessig for DiBK sine Fellestjenester-løsninger å legge seg tett opp til Altinn sine valg.

Avsluttende

Som tidligere nevnt: Inntil en tydeligere avklaring kommer så avventer DiBK. Vi følger og vurderer utviklingen fortløpende og holder dere oppdatert når vi ser behov for det.

Vi oppfordrer til at dette og refererte innlegg deles med deres personvernansvarlig. Er det noen spørsmål eller kommentarer, ta gjerne kontakt via service desk.

Enkelte typer vedleggsfiler som kan lastes ned via Download APIet inneholder feil data.

Problemet oppstod 25.02.2021 og ble fikset i produksjon ettermiddag (09.03.2021, 15:40)

Følgende tjenester er berørt:

• Nabomerknader vedlegg til "Svar på nabovarsel"

• PlanForUavhengigKontroll vedlegg til "Kontrollerklæring (direkte innsending og via distribusjon)"

• Annet vedlegg til "Uttalelse til oppstart av reguleringsplanarbeid"

I tilfeller der de vi har sendt de samme vedleggene til søkers innboks i Altinn (f. eks. nabomerknader) så er det ikke feil vedlegget.

Vi har identifisert et par hundre vedlegg som må oppdateres. Vi prøver å fullføre denne jobben i morgen.

Vi oppdaterer blob storage med de korrekte vedleggene slik at alle Download API lenkene kommer til å levere det rette APIet.

Vi oppdaterer dette blog innlegget når vi har fått oppdatert vedleggene som er lagret feil.

10.03.2021: 10:22 – vi har oppdatert alle filvedleggene slik at de har korrekt innhold. Søknadssystemene bes laste ned data fra download APIet på nytt. Vi sender ut en liste med de oppdaterte AR kodene til de berørte søknadssystemene.

Send sak til Service Desk om det er noen vedvarende problemer.

Vi ser noen utsendinger til Svar Ut feiler med meldingen “Klarte ikke å lagre originaldokument (java.util.concurrent.TimeoutException null)“. Vi jobber med KS kundestøtte om saken.

Vi har inntil videre ikke stoppet utsendinger til SvarUt.

Det er 6 utsendinger som har feilet siden 07.03.2021.

KS er klar over problemet og jobber med saken. Noen utbedringer er allerede på plass.

Vi oppfordrer søknadssystemene til å sjekke status på innsendinger.

08.03.2021, 12:48: KS har utbedret feilen og vi har sett flere feilsituasjoner. Det er seks AR koder som har feilet, vi tar kontakt med avsendende systemer.

Tiltakshavers samtykke til byggeplaner ble satt i produksjon i arbeidsflyt forrige uke. Vi har også bestilt produksjonssetting i Altinn.

Mer dokumentasjon finner dere her: Tiltakshavers samtykke til byggeplaner

Vi anbefaler alle søknadssystemene å implementere støtte for tiltakshavers samtykke i løsningen, av følgende grunner:

• Digitalt samtykke fra tiltakshaver er viktig for at kommunene skal få inn fødselsnummeret til tiltakshaver, slik at den videre dataflyten med eByggesakssystemene blir sømløs.

• Unntaket i forskriften fra kravet om å sende tiltakshavers samtykke til kommunen vil også oppheves på sikt. Løsningen vil sikre at ansvarlig søker slipper å ettersende tiltakshavers signatur til kommunen.