Snitflade for sagsbehandling service

Snitflade for sagsbehandling service Version: 1.3 Forfatter: USE Dato: 2013-06-19

Indhold 1 INTRODUKTION... 5 1.1 FORMÅL... 5 1.2 MÅLGRUPPE... 5 1.3 LÆSEVEJLEDNING... 5 1.4 STATUS... 5 2 SERVICES OG INTEGRATIONSMØNSTER... 6 2.1 FORBERED ANSØGNING... 7 2.1.1 Ansøgning XML... 7 2.1.2 Ansøgningsdokumentet... 7 2.2 INDSEND ANSØGNING... 8 2.2.1 Ansøgningsdokument og bilag uploades til upload/download service... 9 2.2.2 Besked sendes til beskedfordeler... 9 2.3 MYNDIGHEDS ESDH/FAGSYSTEM TØMMER BESKEDFORDELER SERVICE... 9 2.3.1 Myndigheds ESDH/fagsystem læser ansøgning... 9 2.3.2 Myndigheds ESDH/fagsystem downloader ansøgningsdokument og bilag... 9 2.4 MYNDIGHED BESVARER ANSØGNINGEN... 9 3 MEDDELELSESMODELLER... 11 3.1 ELEMENTET ANSOEGNING... 11 3.2 ELEMENTET DOKUMENT... 13 3.2.1 Korrespondance til OIO Dokument... 14 3.3 ELEMENTET BOMSAG (BYG OG MILJØ SAG)... 14 3.4 ELEMENTET PARTLISTE... 15 3.5 ELEMENTET DOKUMENTATION... 16 3.6 ELEMENTET TIDLIGEREANSOEGNINGLISTE... 17 3.7 ELEMENTET AKTIVITETLISTE... 17 3.8 ELEMENTET DOKUMENTATIONBILAGLISTE... 18 3.9 ELEMENTET OBJEKTLISTE... 19 3.10 ELEMENTET MATRIKEL... 20 3.11 ELEMENTET BYGNING... 21 3.12 ELEMENTET ENHED... 22 3.13 ELEMENTET SKITSE... 23 3.14 ELEMENTET FILBILAGLISTE... 24 3.15 ELEMENTET DOKUMENTATIONKRAVLISTE... 25 3.16 ELEMENTET KONFLIKTSOEGNINGRESULTATLISTE... 26 3.17 ELEMENTET MYNDIGHEDSAG... 27 3.18 ELEMENTET SAGREFERENCE... 28 3.19 ELEMENTET SAGSTATUS... 28 3.20 ELEMENTET BEHANDLESAFENHED... 29 3.21 ELEMENTET SAGSBEHANDLER... 29 3.22 ELEMENTET BEHANDLINGRETSKILDE... 30 3.23 ELEMENTET LOKALUDVIDELSE... 30 3.24 ELEMENTET ANSOEGNINGBESVARELSE... 30 3.25 ELEMENTET MYNDIGHEDAFSENDER... 32 3.26 ELEMENTET ANSOEGERMODTAGER... 32 3.27 ELEMENTET MEDDELELSETEKST... 32 ELEMENTET... 32 Schultz Information Side 2 af 47

3.28 ANSOEGNINGMODTAGET... 32 3.29 ELEMENTET SAGREFERENCEOPDATERING... 33 3.30 ELEMENTET SAGSTATUSOPDATERING... 33 3.31 ELEMENTET BEHANDLINGENHEDOPDATERING... 33 3.32 ELEMENTET SAGSBEHANDLEROPDATERING... 34 3.33 ELEMENTET LOKALUDVIDELSEOPDATERING... 34 3.34 ELEMENTET RETSKILDEOPDATERING... 35 3.35 ELEMENTET DOKUMENTATIONKRAVOPDATERING... 35 3.36 ELEMENTET INSTRUKTIONTEKST... 35 3.37 ELEMENTET KRAVSTYRKE... 36 4 SERVICEINTERFACET SAGSBEHANDLING... 37 4.1 ANVENDELSE... 37 4.2 LAESANSOEGNING... 37 4.2.1 Input... 37 4.2.2 Output... 37 4.2.3 Fejlsituationer... 37 4.3 BESVARANSOEGNING... 37 4.3.1 Input... 37 4.3.2 Output... 38 4.3.3 Fejlsituationer... 38 4.4 HENTMEDDELELSE... 38 4.4.1 Input... 38 4.4.2 Output... 38 4.4.3 Fejlsituationer... 38 4.5 LAESANSOEGNINGOVERSIGT... 38 4.5.1 Input... 39 4.5.2 Output... 39 4.5.3 Fejlsituationer... 39 4.6 LAESMEDDELELSEOVERSIGT... 39 4.6.1 Input... 39 4.6.2 Output... 39 4.6.3 Fejlsituationer... 40 4.7 WSDL... 40 5 SERVICEINTERFACET DOWNLOAD DOKUMENT... 41 5.1 DOWNLOAD ENDPOINT... 41 5.2 AUTENTIFICERING... 41 5.3 LEVETID AF DOKUMENTER... 41 5.4 URI MØNSTER... 41 5.5 FEJLSITUATIONER... 42 6 SERVICEINTERFACET UPLOAD DOKUMENT... 43 6.1 LEVETID... 43 6.2 AUTENTIFICERING... 43 6.3 FEJLSITUATIONER... 43 7 SIKKERHED... 45 7.1 SAGSBEHANDLING SERVICEN... 45 7.2 DOKUMENT UPLOAD / DOWNLOAD SERVICE... 45 8 VERSIONERING... 46 Schultz Information Side 3 af 47

9 ÆNDRINGSLOG... 47 Schultz Information Side 4 af 47

1 Introduktion Dette dokument beskriver snitfladen Sagsbehandling og relaterede services som udstilles af KOMBIT Byg og Miljø løsningen til brug for sagsbehandling i myndighedernes (kommuner og Kulturstyrelsen) sagsbehandlings- og fagsystemer. 1.1 Formål Formålet med dette dokument er at give eksterne parter mulighed for at konstruere service klienter således at sagsbehandling kan foretages i ESDH- og fagsystemer og integreres med Byg og Miljø (BOM) løsningen. 1.2 Målgruppe Dokumentet er rettet mod IT løsningsarkitekter og udviklere som skal udvikle integrationer med Byg og Miljø løsningen. 1.3 Læsevejledning Kapitel 2 giver et overblik over integrationsmønsteret på forretningsteknisk niveau. Kapitlet beskriver overordnet den funktionalitet som Byg og Miljø løsningen udstiller til brug for manipulation af sager og kommunikation med ansøgere gennem løsningen. Dette kapitel bør læses af IT arkitekter som skal planlægge på hvilket niveau et aftagersystem skal/kan integrere med løsningen. Kapitel 3 beskriver med XML diagrammer (XML Spy diagrammering) detaljeret opbygningen af meddelelser og deres elementer/attributter. Dette kapitel bør læses af udviklere/it arkitekter som skal sammensætte de og udfylde elementer i de konkrete meddelelser. Kapitel 5 og 6 beskriver 2 relaterede services som benyttes til udveksling af binære filer og dokumenter der ikke kan indlejres i selve XML meddelelserne. Disse kapitler retter sig mod udviklere som skal udvikle den faktiske integration med disse services. Kapitel 7 beskriver sikkerhedsmodellerne som anvendes af services. Kapitlet bør læses af IT arkitekter / IT sikkerhedsansvarlige samt udviklere som har ansvar for udvikling af integration med BOM løsningen. 1.4 Status Nærværende dokument beskriver snitfladen som den er planlagt. Den overordnede struktur, integrationsmønster og funktionalitet forventes ikke at blive ændret. Der tages forbehold for at detaljer i de enkelte meddelelsesmodeller kan ændres. Schultz Information Side 5 af 47

2 Services og Integrationsmønster Integrationen med ESDH- og fagsystemer omfatter flere services som alle beskrives i dette dokument: Sagsbehandling serviceinterfacet er den primære snitflade som myndighedernes ESDH- og fagsystemer benytter i integrationen. Igennem denne snitflade henter systemerne ansøgninger og meddelelser fra ansøgerne og sender myndighedens besvarelser, sagsopdateringer mm. Serviceinterfacet omfatter ikke overførsel af de faktiske binære dokumenter/filer. Sagsbehandling serviceinterfacet er SOAP baseret og er ikke praktisk anvendeligt til overførsel af binære filer af uforudsigelige størrelser. I dette benytter serviceinterfacet samme princip som OIO Dokument serviceinterfacet. Dokument download serviceinterface benyttes til at downloade binære filer og dokumenter. De konkrete URL er modtages gennem det primære Sagsbehandling serviceinterface og hentes fra denne service direkte over http protokollen. Dokument upload serviceinterface benyttes til at uploade binære filer og dokumenter som skal sendes fra myndigheden til ansøger(ne). Myndigheden tildeler et unikt URL til hver enkelt fil og uploader disse gennem denne upload servicen. Derefter refereres dokumenterne/filerne i meddelelser som sendes til ansøgeren gennem det primære Sagsbehandling serviceinterface. Beskedfordeler serviceinterfacet er pladsholder for en infrastruktur komponent af samme navn som det formodes at BOM og ESDH/fagsystemer senere skal integrere med. Imidlertid er denne komponent ikke færdigudviklet og tilgængelig når BOM skal tages i drift. Denne service opfylder samme funktion lokalt mellem BOM og ESDH/fagsystemer med det formål at tillade samme integrationsmønster men uden at forsøge at forudsige det præcise design af den kommende beskedfordeler. Beskedfordeler servicen er et posthus hvor BOM placerer beskeder om hændelser (fx nye ansøgninger eller meddelelser fra ansøgere til myndigheden). Myndigheden antages så at hente beskeder regelmæssigt (polling) og kontakte BOM Sagsbehandling servicen for at læse de faktiske ansøgninger, meddelelser mm. Schultz Information Side 6 af 47

2.1 Forbered ansøgning Før ansøgningen afsendes fra BOM (den oprindelige ansøgning eller senere indsendelser) bliver den pakket i BOMs forsendelseskomponent. Denne pakning indebærer at der dannes en XML besked med ansøgningsdata samt et PDF dokument, ansøgningsdokumentet. 2.1.1 Ansøgning XML Ansøgningen er beskrevet i et XML dokument. Skema for dette dokument er beskrevet i afsnit 3.1. 2.1.2 Ansøgningsdokumentet Ansøgningsdokumentet er et PDF dokument som indeholder o o Projektets navn/titel som ansøgningens titel Myndighedens sagsnr hvis dette er sat af myndigheden (1. indsendelse vil ikke have sagsnr). Schultz Information Side 7 af 47

o o o o o o o o o o Sagens beregnede sagstype Klassifikation ud fra sagstype (fx KLE) Historikrapport som beskriver hvad der er ændret i dokumentet siden sidste indsendelse. Dette omfatter ændrede dokumentationstyper, ændrede objekter (flyttede/slettede/nye), ændret sagstyper, ændrede aktivitetstyper, ændrede dokumentationskrav. Liste over sagens aktivitetstyper. Liste over sagens objekter (indtegnede og udpegede bygninger, matrikler, enheder). En sektion for hver dokumentationstype. Sektionen viser eventuelle indtastede redegørelser, besvarelser af inputfelter, digital signatur etc. Sektionen indeholder også en liste af referencer til bilag der er refereret fra dokumentationsbesvarelsen. Bilag er filer som er uploadet af ansøgeren. Bilag vises som links i PDF filen. Hvis brugeren har adgang til sagsbehandler web kan brugeren downloade filen ved at klikke på linket. Rapport over beregnede dokumentationskrav. Ansøger behøver ikke at medsende alle dokumentationskrav, men denne rapport beskriver de dokumentationstyper som systemet har beregnet som krævede eller frivillige. Rapport over konfliktsøgninger. Konfliktsøgninger vises uanset deres resultat. Konflikter illustreres ved kort med indtegnede objekter og konflikt objekter fra kortlagene., Samlet krydsreferenceliste over bilag og hvilke dokumentationstyper der refererer bilaget. Liste over tidligere indsendelser 2.2 Indsend ansøgning Når ansøgningen er gjort klar skal den sendes. Ansøgningen indsendes som en XML meddelelse samt et antal PDF filer og filer som måtte være vedhæftet af ansøger. Én af PDF filerne er ansøgningsdokumentet som dannes under forsendelsen. Andre filer er uploadet af ansøger. Ansøgning XML meddelelsen indeholder ikke det binære indhold af PDF dokumenter og andre vedhæftede filer. I stedet refererer ansøgning XML meddelelsen til disse filer (kaldet dokumenter) gennem dokument metadata som bl.a. angiver URL hvor de faktiske filer (dokumenterne) kan downloades fra. Dette betyder at afsendelsesprocessen starter med at uploade filer til en upload/download (dokument) service og indlejrer referencer til disse filer i ansøgning XML meddelelsen. Til den fælles kommunale rammearkitektur er der planlagt en komponent Beskedfordeler. Dette er et posthus komponent som fritager afsendende systemer for at skulle kalde direkte til aftagersystemer. Beskedfordeler komponenten forventes ikke at være klar til den planlagte ibrugtagning for Byg og Miljø løsningen og kan følgelig ikke benyttes af BOM. BOM løsningen implementerer sin egen lokale beskedfordeler service for at kunne benytte samme integrationsmønster som vil lette en evt. senere overgang til en fælles beskedfordeler. Schultz Information Side 8 af 47

2.2.1 Ansøgningsdokument og bilag uploades til upload/download service Ansøgningens PDF dokument og eventuelle bilag som er uploadet af ansøgeren er filer. Filer overføres ikke som en del af XML meddelelsen. I stedet uploades filer til en upload/download service hvor modtager senere kan download fra. 2.2.2 Besked sendes til beskedfordeler Når ansøgning XML er klar og dokumenter/filer er uploadet til upload/download service sendes en besked til besked fordeler servicen. Beskedfordeler servicen opbevarer beskeder om indsendte ansøgninger. 2.3 Myndigheds ESDH/fagsystem tømmer beskedfordeler service Myndigheders ESDH/fagsystemer poller regelmæssigt beskedfordeler servicen og forespørger med angivelse af tidspunkt beskeder siden sidst. Beskeder identificerer ansøgning ID som kan benyttes til at hente ansøgningen. 2.3.1 Myndigheds ESDH/fagsystem læser ansøgning Med ID et fra beskedfordeleren kan ESDH/fagsystemet læse ansøgning XML dokumentet fra BOM. XML dokumentet indeholder dokumentreferencer for ansøgning dokumentet og bilag. Disse sendes ikke fysisk med i XML dokumentet. 2.3.2 Myndigheds ESDH/fagsystem downloader ansøgningsdokument og bilag Referencerne fra ansøgning XML dokumentet indeholder URL referencer til hvorfra filerne kan downloades. Disse URL er peger på upload/download servicen. Myndigheden kan vælge at download dokumenterne med det samme eller vente til senere. Dokumenterne bliver liggende på URL en i hele sagens levetid. 2.4 Myndighed besvarer ansøgningen Myndigheden kan nu besvare ansøgningen. Der kan sendes én eller flere besvarelser og hver besvarelse kan indeholde en eller flere ansøgningsdele: Anerkend modtagelse. Benyttes til at informere ansøger om at myndigheden har taget ansvar for ansøgningen. Sæt sagsstatus, frist og initiativpligt. Myndigheden kan sætte sagsstatus efterhånden som sagen behandles af myndigheden. Sagsstatus vises for ansøgeren. Sæt sagsbehandler navn, email, telefonnr. Myndigheden kan vælge at fortælle ansøgeren hvem der behandler sagen med kontaktinformation. Email og telefonnr er frivilligt. Schultz Information Side 9 af 47

Sæt sagsreference. Myndigheden kan fortælle ansøgeren om det sagsnr sagen har fået hos myndigheden. Desuden kan myndigheden registrere et sag UUID som bliver medsendt af BOM ved fremtidige meddelelser vedr. sagen. Sætte sagsbehandler enhed. Myndigheden kan fortælle ansøgeren i hvilken org enhed sagen behandles. Registrere lokale udvidelser. Myndighedens ESDH/fagsystem kan registrere et XML element (incl. underelementer). Dette har ingen betydning for behandlingen i BOM og vises ikke for ansøgeren. Registrerede lokale udvidelser medsendes ved fremtidige meddelelser fra BOM vedr. sagen. Sæt specifik retskilde. Myndigheden kan sætte en specifik retskilde, fx BR10 som sagen behandles under i myndigheden. BOM benytter dette til at vælge den seneste regelkonfiguration der refererer denne retskilde således at regelberegninger udføres ifht. Retskilden. Sæt krav om dokumentationstype. ESDH/fagsystemet kan anmode ansøgeren om at (gen)udfylde et dokumentationskrav. Sammen med identifikationen af dokumentationstypen kan der sendes en instruks. Denne instruks vises som en del af vejledningen når dokumentationstypen udfyldes af ansøgeren. Alle ovenstående besvarelser er frivillige og kan frit kombineres. Besvarelser behøver ikke at være i vekslende med indsendelser fra ansøgeren. Myndigheden kan lave flere besvarelser uden mellemliggende indsendelser fra ansøgeren, og ansøgeren kan foretage flere indsendelser uden mellemliggende besvarelser fra myndigheden. Schultz Information Side 10 af 47

3 Meddelelsesmodeller I dette kapitel beskrives med udgangspunkt i XML skema for meddelelserne den model de repræsenterer. Overordnet er der 3 modelelementer som benyttes i meddelelser: Ansøgning, AnsøgningBesvarelse og Meddelelse. De øvrige elementer er støttelementer. Både de overordnede elementer og støtteelementerne beskrives i det følgende. I dette kapitel beskrives elementer på samme niveau (underafsnit) uanset hvor i XML meddelelserne de forekommer (flere elementer forekommer flere steder). Dette svarer til at elementer generelt er defineret som globale elementer i XML skemaet. 3.1 Elementet Ansoegning Elementet repræsenterer den initielle (første) ansøgning eller en følgende supplerende indsendelse af dokumentation vedrørende en sag. Schultz Information Side 11 af 47

Ansøgningen er identificeret med et entydigt ID (UUID) som tildeles af BOM. Derudover er ansøgningen beskrevet med titel og dato. Schultz Information Side 12 af 47

Ansøgningen indeholder et PDF dokument som er ansøgningens hoveddokument. Andre dokumenter i ansøgningen vil være bilag. Desuden indeholder ansøgningen informationer om sagens status som den ses fra ansøgers hhv. myndighedens perspektiv. 3.2 Elementet Dokument Et dokument kan være et brev, billede, foto, tegning eller en vedhæftet fil i et accepteret MIME format. Alle dokumenter tildeles et entydigt ID (UUID). Dokumenter versioneres ikke. Hvis der rettes i et dokument og det fremsendes igen betragtes det som et nyt dokument. Dokumentet kan dog være vedlagt et dokumentationsbilag som er versioneret. Schultz Information Side 13 af 47

3.2.1 Korrespondance til OIO Dokument Formålet med OIO Dokument 1 standarden er at tilbyde at registrere oplysninger om en organisations dokumenter. Entiteterne i BOM løsningen repræsenterer dokumenter tilhørende ansøgeren og dennes fuldmagtshavere (tilknyttede ansøgere). Dokumenter som ansøgeren producerer og/eller lagrer i BOM løsningen bliver først til dokumenter inden for myndighedens organisation når de fremsendes til myndigheden. Indtil da er dokumenterne ikke tilgængelige for myndigheden. OIO Dokument er designet til at blive anvendt i en ESDH arkitektur sammen med myndighedens fagsystemer. OIO Dokument indeholder attributter til at beskrive egenskaber for dokumenter i offentlige myndigheder (arkivering, offentlig, hjemmel, kassation etc), versionering, redigeringsstatus samt dokument tilstande som sporer fremdriften af behandlingen af dokumentet i myndigheden. Ansøger og myndighed samarbejder ikke om de enkelte dokumenter. Dokumenter i snitfladen ejes enten af myndighed eller af ansøger og er udtryk for en korrespondance. Følgelig skal dokumenter ikke versioneres i snitfladen. Når et dokument fremsendes skal det fastholdes i den version det blev fremsendt i. Hvis der skal genfremsendes dokumentation betragtes dette som et nyt dokument i stedet for en ny version af samme dokument. BOM benytter ikke OIO Dokument som formel model for ansøgerens dokumenter. Imidlertid er BOMs dokumentmodel designet til at svare til OIO dokument hvor det giver værdi. Dette gælder fx brug af begreber som varianter, dokumentdele samt udvalgte attributter som MIME type. At de samme begreber og attributter anvendes forventes at gøre integration til ESDH system som benytter OIO Dokument enklere. BOM skal ikke følge dokumenters livscyklus hos myndigheden og myndigheden skal ikke kunne ændre, slette eller passivere dokumenter som er sendt til ansøgere. Myndigheden kan fremsende nye dokumenter. Myndigheden kan også fremsende en ny version af et dokument som eksisterer hos myndigheden, men for ansøgeren er det et nyt dokument som modtages. Følgelig realiserer snitfladen heller ikke Serviceinterfacet Dokument. 3.3 Elementet BOMSag (Byg og Miljø sag) BOMSag betegner sagen som ansøger ser den. Ansøgerens sag opstår før myndighedens sag: Opdelingen efter enkeltsagsprincippet sker allerede under ansøgerens forberedende arbejde med sit projekt. Først når den første ansøgning indsendes opstår sagen hos myndigheden. Ansøgerens sag og myndighedens sager er dog stadig kun associerede gennem ansøgningen. Det står ansøger frit at lave ændringer i sit projekt/sager det er først når der fremsendes en ny ansøgning at myndigheden får kendskab til disse ændringer. Tilsvarende kan myndigheden ændre sagsstatus, tildele sagsbehandlere, sætte frister mm. 1 http://digitaliser.dk/resource/1567672 Schultz Information Side 14 af 47

BOMSag repræsenterer her et uddrag af ansøgerens projekt/sag når denne fremsender en ansøgning. Informationen skal bruges til reference i myndigheden. Fx kan myndigheden se hvad ansøgerens overordnede projekt hedder så sagsbehandler evt. kan sikre sig at de taler om det samme projekt. BOMSagID er UUID for BOM sagen som ansøgningen vedrører. SagId et ændrer sig ikke og kan bruges til at relatere senere ansøgninger til samme sag. Når en ansøger opretter et projekt i BOM kan systemet ud fra regler opdele projektet i flere delprojekter. Disse delprojekter kaldes i BOM for sager fordi opdelingen sker af hensyn til myndighedernes sagsbehandling således at hver sag har netop én sagstype. En BOM Sag må ikke forveksles med den tilsvarende sag som den måtte optræde i myndighedens ESDH og/eller fagsystem. En BOM Sag oprettes så den repræsenterer Ansøgers billede af sagsbehandlingen hos myndigheden. En væsentlig del af BOMProjekt er PartList. Denne beskriver hvilke parter der er på sagen og deres rolle. 3.4 Elementet PartListe PartListe beskriver de parter der indgår i sagen. Parter er fx ejer og de personer som ejer måtte have givet fuldmagt til projektet/sagen. Schultz Information Side 15 af 47

Hver part har en entydig nøgle PartID (UUID). Nøglen er fælles for alle sager under samme projekt (det er samme part). Derudover beskrives en part med CVR nummer, navn, organisationsnavn, adresse, email og telefonnr. En part har også en rolle på projektet. Denne beskrives som Ejer, Rådgiver, Fagspecialist (håndværker) eller Andet. Hvis Andet angives er PartAndenRolleNavn udfyldt med beskrivelse af rollen. 3.5 Elementet Dokumentation Dokumentation elementet er en væsentlig del af Ansøgning elementet. Dokumentation elementet samler dokumentationen (som modsætning til referenceinformation) under ét element i ansøgningen. Schultz Information Side 16 af 47

Dokumentation elementet selv er delt op i en række underelementer som beskrives i de følgende afsnit. 3.6 Elementet TidligereAnsoegningListe Hvis ansøgningen er en indsendelse af supplerende dokumentation findes der tidligere ansøgninger vedr. sagen. I så fald medtages en liste over de tidligere ansøgningers AnsoegningID og AnsoegningDato. 3.7 Elementet AktivitetListe Ansøgeren har udvalgt et antal aktiviteter som alle falder under samme sagstype. Listen over aktivitetstyper vedlægges ansøgningen så sagsbehandleren kan se hvilke aktiviteter der er udvalgt og vurdere om det passer med fx beskrivelserne. Schultz Information Side 17 af 47

Hvis de korrekte aktiviteter ikke er udpeget af ansøgeren kan dokumentationskravene være beregnet på et forkert grundlag. 3.8 Elementet DokumentationBilagListe Dokumentation for hver af de kendte dokumentationstyper samles og vedlægges som bilag i en DokumentationBilagListe. Hvert element i listen dokumenterer én dokumentationstype. Listen indeholder kun dokumentation for en dokumentationstype én gang (dermed benyttes dokumentationstype ID sammen med ansøgning ID som nøgle for hvert element). Schultz Information Side 18 af 47

Et dokumentationsbilag henviser til dokumentationstypen gennem DokumentationTypeID. VersionIndikator fortæller om samme dokumentationstype har været fremsendt i en tidligere ansøgning på samme sag. Hver gang dokumentation for en dokumentationstype fremsendes tælles versionen én op. Første version har nummer 1. Et Dokument er vedlagt som er dokumentationen printet i PDF format. BilagReferenceListe er krydsreferencer toil FilBilag som er vedlagt ansøgningen. Dokumentation for en dokumentationstype kan henvise til et eller flere filbilag som er binære filer som ansøgeren uploader til BOM løsningen. Samtidigt kan et filbilag benyttes af dokumentationen for flere dokumentationstyper. Filbilagene er vedhæftet Dokumentation elementet og de enkelte elementer i BilagReferenceListe liste henviser ved filbilagets ID. 3.9 Elementet ObjektListe En ansøgning vedrører altid en række objekter som er eksisterende matrikler, bygninger, konstruktioner, enheder eller nye objekter som der søges om tilladelse til at opføre/konstruere. Objekterne som ansøgningen vedrører samles i en ObjektListe. Schultz Information Side 19 af 47

De enkelte elementer i objektlisten er sagsobjekter. Hvert sagsobjekt har et entydigt UUID SagObjektId. Sagobjektet er så delt op i Matrikel, Bygning, Enhed og Skitse objekter. 3.10 Elementet Matrikel Matrikel benyttes når der fx opføres en ny bygning på en matrikel. De matrikler som er berørt af aktiviteterne sendes med ansøgningen. Schultz Information Side 20 af 47

Matriklen identificeres med matrikelnummer (LotIdentifier). Hvis matriklen har en adgangsadresse angives denne i AddessAccess. 3.11 Elementet Bygning Hvis ansøgningen er fx ombygning eller nedrivning/sløjfning af en eksisterende bygning/konstruktion identificeres bygningen med et Bygning element. Schultz Information Side 21 af 47

Bygningens matrikel angives i LotIdentifier. Bygningens adgangsadresse (hvis den findes) angives i AddressAccess. Bygningens bygningsnummer på matriklen angives i BuildingIdentifier. 3.12 Elementet Enhed Hvis ansøgningen vedrører ombygning eller lignende af en eksisterende enhed i en eksisterende bygning angives dette med et Enhed element. Schultz Information Side 22 af 47

Enheden identificeres med AddressSpecific som er enhedens dør adresse. Enhedens bygnings matrikel angives i LotIdentifier. 3.13 Elementet Skitse Når ansøgningen vedrører bygning eller opførelse af ny bygning/konstruktion/anlæg er der visse typer aktiviteter som kræver at ansøgeren skitser de nye objekters placering. Sådanne skitseobjekter sendes med som Skitse elementer. Schultz Information Side 23 af 47

Et skitseobjekt kan berøre flere matrikler (fx jordvarmeanlæg). Listen af berørte matrikler sendes i LotIdentifier. Derudover sendes der et GML objekt med som kan være et polygon, rektangel, cirkel eller en liste af punkter. 3.14 Elementet FilBilagListe En ansøger kan vedhæfte dokumentation i form af Word dokumenter, billeder, CAD tegninger m.v. Disse betegnes som filbilag. Fordi sådanne filer kan indgå som dokumentation i flere dokumentationstyper er der en mange-til-mange relation imellem dokumentationsbilag og filbilag. Derfor er filbilagslisten placeret sideordnet med dokumentationsbilagslisten. Hvert element fra dokumentationsbilagslisten (hvert dokumentationsbilag) kan referere til nul eller flere filbilag ved FilBilagID. Schultz Information Side 24 af 47

Filbilaget er identificeret med FilBilagID som er en entydig ikke-informationsbærende nøgle. Hvert filbilag har en TitelTekst som er udledt af ansøgerens titel for filen som igen er udledt (foreslået) ud fra filnavnet på upload tidspunktet. Hvis en ny fil uploades med samme navn betragtes den nye fil som en ny version af den samme filbilag. I det tilfælde tildeles den nye filbilag det samme FilBilagID således at alle referencer automatisk peger på den nye filbilag. Ved samme lejlighed tælles VersionIndikator én op for at indikere at det er en ny version. Myndigheden kan benytte FilBilagID og VersionIndikator til at afgøre om det er en ny fil der modtages eller en ny version af en tidligere modtaget fil. 3.15 Elementet DokumentationKravListe BOM løsningen beregner dokumentationskrav ud fra et sæt regler som bl.a. kan lave konfliktsøgning for at afgøre om der skal redegøres for fx afstandskrav. Ved regelberegningen fastlægges dokumentationskravene til sagen. De beregnede dokumentationskrav rapporteres med alle ansøgninger som indsendes. Schultz Information Side 25 af 47

Hvert dokumentationskrav identificeres med dokumentationstypens DokumentationTypeID. Desuden angives den beregnede styrke af kravet i KravStyrke. Styrken kan være Undtaget, Frivilligt, Obligatorisk. En sagsbehandler kan sætte krav til dokumentationstyper eksplicit gennem en opdatering fra myndigheden. KravAktoer angiver om det er BOM løsningen (ITSystem) eller sagsbehandleren (Myndighed) som har sat kravet. 3.16 Elementet KonfliktSoegningResultatListe Ansøgningen indeholder en liste over de konfliktsøgninger BOM ud fra reglerne i systemet har foretaget, samt deres resultat. Konfliktsøgninger er repræsenteret ved konfliktprofilens KonfliktProfilID. Resultatet af konfliktsøgningen er en liste af konfliktende objekter fra sagen. Disse objekter kan være indtegnede objekter, matrikler eller bygninger. Schultz Information Side 26 af 47

3.17 Elementet MyndighedSag På BOM sagen opbevares status og referenceinformation for myndighedens sag. Denne information medsendes når der indsendes ansøgninger eller meddelelser. Elementet MyndighedSag vil ved første indsendelse kun have udfyldt elementet SagStatus. De øvrige elementer på elementet MyndighedSag vil først være udfyldt når myndigheden via opdateringer har angivet værdier for disse elementer. Bemærk at ansøgeren kan foretage flere indsendelser efter hinanden før myndigheden opdaterer fx reference til myndighedens sag, behandlende enhed, sagsbehandler, retskilder eller lokale udvidelser. Schultz Information Side 27 af 47

3.18 Elementet SagReference SagReference indeholder referenceinformation om myndighedens sag. BrugervendtNoegle vises til ansøgeren som myndighedens sagsnummer på sagen. 3.19 Elementet SagStatus Dette element indeholder information om sagens status hos myndigheden. Schultz Information Side 28 af 47

SagStatusKode benytter BOMs kodeliste for sagsstatus. BOMs sagsstatus forventes at være en delmængde af alle myndigheders status således at der kan etableres en mange-til-en korrespondance mellem myndighedernes interne status og BOMs sagsstatus. Når sagsstatus registreres skal det også registreres hvem der har initiativpligten. Dette fremgår af elementet InitiativPligt som er Ansøger eller Myndighed. 3.20 Elementet BehandlesAfEnhed Myndigheden kan oplyse ansøgeren om hvilken organisatorisk enhed hos myndigheden der behandler sagen. Dette er ikke obligatorisk. 3.21 Elementet Sagsbehandler Myndigheden kan oplyse ansøgeren om hvilken sagsbehandler der har fået tildelt sagen hos myndigheden. Dette er ikke obligatorisk. Schultz Information Side 29 af 47

3.22 Elementet BehandlingRetskilde Hvis retskilden er afvigende fra det som blev beregnet af BOM kan myndigheden sætte en anden retskilde. RetskildeKode er fra BOMs kodeliste over retskilder. En retskilde kan fx være BR10 eller BR13, en lovidentifikation eller en i en lov. Hvis retskilden sættes af myndigheden vil BOM løsningen benytte det seneste regelsæt som refererer til retskilden. 3.23 Elementet LokalUdvidelse Myndigheders ESDH/fagsystemer kan have behov for at registrere referenceinformation i BOM løsningen som derefter medsendes alle supplerende ansøgninger/meddelelser vedrørende sagen. LokalUdvidelse er et element hvor myndighedens systemer kan registrere en vilkårlig XML struktur. LokalUdvidelse vises aldrig for ansøgerne. 3.24 Elementet AnsoegningBesvarelse Elementet benyttes til at besvare meddelelser og ansøgninger. Ud over at kunne skrive beskeder kan elementet benyttes til at lave et antal opdateringer. Schultz Information Side 30 af 47

Schultz Information Side 31 af 47

3.25 Elementet MyndighedAfsender Den afsendende myndighed og eventuel hvilken del af myndigheden der skal stå som afsender. 3.26 Elementet AnsoegerModtager Hvis besvarelsen er rettet mod én bestemt af parterne på sagen angives den primære modtager her. 3.27 Elementet MeddelelseTekst En tekst indeholdende en meddelelse fra sagsbehandler/myndighed til ansøger. Denne tekst er ikke formatteret som en skrivelse og vises direkte til ansøgeren uden at denne behøver at benytte en PDF læser. 3.28 Elementet AnsoegningModtaget Anderkender overfor ansøger at ansøgningen er modtaget. Kan frivilligt indikere til hvilken del af organisationen sagen er visiteret. Schultz Information Side 32 af 47

3.29 Elementet SagReferenceOpdatering Dette element medsendes når sag er oprettet hos myndigheden. Elementet indeholder reference til myndighedens sag ID, brugervendt nøgle samt dato. 3.30 Elementet SagStatusOpdatering Dette element medsendes for at indikere et statusskift på myndighedssagen. Med dette element kan myndigheden styre status i BOM, frist og initiativpligt. 3.31 Elementet BehandlingEnhedOpdatering Benyttes til at informere ansøger om hvilken organisatorisk enhed hos myndigheden der er ansvarlig for behandling af sagen. Schultz Information Side 33 af 47

3.32 Elementet SagsbehandlerOpdatering Benyttes til at informere ansøger om hvilken sagsbehandler hos myndigheder der er ansvarlig for behandling af sagen. 3.33 Elementet LokalUdvidelseOpdatering Myndigheden kan registrere vilkårlig XML på dette felt på BOM sagen. Efterfølgende vil elementet blive vedhæftet alle meddelelser og ansøgninger fra BOM vedrørende sagen. Schultz Information Side 34 af 47

3.34 Elementet RetskildeOpdatering Når elementet er angivet sættes retskilden for BOM sagen til den angivne retskilde. Retskilden er synlig for ansøgeren og betinger desuden hvilket regelsæt version der arbejdes efter. BOM benytter det seneste regelsæt som refererer til retskilden. 3.35 Elementet DokumentationKravOpdatering Sætter eksplicit krav om at en dokumentationstype udfyldes eller genudfyldes (ved mangelfuld udfyldelse). 3.36 Elementet InstruktionTekst Instruktionstekst som vises til ansøgeren under udfyldelse af dokumentationskravet. Benyttes fx til at instruere ansøger i hvori manglen bestod. Schultz Information Side 35 af 47

3.37 Elementet KravStyrke Styrken af kravet. Myndighed kan tilføje et krav som frivilligt eller obligatorisk. Myndigheden kan *fjerne* et dokumentationskrav som ellers er beregnet ud fra regler ved at angive "Undtaget". Schultz Information Side 36 af 47

4 Serviceinterfacet Sagsbehandling 4.1 Anvendelse Operationerne som snitfladen udstiller giver ESDH systemer og fagsystemer mulighed for at hente ansøgninger, liste/forespørge på ansøgninger, ændre status og frister samt kommunikere med ansøgerne gennem Byg og Miljø løsningen. 4.2 LaesAnsoegning Denne operation bruges til at hente en enkelt Ansøgning når ID er kendt. 4.2.1 Input Ansøgning ID: Ansøgning ID skal først være fundet enten ved at det fremgår af en besked/hændelse som integrationssystemet reagerer på eller ved at integrationssystemet har forespurgt ved andre operationer på denne service. 4.2.2 Output Et Ansoegning element. Se afsnit 3.1. 4.2.3 Fejlsituationer (De konkrete status/fejlkoder fastlægges ifm udviklingsforløbet). Ansøgningen findes ikke Myndigheden har ikke ret til at læse ansøgningen (ikke behandlende myndighed) 4.3 BesvarAnsoegning Denne operation benyttes til at registrere svar fra myndigheden på en ansøgning. 4.3.1 Input Et AnsoegningBesvarelse element Schultz Information Side 37 af 47

4.3.2 Output Statuskode 4.3.3 Fejlsituationer (De konkrete status/fejlkoder fastlægges ifm udviklingsforløbet). Ansøgningen der refereres til findes ikke Myndigheden har ikke ret til at behandle ansøgningen. Dokument som er referereret i besvarelsen er ikke uploadet til upload service Formatfejl/værdifejl i værdi (fx GUID værdi følger ikke formatet eller frist i fortiden, ukendt statuskode, retskilde findes ikke, myndighed/organisatorisk enhed findes ikke). Fejlen vil være forklaret i tekst Dokumentationstype findes ikke i den aktuelle udgave af reglerne. 4.4 HentMeddelelse Henter en besked som ligger klar fra Ansøger(ne). 4.4.1 Input Meddelelse ID (modtaget fra beskedfordeler) 4.4.2 Output Elementet Ansoegning. 4.4.3 Fejlsituationer (De konkrete status/fejlkoder fastlægges ifm udviklingsforløbet). Meddelelsen der refereres til findes ikke Myndigheden har ikke ret til at læse ansøgningen. 4.5 LaesAnsoegningOversigt Henter en liste af Ansøgning ID er ud fra specifikation af det ønskede udvalg. Der kan begrænses i tidsperiode (ansøgning oprettet) samt sagsområder og sagstyper. Schultz Information Side 38 af 47

4.5.1 Input Myndighed ID. Skal udfyldes. Fra dato/tid og Indtil dato/tid: Filtrerer ansøgninger til myndigheden så kun ID for de ansøgninger der er sendt til beskedfordeleren i det angivne tidsrum returneres. Skal udfyldes. Sagsområde liste (liste af koder for sagsområder). Kun ID for ansøgninger som er tilhører sagsområdet (ex Miljø ) returneres. Skal udfyldes. Sagstype liste (liste af GUIDs for sagstyper). Kun ID for ansøgninger med sagstypen returneres. Frivilligt; hvis ikke udfyldt returneres ansøgninger for alle sagstyper. 4.5.2 Output Liste af Ansøgning ID. Kan benyttes til at læse ansøgningen fra LaesAnsøgning operationen. 4.5.3 Fejlsituationer Myndighed har ikke rettighed til at læse ansøgninger for det angivne Myndighed ID Myndighed har ikke rettighed til sagsområde. Sagområde, sagstype eller myndighed er ukendt eller anden parameterfejl. 4.6 LaesMeddelelseOversigt Henter en liste af besked ID er ud fra specifikation af det ønskede udvalg. Der kan begrænses i tidsperiode (ansøgning oprettet) samt sagsområder og sagstyper. 4.6.1 Input Myndighed ID. Skal udfyldes. Fra dato/tid og Indtil dato/tid: Filtrerer ansøgninger til myndigheden så kun ID for de meddelelser der er sendt til beskedfordeleren i det angivne tidsrum returneres. Skal udfyldes. Sagsområde liste (liste af koder for sagsområder). Kun ID for meddelelser som vedrører en sag under sagsområdet (ex Miljø ) returneres. Skal udfyldes. Sagstype liste (liste af GUIDs for sagstyper). Kun ID for meddelelser vedr. sager med sagstypen returneres. Frivilligt. Hvis ikke udfyldt returneres alle sagstyper. 4.6.2 Output Liste af Ansøgning ID. Kan benyttes til at læse ansøgningen (med meddelelserne i) fra LaesAnsøgning operationen. Schultz Information Side 39 af 47

4.6.3 Fejlsituationer Myndighed har ikke rettighed til at læse ansøgninger for det angivne Myndighed ID Myndighed har ikke rettighed til sagsområde. Sagområde, sagstype eller myndighed er ukendt 4.7 WSDL Udkast til WSDL er vedlagt designrapporten som bilag 12a Schultz Information Side 40 af 47

5 Serviceinterfacet Download Dokument Download Dokument serviceinterfacet benyttes til at downloade fysiske filer der er refereret som dokumentdele i ansøgninger. Serviceinterfacet er et REST interface som besvarer http GET forespørgsler. I elementet Del under Dokument (se afsnit 3.2) forekommer en attribut IndholdTekst som angiver en absolut URL den binære repræsentation af dokumentet på Download Dokument servicen. Del angiver også MIME typen. Ved download af dokumentdelen fra Download Dokument vil samme MIME type blive angivet i response header. 5.1 Download endpoint Alle dokumenter har en entydig adresse på Download Dokument serviceinterfacet. Dokumentets UUID benyttes som grundlag for den entydige adresse. Service aftagere skal ikke selv sammensætte adressen. Den absolutte og fuldstændige adresse tages fra den pågældende dokumentdel og benyttes direkte som adresse til at downloade dokumentdelen. 5.2 Autentificering Service Aftager skal identificere sig med et client certificate i som del af http kommunikationen. Certifikatet skal være et FOCES eller VOCES certifikat og certifikatets serialnumber skal være registreret for myndigheden i BOM løsningen. 5.3 Levetid af dokumenter Dokumentdele som er dele af en ansøgning eller af ansøgning bilag er tilgængelige umiddelbart når ansøgningen fremsendes. Download URI er vedbliver at være tilgængelige indtil projektet/sagen slettes i BOM løsningen. Service aftager kan downloade dokumentdele umiddelbart efter modtagelse af ansøgningen eller på ethvert tidspunkt derefter. Sager i BOM slettes først efter en given periode (standard 3 år) efter at myndigheden har sat status til afsluttet. BOM er ikke arkiv for dokumenter. Det er Service Aftagers ansvar at journalisere og arkivere al korrespondance. 5.4 URI mønster Dokumenter adresseres med følgende mønster: https://<server>/dokumentdele/<dokumentdel-uuid> Schultz Information Side 41 af 47

hvor <dokumentdel-uuid> er dokumentdelens ikke informationsbærende entydige nøgle (UUID). Service Aftager skal aldrig selv konstruere disse URIer. De modtages som absolutte URI i dokument dele fra Sagsbehandling serviceinterfacet. 5.5 Fejlsituationer Serviceinterfacet er baseret på REST og standard http statuskoder anvendes. Der henvises til beskrivelsen af http protokollen for specifikke returkoder. Herunder listes udvalgte statuskoder som kan have særlig betydning i BOM løsningen. Statuskode Betydning 401 Kalder har ikke rettighed til at læse den pågældende dokumentdel. Dette kan skyldes flg. situationer: Kalder har ikke autentificeret sig med et FOCES/VOCES certifikat som del af kommunikationen. FOCES/VOCES certifikat er ikke registreret for myndigheden i BOM løsningen. FOCES/VOCES certifikat er udløbet eller på spærreliste. Kaldende myndighed forsøger at downloade et dokument fra et område som indeholder dokumenter som er sendt til en anden myndighed. 404 Dokumentet er ikke kendt i BOM løsningen. 405 Kalder benytter et http metode som ikke er tilladt. Kun GET, HEAD er tilladt på Download Dokument serviceinterfacet 200 OK. http response indeholder dokumentdelen. Schultz Information Side 42 af 47

6 Serviceinterfacet Upload Dokument Upload Dokument serviceinterfacet benyttes til at uploade dokumentdele til BOM så de kan refereres fra besvarelser der efterfølgende skabes i Sagsbehandlng servicen. Serviceinterfacet er et REST interface som besvarer http PUT, GET og HEAD forespørgsler. Hver myndighed tildeles et uploadområde hvor kun myndigheden har adgang. Myndigheden kan her uploade dokumenter med PUT requests. GET og HEAD requests kan benyttes til at verificere uploads. Service Aftager vælger selv et GUID som dokumentdele gemmes under. Det er Service Aftagers ansvar at referere til denne GUID i det senere kald til Sagsbehandler servicen som importerer dokumentdelen. 6.1 Levetid Dokumenter som uploades til denne service forventes at blive refereret i et efterfølgende kald til Sagsbehandling servicen. Dokumenter som er uploadet til servicen slettes automatisk fra uploadområdet efter 24 timer. Dokumenter som er uploadet til upload servicen slettes automatisk fra upload området når de er blevet importeret i en besvarelse en ansøger. Samme fil kan ikke benyttes i flere besvarelser til ansøgere. 6.2 Autentificering Service Aftager skal identificere sig med et client certificate i som del af http kommunikationen. Certifikatet skal være et FOCES eller VOCES certifikat og certifikatets serialnumber skal være registreret for myndigheden i BOM løsningen. 6.3 Fejlsituationer Serviceinterfacet er baseret på REST og standard http statuskoder anvendes. Der henvises til beskrivelsen af http protokollen for specifikke returkoder. Herunder listes udvalgte statuskoder som kan have særlig betydning i BOM løsningen. Statuskode Betydning 401 Kalder har ikke rettighed til at skrive den pågældende dokumentdel. Dette kan skyldes flg. situationer: Kalder har ikke autentificeret sig med et FOCES/VOCES certifikat som del af kommunikationen. FOCES/VOCES certifikat er ikke registreret for myndigheden i BOM løsningen. FOCES/VOCES certifikat er udløbet eller på spærreliste. Kaldende myndighed forsøger at uploade et dokument til et område som er reserveret til en anden myndighed Schultz Information Side 43 af 47

Statuskode Betydning 404 Området hvortil der forsøges uploadet er ikke kendt. 405 Kalder benytter et http metode som ikke er tilladt. Kun PUT, GET, HEAD er tilladt på Upload Dokument serviceinterfacet 200 OK. Schultz Information Side 44 af 47

7 Sikkerhed 7.1 Sagsbehandling servicen OWSA-T 2 benyttes til at beskytte Sagsbehandling servicen, med den afvigelse at også både FOCES og VOCES certifikater accepteres til autentifikation af Service Aftager. HTTPS benyttes til transport og sikkerhed. Transportlaget krypterer data og overfører certifikat mellem Service Udbyder og Service Aftager til autentifikation. I Organisation komponenten sættes SerialNumber for myndighedens funktionscertifikat. Ved kald af servicen kontrolleres det at kalderen autentificerer sig ved hjælp af et FOCES/VOCES certifikat, at certifikatet er gyldigt og ikke på spærreliste. Certifikatets SerialNumber benyttes til at identificere den tilsvarende BOM Myndighed. I organisation komponenten konfigureres det på myndigheden om denne benytter denne webservice eller sagsbehandler website til sagsadministration. Når der benyttes webservice kan der ikke sagsbehandles på sagsbehandler website. Kun hvis myndigheden er konfigureret til at benytte webservice til sagsadministration tillades kald til webservicen. Myndigheden kan administrere de sagsområder for de myndigheder som myndighedens organisatoriske enheder er konfigureret til at behandle, for de kombinationer af myndigheder og sagsområder som hver organisatorisk enhed er sat til at behandle. 7.2 Dokument upload / download service HTTPS benyttes til transport og sikkerhed på dokument upload/download services. Service Aftager skal autentificere med et FOCES/VOCES certifikat. Transportlaget krypterer data og overfører certifikat mellem Service Udbyder og Service Aftager til autentifikation. Samme VOCES/FOCES certifikat som anvendes til Sagsbehandling Webservice benyttes til upload/download services. Upload service kan kun benyttes hvis myndigheden er sat til at benytte webservice til sagsbehandling. Download service kan benyttes af alle myndigheder som er sat til enten webservice sagsbehandling eller website sagsbehandling. 2 http://digitaliser.dk/resource/4349 Schultz Information Side 45 af 47

8 Versionering Fastlægges på et senere tidspunkt. Schultz Information Side 46 af 47

9 Ændringslog Dato Version Beskrivelse af ændringer Initialer 2013-04-06 0.1 USE 2013-04-16 0.7 Tilrettet til designrapport. Bemærk, grænsefladen er ikke færdigdesignet. USE 2013-04-24 0.8 Sikkerhed USE 2013-04-25 0.9 Nye services: upload download, beskedfordeler USE 2013-04-28 0.95 Udførlig dokumentattion af skemaelementer USE 2013-04-29 1.0 AnsoegningBesvarelse USE 2013-05-21 1.1 Udvidet afsnit 2 med forretningsmæssig beskrivelse USE 2013-06-11 1.2 Fjernet tomt (duplikat) Dokument afsnit, beskrevet tekst USE 2013-06-21 1.3 Udvidet operationer afsnittet USE Schultz Information Side 47 af 47