API for oppdatering (nytt)
Utkast per 31. august 2022. Endringer vil komme etter innspill fra økosystemet.
Det nye API-et for oppdatering fanger opp alle oppdateringer på en forsendelse etter at en kvittering er sendt. API for oppdatering erstatter dagens API-er for vedtak og mangel, og inkluderer også andre typer utfall og oppdateringer som ikke er fanget opp av dagens API-er.
Bortsett fra metadata ønsker vi at kommunene kun sender data i feltene dersom noe er nytt eller endret i saken, slik at ikke eksisterende informasjon sendes flere ganger.
Kommunen kan bruke API-et til å oppdatere nøkkelinformasjon eller utfall i saken:
Oppdatering av nøkkelinfo brukes dersom saken har endret eller oppdatert saken med saksnummer, saksbehandler, søknadstype, tiltakstype eller saksbehandlingsfrist.
Oppdatering av utfall brukes når søker skal varsles om et utfall på et eller flere sjekkpunkt. Se oversikt over relevante utfall her: Kobling til utfallarchived
Innhold:
Oversikt
Beskrivelse av felter
Oppdatering
Felt | Beskrivelse | Eksempel |
---|---|---|
Oppdatering |
|
|
Metadata | Samme felter som for API for kvittering - Metadata, bortsett fra at InnsendingReferanse og FtBID er listeobjekter. Dette for å fange opp saker hvor flere sendinger er slått sammen til ett saksnummer, der saken er flyttet til et annet saksnummer eller der én eller flere saker er slått sammen. | - |
OppdatertDato | Dato oppdateringen er sendt fra kommunen. Erstatter vedtaksdato, oppfølgingspunktdato og mangeldato fra de gamle API-ene. |
|
SoknadStatus | Status på søknaden. Forslag til ny kodeliste basert på de viktigste milepælene. Se Kodeliste - SøknadStatus (lenke kommer). | - |
| - |
|
| - |
|
Melding (0…*) | Ustrukturert informasjon, eller en liste av informasjon, fra saksbehandler til søker. |
|
UtgaaendeDokument (0…*) | Informasjon om dokumentene inkl vedlegg som sendes fra saksbehandler. | - |
DokumentUrl | URL for nedlastning av dokumentet. |
|
DokumentTittel | Navn på sendt dokument/skjema. |
|
DokumentType | Følger kodeverdier for Kodeliste - DokumentType. |
|
Svarfrist | Fristen søker har på å svare på utfallene. |
|
Oppdatering av nøkkelinformasjon
Felt | Beskrivelse | Eksempel |
---|---|---|
OppdatertNokkelinfo | - | - |
Saksnummer (0…*) | Samme felter som for API for kvittering - Saksnummer, men saksnummer kan være en liste. Aktuelt ved flytting til annet saksnummer, splitting i to eller flere saker, eller ved sammenslåing av flere saker. | - |
Saksbehandler | Samme felter som for API for kvittering - Saksbehandler. Brukes dersom informasjon om saksbehandler oppdateres eller om saken får ny saksbehandler. | - |
Soknadstype | Brukes dersom kommunen endrer søknadstype fra søknad i ett trinn til rammesøknad. En slik oppdatering må reflekteres i søknadssystemet slik at søknadsløpet kan oppdateres. Følger Kodeliste - Søknadstype. | - |
| - |
|
| - |
|
Tiltakstype (0…*) | Oppdatering av tiltakstype(r) som gjelder for søknaden, dersom saksbehandler endrer disse. Det blir avgjørende for visning av sjekklisteutvalg, og må reflekteres i søknadssystemet slik at valideringen tilpasses de oppdaterte tiltakstypene. Følger Kodeliste - Tiltakstype. | - |
| - |
|
| - |
|
Saksbehandlingsfrist | Kommunens frist for å behandle søknaden. Brukes dersom frist blir fastsatt eller endres, for eksempel fra 3 til 12 ukers saksbehandling eller ved gjensidig fristforlengelse. Fristen må oppdateres hvis det i løpet av saksbehandlingen blir stopp i tidsregningen. |
|
Oppdatering av utfall
Felt | Beskrivelse | Eksempel |
---|---|---|
OppdatertUtfall (0…*) | Utfall, eller liste av utfall, som er oppdatert etter førstegangsinnsending. | - |
Utfall | Hvilket utfall et gitt sjekkpunkt har fått, for eksempel mangel eller vilkår i vedtak. Følger Kodeliste - Utfall. | - |
| - |
|
| - |
|
UtfallID | eByggesaksystemets ID for utfallet. |
|
ReferanseSjekkpunkt | Sjekkpunktet som har utløst utfallet: | - |
| Sjekklistepunktet mangelen er utløst fra. |
|
| Sjekkpunktets tittel. |
|
| Lenke til mer informasjon om sjekkpunktet. |
|
| Eier av sjekkpunktet mangelen er utløst fra. Det kan være DiBK, SSB eller den enkelte kommunes lokale mangler. |
|
UtfallBeskrivelse | Beskrivelse fra kommunen om utfallet: | - |
| Mangelens tittel etter at saksbehandler evt. har justert den. Skal ta utgangspunkt i de standardiserte tekstene dersom de er tilgjengelige. |
|
| Mangelens beskrivelse/undertekst etter at saksbehandler evt. har justert den. Skal ta utgangspunkt i de standardiserte tekstene dersom de er tilgjengelige. |
|
| Mer informasjon fra saksbehandler |
|
| Lovhjemmel, eller en liste av hjemler, som er knyttet til mangelen |
|
UtfallTilProsess | Saksbehandlingsprosessen mangelen må være oppfylt for. Følger Kodeliste - Søknadstype. | - |
| - |
|
| - |
|
Felter som er vurdert, men ikke tatt med
Tema for utfallet - fra https://register.geonorge.no/kodelister/ebyggesak/tema
Standardtekst for utfallet fra GeoNorge
Status for utfallet, for eksempel “ikke besvart”
Gebryrberegning
Dispensasjon for vedtak (til vurdering)
Kodelister
DokumentType
DokumentType sendt fra søknadssystem har en egen kodeliste: https://register.geonorge.no/kodelister/byggesoknad/vedlegg-og-underskjema .
Denne må oppdateres eller det må opprettes en ny kodeliste for å fange opp dokumenttyper fra kommunen (vedtak, mangelbrev mv.).
SoknadStatus (ny)
Forslag til ny kodeliste for å fange opp de viktigste milepælene for søknaden. Mer informasjon her: Statuser / Milepælerarchived
Søknadstype
Eksisterende kodeliste for å fange opp endring av søknadstyper, eller utfall som skal oppfylles før en gitt tillatelse kan gis. Følger eksisterende kodeliste: https://register.geonorge.no/kodelister/byggesoknad/soknadstype
Tiltakstype
Brukes dersom saksbehandler endrer eller legger til tiltakstyper. Følger eksisterende kodeliste: https://register.geonorge.no/kodelister/byggesoknad/tiltaktype
Utfall
Brukes dersom et sjekkpunkt får et utfall som skal meldes til søker. Se oversikt over hvilke utfall det er på Kobling til utfallarchived
Spørsmål til diskusjon
Spørsmål 1: Hvordan bør oppdaterings-APIet brukes på et overordnet plan?
Er det hensiktsmessig med et felles API for alle oppdateringer, eller bør det splittes opp egne API-er for vedtak, mangel og eventuelt andre utfall?
Er det ønskelig at andre typer utfall enn mangel og vedtak med vilkår/oppfølgingspunkt fanges opp av API-et, eller bør det begrenset til det søker skal melde tilbake til kommunen?
Hvilke scenarioer bør API-et fange opp?
Hvilken ID skal brukes som “nøkkel” for å fange opp oppdateringer dersom kommunen splitter opp eller deler en sak?
Spørsmål 2: Treffer feltene behovet til saksbehandler og søker?
Er det noen opplysninger som mangler?
Skal UtgaaendeDokument inneholde en liste med DokumentTittel, DokumentType og eventuelt andre opplysninger, eller kun en liste med navn?
Er det nødvendig med både beskrivelse og veiledningstekst for UtfallBeskrivelse?
På hvilken måte bør SoknadStatus brukes? Hvordan se det i sammenheng med utfall?
Spørsmål 3: Hva slags validering er ønskelig?
Hvilke felter skal være påkrevde og ikke?
Andre begrensninger i innholdet i feltene?