Utkast 2 av dokumentasjon API-er for saksbehandlingsdata

Frist for innspill er onsdag 12. oktober. Vi har også sendt innkalling til et møte i arbeidsgruppa samme dag, slik at vi kan få muntlige tilbakemeldinger. I tillegg kan innspill sendes til service desk eller tas opp i statusmøter før 12. oktober.

Etter gode innspill i møter med leverandørene tidligere denne måneden har vi i dag publisert ny dokumentasjon til API-er for saksbehandlingsdata. Den største endringen går ut på at API for oppdatering er delt opp i flere spesialiserte API-er. Kodelista for Status/Milepæl endres og blir tettere knyttet opp mot API-ene. Mye av innholdet er ellers likt, men noen datafelter er endret.

Endringer i API-ene

For at API-ene og tilhørende validering skal være enkle å forvalte, ser vi behov for å dele API for oppdatering i flere, mer spissede API-er. API-kallene vil i hovedsak være utløst fra milepæler i saksbehandlingsløsningen, i tillegg til noen andre oppdateringer som påvirker søker.

Vi foreslår følgende API-er for saksbehandlingsdata:

API-er for oppdaterte milepæler:

  • API for kvittering (v2)

  • API for mangel (v2)

  • API for vedtak (v2)

  • API for oppdatert milepæl (nytt)

API-er for andre oppdateringer:

  • API for endret saksnummer (nytt)

  • API for saksoppdatering (nytt)

Kallene skal trigges ved oppdatering av milepæler i saksbehandlingssystemet, eller automatisk ved journalføring av innsending og ved en eventuell endring av saksnummer.

Sammenstilling av API-er og milepæler

Les mer API-ene og tilhørende datamodeller her: https://dibk.atlassian.net/wiki/spaces/FB/pages/2672787457

Endret kodeliste for status/milepæl

Forrige versjon av kodelista for status/milepæl blandet sammen ulike ting. Vi har derfor rendyrket kodelista til å kun inneholde milepæler vi mener skal omfattes av Fellestjenester BYGG, og knyttet API-ene tettere opp mot disse.

Les mer om milepælene som dekkes av FtB: https://dibk.atlassian.net/wiki/spaces/FB/pages/2674262017

Endring i datafeltene

I all hovedsak vil API-ene omfatte det samme innholdet som ble presentert i forrige runde. Vi foreslår imidlertid følgende endringer:

  • Kodeliste for SoknadStatus er endret og erstattes med en kodeliste for milepælene vi mener dekkes i Fellestjenester BYGG.

  • Strukturerte utfall sendes kun ved milepælene “Mangelbrev” eller “Vedtak fattet”, og begrenses til et gitt antall relevante utfall.

  • Vedtak har fått ny objekt for VedtakStatus. Feltet følger kodeliste med godkjente statuser.

  • Melding fjernes i de tilfellene det skal foreligge et formelt brev fra kommunen.

  • I API for kvittering skal kommunen melde tilbake hvilke filer, med metadata, som er mottatt. Vi har endret navn til FilNavn, og lagt til MimeType og EkstraMetadata, slik at det samsvarer med informasjonen som ligger i SvarUt.

  • Vi har lagt til saksnummer og saksansvarlig i alle API-ene, bortsett fra API for endret saksnummer.

  • Saksbehandler har endret navn til Saksansvarlig og kan inneholde enten navnet til en saksbehandler, til en avdeling eller for eksempel et kundesenter.

  • Vi har fjernet Journalår og Journalsekvensnummer fra Saksnummer. Dette er erstattet med Dokumentnummer, og kan brukes til for eksempel kobling til saksbehandlingsfase.

  • AvsenderNavn og EkspedertDato er flyttet til Metadata.

  • Vi har slått sammen oppdatering av søknadstype og oppdatering av tiltakstype i et nytt API for saksoppdatering.

Annen viktig informasjon

I innspillsmøtene har vi avklart følgende:

  • API for kvittering sendes for hver innsending og ikke kun for hovedsøknaden.

  • API for kvittering brukes når innsendingen er journalført i eByggesakssystemet. Systemene håndterer dette ulikt, og det kan derfor ta noe tid før kvittering og saksnummer sendes. Det er derfor viktig at søknadssystemene forventningsavklarer søker om at kvitteringen ikke kommer umiddelbart etter innsending.

  • Oppdatering av milepæl sendes for hver innsending, og ikke for søknadsprosessen i sin helhet. Det vil si at for eksempel Søknad om igangsettingstillatelse og Supplering av søknad oppdateres på samme måte, men at søknaden/saken som helhet ikke oppdateres.

  • API-ene skal ikke fange ikke opp uformell kommunikasjon, men skal dekke formelle utsendinger av brev og lignende.

  • Svar tilbake til kommunen sendes som ettersending/mangelbesvarelse i Supplering av søknad eller ved å oppfylle vilkår og oppfølgingspunkt ved søknad om igangsetting, midlertidig brukstillatelse og ferdigattest.

  • API for saksoppdatering krever at sjekklistene oppdateres til å gjelde for den nye tiltakstypen/søknadstypen. Dette må oppdateres både i søknadssystemene og i saksbehandlingssystemet, i tillegg til at sjekklistene må oppdateres.

  • Endring av saksnummer kan forekomme, og blir sendt tilbake til søknadssystemet i et eget API. Det kan være at saken flyttes, deles opp eller slås sammen. Det er viktig at søknadssystemene oppdaterer saksnummer/saksnumrene basert på denne informasjonen. På sikt ønsker vi å komme frem til en standard oppdeling av saker som gjelder både fra søknadssystem og i mottakssystem, for å minimere behovet for slike endringer i ettertid. Det vil følges opp i et eget prosjekt.

  • Vi har ikke landet på hvordan det utgående dokumentet fra kommunen skal leveres, eller hvilke felter objektet skal inneholde.