Standard IT- og Telestyrelsen København den 17. december 2007

Størrelse: px
Starte visningen fra side:

Download "Standard IT- og Telestyrelsen København den 17. december 2007"

Transkript

1 Standard IT- og Telestyrelsen København den 17. december 2007 FESD-standardisering FESD Datafølgeseddel. Protokol Version 1.0

2 Kolofon: FESD-standardisering. FESD Datafølgeseddel. Protekol. Version 1.0 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Forslag til FESD-standarder udarbejdes af IT- og Telestyrelsen, Datastandardiseringskontoret, FESDstandardiseringsgruppen i samarbejde med de tre FESD-leverandører Software Innovation A/S, Accenture I/S og CSC mark A/S. Kontaktperson i FESD-standardisering: Projektleder Palle Aagaard, Mailadresse Telefon (direkte) Accenture A/S Arne Jacobsens Allé København S Telefon: Web-adresse: CSC mark A/S Retortvej København V Telefon: Web-adresse: Software Innovation A/S Nærum Hovedgade 10 DK-2850 Nærum Telefon: Web-adresse: Ministeriet for Videnskab, Teknologi og Udvikling IT- og Telestyrelsen Datastandardiseringskontoret National IT and Telecom Agency Ministry of Science, Technology and Innovation Holsteinsgade 63 DK-2100 København Ø Telf Fax / 28

3 Indholdsfortegnelse 1. Forord DEL A FESD Datafølgeseddel Indledning Sammenhæng med DOKFORM og FESD Packet standarderne Formål Afgrænsning Del B Forretningsarkitektur Datafølgesedlens anvendelse Ansvar Protokoller Web-Service til modtagelse af datafølgeseddel Transaktionshåndtering Gentagen oversendelse / opdatering Unik identifikator for sags- og dokumentobjekter Registrering af sags- og dokumentparter Datafølgesedlens struktur Anvendelse af myndigheds- eller sektorspecifikke udvidelser af skemaet Elektronisk signering og kryptering af datafølgeseddel Del C Beskrivelse af skema Beskrivelse af klasser Elementet følgeseddel meta Elementet Sag meta Beskrivelse af elementet SagsPart meta Elementet JournalPost Beskrivelse af elementet JournalpostPart meta Beskrivelse af elementet Dokument meta Beskrivelse af elementet DokumentObjekt Elementet Følgeseddel Signatur Bilag A Anvendte typer i FESD-modellerne integer boolean Identifikationstyper char.27 3 / 28

4 1.2.5 date, datetime og time string float.28 4 / 28

5 1. Forord Den offentlige sektors IT-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Derfor arbejdes der målrettet på at få gennemført fælles standarder for elektronisk sags- og dokumenthåndtering - den såkaldte FESD-standard. Målet med standardiseringsarbejdet er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kernefunktionalitet, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kernefunktionalitet skal sikre: at der kan foretages sagsbehandling på tværs af flere organisationer at myndigheder, der arbejder med åbne sager, kan lægges sammen at der kan flyttes opgaver mellem forskellige myndigheder I forlængelse af FESD-projektkonkurrencen, som havde sin afslutning primo 2004, og hvor der blev fundet tre FESD-leverandører, blev det i forbindelse med kontraktforhandlingerne besluttet at starte en standardiseringsproces den såkaldte FESD-standardisering. For at sikre interoperabiliteten, både mellem ESDH-systemer og til andre systemer, men også så tredjepart kan udvikle moduler til systemet, blev det anset for afgørende, at der udvikles en fælles offentlig datamodel samt andre standarder på ESDH-området. Koordinering af FESD-standardiseringen er efterfølgende lagt i IT- og Telestyrelsen (ITST). Den konkrete udarbejdelse af forslag/udkast til standarder foregår i et samarbejde mellem de tre FESD-leverandører og en FESD-standardiseringsgruppe i ITST. Arbejdet med forslag/udkast til standarder tager udgangspunkt i Noark 4 s datamodel og databeskrivelser samt leverandørernes løsninger. Standarderne kan afvige fra Noark 4 på de områder, hvor det er nødvendigt for at understøtte dansk forvaltningspraksis, eller hvor parterne i FESD-standardiseringen kan opnå enighed om en afvigelse. Udkast/forslag sendes herefter i offentlig høring i ca. 1 måned. FESD-standardiseringsgruppen tilretter og færdiggør på baggrund af høringen de endelige Forslag til standarder. Standardforslagene forelægges herefter OIO-Datastandardiseringskomiteen til godkendelse. Efter den samlede godkendelse bliver standarderne således offentliggjort og indgår i IT- og Telsestyrelsens OIO-Katalog, som indeholder en oversigt over godkendte og anbefalede standarder til digital forvaltning i det offentlige. I standarden kan forekomme brug af særligt ordvalg. Følgende termer anvendes konsekvent i den følgende betydning: skal / obligatorisk : betyder, at den nævnte metode/element/mulighed/etc. skal benyttes eller skal forefindes dvs. må ikke udelades. må ikke : betyder, at den nævnte metode/element/mulighed/etc. ikke må forefindes eller må ikke benyttes. bør / anbefalet : betyder, at det i høj grad anbefales, at den nævnte metode/element/mulighed/etc. benyttes eller forefindes. Der skal være tungtvejende grunde til at udelade. kan / optionel : betyder, at den nævnte metode/element/mulighed/etc. er en valgmulighed og derfor valgfri at medtage. 5 / 28

6 2. DEL A FESD Datafølgeseddel 1.1 Indledning Standarden FESD Datafølgeseddel i det følgende betegnet som datafølgesedlen - angiver struktur og indhold for en datafølgeseddel der kan benyttes til oversendelse af sags- og dokumentinformation mellem myndigheder, uden forudgående aftale. Datafølgesedlen kan sidestilles med en almindelig brevforsendelse mellem myndigheder, med den forskel at datafølgesedlen giver den modtagende part alle relevante oplysninger om sags, dokument og part i elektronisk form, som grundlag for registrering Datafølgesedlen er en videreudvikling af FESD Packet, som gav mulighed for at sende dokumenter mellem myndigheder, baseret på DOKFORM standarden i forhold til beskrivelse af dokumenterne. Datafølgesedlen giver også mulighed for at medsende information om sag og part, og udvider dermed anvendelsesmulighederne i forhold til FESD Packet. Datafølgesedlen tager indholdsmæssigt udgangspunkt i FESD Datamodel, og sags- og parts- og dokumentinformation er således umiddelbart sammenligneligt med FESD Datamodel. 1.2 Sammenhæng med DOKFORM og FESD Packet standarderne FESD Packet standarden specificerer hvorledes dokumenter sendes mellem myndigheder, baseret på DOK- FORM eller udvekslingskernen som den også kaldes. FESD Packet er begrænset til at sende dokumenter via e- post, og havde dermed en række begrænsninger i forhold til såvel det indholdsmæssige, som metoder til at sende. Datafølgesedlen giver mulighed for at benytte andre protokoller end SMTP ( ), og giver desuden mulighed for at sende information om sag og part i tilknytning til dokumenterne. Forsendelser med datafølgesedlen, beriger således forsendelsen i et større omfang end FESD Packet gav mulighed for. Datafølgesedlen afløser FESD Packet, og udgør det der i FESD Packet standarden betegnes som FASE 2. Der vil ikke ske yderligere revisioner af FESD Packet, ligesom der sandsynligvis heller ikke vil blive udarbejdet flere revisioner af DOKFORM (Udvekslingskernen) Formål Formåled med standarden FESD Datafølgeseddel, er at give et grundlag for fremsendelse af sager og dokumenter fra en myndighed til en anden, og dermed understøtte behovet for sagsbehandling på tværs af myndighederne i den offentlige forvaltning Afgrænsning Standarden for FESD Datafølgeseddel har sit udgangspunkt i FESD Packet standarden, og i FESD kontraktens krav om understøttelse af efølgeseddel såvel ved afsendelse som modtagelse af dokumenter i FESD systemet. Standarden baserer sig ikke på eller har sit udgangspunkt i den norske NOARK-4 standard, som det er tilfældet for andre FESD standarder. Standarden stiller ikke eksplicitte krav til implementering af forretningslogik, til understøttelse af udveksling baseret på datafølgesedlen, men FESD kontraktens krav om at FESD systemet skal kunne danne og afsende en e-følgeseddel baseret på udvekslingskernen, samt modtage og anvende samme som registreringsgrundlag, vil være gældende i forhold til datafølgesedlen. Anvendelse af de forskellige protokoller, beskrevet i Del B afsnit 1.5 vil variere fra leverandør til leverandør, og der kan kun forventes en understøttelse, svarende til den eksisterende, baseret på udvekslingskernen. 6 / 28

7 3. Del B Forretningsarkitektur 1.3 Datafølgesedlens anvendelse Datafølgesedlen giver mulighed for at en myndighed kan sende sager og dokumenter til en anden myndighed, i elektronisk form. Forsendelsen indeholder, udover de elektroniske dokumenter, de metadata den afsendende myndighed har registreret i sit FESD ESDH system, og giver således den modtagende myndighed et grundlag for registrering af tilsvarende metadata i sit FESD ESDH system. Dermed opnår den modtagende myndighed dels en større præcision i sin registrering, dels en effektivitetsgevinst idet en tidligere registrering genbruges. Det er vigtigt at bemærke, at der i forvaltningsmæssig forstand er tale om forskellige instanser af hhv. sager og dokumenter hos den afsendende og modtagende myndighed. Nedenstående figur illustrerer den forretningsgang, datafølgesedlen er tænkt anvendt: Fig. 1 Forretningsgang for oversendelse af datafølgeseddel En forbindelse med et sagsforløb, som indvolverer to myndigheder, udfører myndighed A sin sagsbehandling til et givent punkt, og sagen skal herefter behandles i myndighed B. Myndighed A danner en datafølgeseddel indeholdende information om sagen, sagens dokumenter og de elektroniske dokumenter, og sender denne via en af de mulige protokoller til myndighed B. Myndighed B anvender det fremsendte som grundlag for registrering af sagen/dokumenterne i sit FESD ESDH system. 1.4 Ansvar Det er den afsendende part som har ansvaret for oversendelsen, herunder modtagelsen, til den modtagende part. Det vil sige at det er den afsendende part der skal sikre at den oversendte information er modtaget og vil blive behandlet som ønsket. Standarden giver ikke mulighed for f.eks. anmodning om hvittering for modtagelse eller behandling. Den afsendende part må foretage en implementering af datafølgesedlen, som i nødvendigt omfang sikrer afsendelse/modtagelse i henhold til de krav der gælder for kommunikationen mellem de to parter. Dette kan ske gennem valg af protokol og evt. gennem særskilt aftale mellem afsender og modtager. 1.5 Protokoller Til forskel fra FESD Packet, som alene forholder sig til benyttelse af SMTP (e-post), kan man sende datafølgesedlen ved hjælp af flere protokoller: 7 / 28

8 SMTP FTP FILE HTTP Oversendelse via e-post. Denne protokol er i dag understøttet af FESD Packet standarden, og er den protokol der typisk anvendes. Protokollen er asynkron. Det vil sige at man ikke umiddelbart får en kvittering for modtagelse, og ikke har 100% sikkerhed for modtagelse. Oversendese via FTP protokollen kan anvendes i forbindelse med oversendelse af større data mængder. Herudover har protokollen den fordel at man får en teknisk kvittering på at oversendelse er gennemført. Ved oversendelse af større datamængder, eller oversendelse til en myndighed som ikke har åbnet for direkte kommunikation, kan protokollen FILE anvendes. I praksis vil oversendelsen skulle ske via et fysisk medie (CD, DVD, USB-memory stick, ell. lign.). Mediet transporteres fysisk fra afsender til modtager. Man kan opnå kvittering for modtagelse, gennem traditionelle forsendelsesmetoder (post / bud / fragt). I de tilfælde hvor man har hyppig oversendelse af data fra en myndighed til en anden, f.eks. i de tilfælde hvor to myndigeder i fællesskab forvalter et sagsområde, kan det være hensigtsmæssigt at pgl. myndigheder udvikler web-services som benyttes til oversendelsen. Ved valg af protokol, er der flere ting som bør overvejes: 1) Tekniske mulighede for kommunikation 2) Behovet for kvittering for oversendelse/modtagelse 3) Datamængder Selve datafølgesedlen er identisk, uanset valgt protokol, men omfanget i forbindelse med implementering, og den opnåede sikkerhed i forbindelse med overførsel vil variere meget. 1.6 Web-Service til modtagelse af datafølgeseddel Som en del af standarden defineres en webservice ved navn receivefesddeliverynote, som skal kunne modtage en datafølgeseddel og behandle denne med henblik på registrering i et ESDH system. Da en datafølgeseddel per definition kun kan fungere som et regitreringsgrundlag kan den interne funktionalitet i servicen ikke beskrives, og det vil være frit for den enkelte leverandør at afgøre graden af manuel sagsbehandling i forbindelse med en oversendelse. Servicen har således til formål at sikre, at det er muligt at sende datafølgesedlen problemfrit via http-protokollen, og kravet er således blot at servicen tager en datafølgeseddel som argument. 8 / 28

9 receivefesddeliverynote (Standard WebService) Fig. 2 Netværk af myndigheder der udstiller en dedikeret Web-Service til modtagelse af datafølgeseddel Webservicen bør implementeres via som en realisering af OWSA model T (OIO Web Service Arkitekur model Transportbaseret sikkerhed) referencemodellen. OWSA model T er baseret på punkt-tilpunkt kommuninkation over SSL 3.0. Dermed sikres fortroligheden i forbindselse med overførsel af data, og datafølgeseddelen behøver ikke særskilt kryptering. OWSA model T er endvidere relevant da denne standard realiserer både MOCES(medarbejdercertifikat) og VOCES(virksomhedscertifikat). Det er således muligt at som myndighed eksponere en webservice til modtagelse af datafølgesedler og samtidigt sætte konkrere regler for hvilke myndigheder eller sagsbehandlere der kan tilgå denne service, og sikre en pålidelig identifikation af samme. Dette personcertifikat skal ikke forveksles med den signering som foregår på selve datafølgeseddelen. Signering af datafølgeseddel har til formål at sikre uafviselighed af data på tværs af protokoller, hvorimod certifikatet som oversendes med webservicekaldet har til formål at bevise brugsretten af pågældende service. I takt med implementering af standarden i den offentlige sektor, vil de implementerede Web-Services udgøre et alternativt forsendelsesnet. Standarden indeholder ikke administrative retningslinier i forhold til lokalisering og anvendelse af en modtagelsesservice hos en specifik myndighed. Det forventes her at den eksisterende infrastruktur omkring OIO/ISB benyttes. Myndigedernes web-services vil dermed være udstillet i det centrale UDDI. 1.7 Transaktionshåndtering Datafølgesedlen er udviklet med henblik på effektiv oversendelse af sags- og dokumentinformation, herunder dokumentobjekter. Standarden indeholder ikke mulighed for f.eks. at afsender kan anmode om modtagelseskvittering af modtageren. Krav om pålidelighed, kvittering, mv. skal adresseres i forbindelse med valg af protokol, og evt. gennem bilaterale aftaler mellem afsender og modtager. 9 / 28

10 Høj pålidelighed i forbindelse med oversendelse opnås gennem anvendelse af http protokollen. Det vil sige gennem en dedikert webservice, som modtageren udstiller. Her vil man umiddelbart få en kvittering for transaktionen og dermed for teknisk modtagelse af den oversendte pakke. Tilsvarende vil man ved anvendelse af protokollen FTP kunne opnå en teknisk transmissionskvittering. I forhold til anvendelse af FILE og SMTP protokollerne, som begge er asynkrone protokoller, er der ikke umiddelbart mulighed for at opnå kvittering for modtagelse, og bør således ikke benyttes hvis det er et krav i forbindelse med oversendelsen Gentagen oversendelse / opdatering I forbindelse med hyppig kommunikation mellem to myndigheder, kan man forestille sig et behov for at den ene myndighed sender en sag med sagens dokumenter, og på et senere tidspunkt ønsker at sende samme sag, med opdaterede oplysninger samt yderligere dokumenter. Opdatering er ikke medtaget som en del af standarden, og de to oversendelser er i forhold til standarden selvstændige, uafhængige forsendelser.evt. semantik omkring opdatering af sagsinformation, tilføjede dokumenter siden sidste forsendelse, mv. skal aftales bilateralt mellem afsender og modtager. Til støtte for fastlæggele af semantik omkring gentagen oversendelse, indeholder standarden krav om entydig identifikation af sags- og dokumentobjekter se afsnit vedrørende unikke identifikatorer Unik identifikator for sags- og dokumentobjekter Oversendelse af sager mellem myndigheder kan ske på et vilkårligt tidspunkt i sagsforløbet, og kan i nogle tilfælde ske flere gange: SAG A SAG A SAG A Sagsbehandling Sagsbehandling Sagsbehandling TID. Fig. 3 Sagens udvikling over tid, med flere oversendelser. Ovenstående figur, illustrerer et sagsforløb, hvor den samme sag sendes fra en myndighed til en anden, flere gange indenfor det specifikke sagsforløb. Sagen vil udvikle sig over tid, det vil sige at der vil være flere dokumenter i sagen, sagens metadata vil muligvis ændre sig, osv. Standarden giver ikke mulighed for at DELE en sag mellem to myndigheder det vil sige at der ikke er elementer eller metoder som specifikt skal bidrage til at sikre synkronisering af sags- og dokumentinformation mellem to myndigheder. Imidlertid er der et krav om at den afsendende part opmærker afsendte sager og dokumenter med en unik identfikator, som skal benyttes ved en evt. senere oversendelse af samme sag/dokument eller ved oversendelse til en tredje myndighed. Referencens formål er primært at kunne identificere et sags- eller dokumentobjekt der oversendes mere en en gang, men kan også benyttes som reference i andre former for dialog mellem myndigheder. 10 / 28

11 Den unikke identifikator, anbefales konstrueret som en UUID (som vist på nedenstående figur). UUID benyttes generelt i FESD Datamodel og øvrige standarder i forbindelse med dannelse af entydige nøgler. Som følge af denne standard, vil FESD Datamodel blive konsekvesrettet, så et ophavs UUID vil blive tilføjet på sags- og dokumentklasserne. Fig. 4 Entydig nøgle for et sagsobjekt Registrering af sags- og dokumentparter I forbindelse med oversendelse af sager og dokumenter mellem to myndigheder, skal det oversendte som tidligere beskrevet opfattes som registreringsgrundlag ved modtagelse. Det er i denne forbindelse vigtigt at den modtagende myndighed fastlægger generelle principper for hvorledes den oversendte partsinformation benyttes og dermed registreres. Hvis man f.eks. forestiller sig at en myndighed har opretttet en sag, på baggrund af en skrivelse, modtaget fra en borger, vil denne skrivelse være registreret i myndighedens ESDH system som et indgående dokument, og borgeren vil være registreret som dokumentpart med egenskaben AFSENDER. Sagen og sagens dokumenter oversendes på et tidspunkt til en anden myndighed, som en del af det samlede sagsbehandlingsforløb. I den datafølgeseddel der dannes i forbindelse med oversendelsen, vil førnævnte dokument, inkl. partsregistrering være indeholdt. Den modtagende myndighed vælger at oprette en sag i eget ESDH system, på baggrund af det oversendte, og lade denne indeholde de dokumenter der er modtaget. I forbindelse med registreringen af dokumenterne i sagen, skal myndigheden tage stilling til om det førnævnte dokument, skal registreres med en dokumentpart med egenskaben AFSENDER, hvor afsenderen er borgeren, eller om den afsendende myndighed skal angives som afsender, og i givet fald, hvilken egenskab skal dokumentparten der indeholder information om borgeren have. Der vil formodentlig være forskel i praksis, fra myndighed til myndighed, og eventuelt også fra sagstype til sagstype, og standarden sætter derfor ingen restriktioner i forhold til praksis. Myndigheden må dermed fastlægge praksis i forbindelse med implementering af standarden Datafølgesedlens struktur Datafølgesedlen indeholder en sag og et eller flere dokumenter, samt parter på både sags- og dokumentniveau. Dokumenter skal i denne sammenhæng forstås som journalposter der kan indeholde flere dokumenter - både metadata om dokumenter og selve dokumentobjektet. I modsætning til standarderne DOKFORM/FESD-Packet, forudsætter datafølgesedlen et sagselement indeholdt. Denne forudsætning er baseret på at oversendelse af information mellem myndigheder er en forvaltningsmæssig handling som skal dokumenteres i en sagsmæssig sammenhæng. Datafølgesedlen kan således ikke benyttes til oversendelse af dokumenter uden sagsmæssigt tilhørsforhold. Strukturen følger strukturen i FESD Datamodel, med SAG-JOURNALPOST-DOKUMENT- DOKUMENTVERSION. Der er dog foretaget en sammenlægning af klasserne DOKUMENT og DOKU- MENTVERSION, idet datafølgesedlen ikke understøtter oversendelse af flere versioner af samme dokument. Det antages, at en myndighed ved oversendelse af et dokument, sender seneste officielle/godkendte version. 11 / 28

12 Følgeseddel Meta FØLGESEDDEL SAG Sag Meta 1.. Sagspart Meta Journalpost Meta JOURNALPOST JournalpostPart Meta Dokument Meta DOKUMENT Dokument Objekt Journalpost MetaExt Sag MetaExt Følgeseddel Signatur Fig. 5 FESD datafølgeseddel opbygning Dokumentobjekter (filer) inkluderes i datafølgesedlen, som kodede objekter, ved benyttelse af base64 encoding. Datafølgesedlen vil således kun bestå af ét filobjekt et XML-dokument, indeholdende såvel metadata som dokumentobjekter (filer). I forhold til dokumentformater, indeholder standarden ingen begrænsninger. I og med der benyttes Base64 encoding, neutraliseres det oprindelige format. Det betyder, at den enkelte myndighed må vurdere hvilke formater det er hensigtsmæssigt at anvende ved oversendelse til en anden myndighed. Man bør anvende formater der er generelt accepteret som produktionsog/eller arkiveringsformater, for at sikre at modtageren er i stand til at læse/benytte de oversendte dokumenter, herunder sikre at gældende standarder for anvendelse af dokumentformater i forbindelse med udveksling, overholdes. Standarden sætter ikke restriktioner i forhold til hvilke formater det er tilladt at medsende i en datafølgeseddel- Filobjektet betragtes som et binært objekt, og dette kodes efter Base64 kodningsstandarden. Elementet DOKUMENT giver mulighed for en simpel angivelse af hvilket format et givent dokument oversendes i. Angivelsen foretages ved at specificere ekstension samt en verbal beskrivelse af formatet. Det er således alene andre standarder/regler som kan sætte restriktioner for hvilke formater der kan/skal benyttes i forbindelse med en specifik oversendelse. 12 / 28

13 1.7.5 Anvendelse af myndigheds- eller sektorspecifikke udvidelser af skemaet Datafølgesedlen indeholder generelle metadata for sager, dokumenter og parter. Normalt vil disse være dækkende i forhold til at beskrive de sager og dokumenter der oversendes, men der kan være behov for sektorspecifikke eller myndighedsspecifkke metadata, som vil kunne berige de oversendte sager/dokumenter og dermed potentielt berige en given sagsproces. Datafølgesedlen indeholder derfor en mulighed for udvidelse, som kan benyttes. Udvidelsesmuligheden kan benyttes med de nedenfor beskrevne restriktioner. Anvendelse af myndigheds- eller sektorspecifikke udvidelser af skemaet Overordnet kan den påtænkte udvidelsesmulighed illustreres på følgende måde: XML SCHEMA FESD DATAFØLGESEDDEL SAG-Meta META-Extension ISB JOURNALPOST-Meta META-Extension Udvidelser skal ske gennem særskilte, publiserede skemaer Fig. 6 Udvidelseselementer i datafølgesedlen De to udvidelsesformer dækker: 1) Beskrivende metadata om sagen Yderligere, beskrivende attributter om sagen 2) Beskrivende metadata om dokumentet Yderligere, beskrivende attributter om dokumentet Tilføjelse af de to typer af udvidelser, realiseres gennem et såkaldt ANY element, der som bekendt kan benyttes uden restriktioner i XML skemaet. En fri modellering af ANY elementet, vil svække standarden, og elementet vil således kun kunne benyttes indenfor standarden, såfremt en række betingelser er overholdt: 1) Udvidelser skal realiseres gennem særskilte skemaer, som er publiceret på ISB en 2) Skemaerne skal følge NDR reglerne i forhold til udformning, mv. 3) Skemaerne skal formålsbeskrives, og må ikke dække generelle forhold som rettelig skal adresseres i standarden og ikke som en udvidelse. 4) Der skal være reference til ansvarshavende for udvidelsen Kravet om publicering af udvidelserne betyder at modtageren vil være i stand til at validere de udvidelser der er foretaget. Det vil også betyde, at standardiseringsenheden vil kunne opsamle og vurdere de forskellige udvi- 13 / 28

14 delser der foretages, med henblik på at revidere standarden, og evt. tilføje yderligere, generelle metadata til standarden Elektronisk signering og kryptering af datafølgeseddel Et vigtigt element i FESD Datafølgeseddel, er muligheden for at signere følgesedlen, standardiseret og dermed uafhængigt af specifikke produkter, og uafhængig af hvilken protokol man benytter i forbindelse med oversendelse. I datafølgesedlen anvendes XML-Signature (xmldsig) til at påføre digitale signaturer. Den fulde beskrivelse af xmldsig ligger udenfor dette dokuments formål og kan findes på Datafølgesedlen tillader et ubegrænset antal personer at signere følgesedlen, og det vil således være muligt at implementere en procedure hvor en sagsbehandler forbereder og danner følgesedlen, signerer denne digitalt og fremsender til nærmeste leder for godkendelse, inden afsendelse. Tilsvarende vil en modtager af datafølgesedlen kunne signere denne, og dermed tilføje endnu en signatur til følgesedlen, hvorefter den kan videresendes indeholdende alle digitale underskrifter. Signatur kan påføres datafølgesedlen som helhed. Standarden giver ikke mulighed for at signere enkelte dele af følgesedlen. Signeringen foretages, som tidligere nævnt, uafhængig af den protokol der påtænkes anvendt. En signeret datafølgeseddel kan sålede oversendes via e-post, på en CD, via ftp, mv., i sogneret form. Anderledes forholder det sig med kryptering. Standarden ser kryotering som værende knyttet til transport. Det vil sige til de protokoller som er nævnt i afsnit 1.5 Protokoller. Fig. 7 Adskillelse af signering og kryptering af datafølgesedlen Ovenstående figur, illustrerer adskillelsen af signering og kryptering. Signeringen foretages på datafølgesedlen, og først når datafølgesedlen afsendes, krypteres den forsendelse som datafølgesedlen udgør. Det vil dermed være muligt at anvende krypteringsfaciliteterne i det e-post programmel man anvender, man kan vælge at benytte liniekryptering ved oversendelse via http (https), mv. 14 / 28

15 Del C Beskrivelse af skema 1.1 Beskrivelse af klasser Elementet følgeseddel meta Indeholder overordnet information om datafølgesedlen Type Kardinalitet Beskrivelse dfsafsendernavn dnsendername char(50) [1] Afsender myndighedsnavn dfsafsendercvr dfsafsenderpnr int(8) [1] Afsenders CVRnummer. dfseannummer dfseanreference Int(8) [1] Afsenders EAN nummer dfsafsenderkontaktpersonnavn dnsendercvrreference dnsenderpreference dnsendercontact- Name dfsafsendelsesdatotid dfssenderdatetime DateTime CCYYMMDD, Jf. ISO dfsdokumenthenvisningreference dfsdocumentreference int(8) [0..1] Afsenders P-nummer produktionsenhedsnummer under det anførte CVRnummer. char(50) [1] Personnavn på vedkommende der er ansvarlig for afsendelse af følgesedlen, og som dermed bør kontaktes i forhold til den specifikke oversendelse. anyuri [0..1] Der kan her indsættes en reference til et af de dokumenter der er indeholdt i datafølgesedlen. Dette kan benyttes til at angive et dokument som værende følgeskrivelse til datafølgesedlen og som dermed må forventes at indehole formål, mv. med oversendelsen Elementet Sag meta Indeholder information om sagen med hovedvægt på de traditionelle journaloplysninger. Type Kardinalitet Beskrivelse sagidentifikatir casefileidentifier UUID [1] Unik nummerering af samtlige sager for at sikre teknisk entydighed. Anvendes som teknisk reference for sagen, hvilket muliggør skabelse af referentiel integritet. UUID (Universal Unique Identifier) anvendes (jf. ISO/IEC :2005 fra International Telecommunication Union). Anføres på formen: urn:uuid:<uuididentifier> 15 / 28

16 Type Kardinalitet Beskrivelse sagpapir paperstorageindicator Indicator [0..1] Angiver om sagen arkiveres på papirform eller elektronisk. Værdi der angiver, om sagen er på papir eller elektronisk. sagdato creationdate Date [1] Oprettelsdato for sagen. Bør tildeles automatisk. Anvendes som bl.a. afgrænsiningsparameter ved søgninger. Sagsoprettelsdato CCYYMMDD, Jf. ISO sagtitel titletext text [1] Feltet indeholder sagens titel, der er ingen krav om entydighed, blot at titlen afspejler sagens indhold. Feltet bidrager sammen med journalnummer/emneord og andre sagsinformationer til at sagsbehandleren/journalføreren kan vurdere sagens indhold og dermed relevans for den opgave, vedkommende skal løse. Felt indeholder sagens titel i klar tekst. sagtiteluofficiel TitleUnofficialIndicator Indicator [1] Værdi der markerer, om sagstitlen er officiel. Markerer om sagstitlen indeholder fortrolig information, eller af anden grund ikke er officiel. sagtitelalternativ TitleAlternativeText text [0..1] Hvis sagstitlen er uofficiel kan dette felt indeholde en alternativ officiel sagstitel, til postlister etc. Feltet indeholder en alternativ titel i klar tekst. sagsstatusbetegnelse StatusName Name [1] Sagsstatus betegnelse i klar tekst. Fri tekst. sagstypebetegnelse name text [1] Sagstypebetegnelsen i klar tekst. Anvendes til at beskrive en række sagstyper, der kan indgå i sagsbehandlingen. sagansvarligsagsbehandler managerreference char(50) [1] Feltet udfyldes med navn på ansvarlig sagsbehandler. Hentes fra Bruger.brugerNavn sagundtagetoffentlighed RestrictedFromPublicText name [0..1] Henvisning til den lovgivning under hvilken denne sag er undtaget offentlighedsloven. Udfyldes med henvisning til den lovgivning, hvis hjemmel anvendes for at undtage sagen fra almindelig offentlighed. Der vil ofte være tale om persondatabeskyttelseslovgivningen eller lign. Fri tekst. sagsenestejournalpost latestrecorddate Date [0..1] Udfyldes med dato for seneste registrerede journalpost. Angiver hvornår der senest har været tilføjet journalposter i sagen. Der er ikke sammenhæng til rækkefølgen af dokumenter. Bør være automatisk genereret dato af seneste tilføjelse af journalpost. sagsletningsfrist retentiontimeyear integer(2) [0..1] Antal år sagen skal bevares. Anvendes typisk i forbindelse med Kassationsbestemmelser fra Statens Arkiver og/eller sletningsfrister jf. Registerforeskriften fra Datatilsynet. Antal år CC. kassationskodebetegnelse name Name [1] KassationsKoden i klar tekst. Beskriver kassationskoden. 16 / 28

17 Type Kardinalitet Beskrivelse sagkassationdato DisposalDate Date [0..1] Angiver hvornår der skal foretages kassation eller anden arkivmæssig behandling af sagen. Kassation skal jf. Persondatabeskyttelsesloven foregå på et givent tidspunkt. Der skal eventuelt ske aflevering til Statens Arkiver inden. Denne dato angiver hvornår der skal foretages kassation. Kassationsdato CCYYMMDD, Jf. ISO sagnr NumberIdentifier char(40) [1] Frit sagsnr. Eventuelt sammenstillinger af andre felter. Indeholder ofte journalnummeret, der traditionelt er sammenstillinger af forskellige andre felter fra Sag og Registrering eksempelvis sagsår, saggruppe og sagloebenummer. Frit sagsnummer. Fri tekst. sagafsluttetdato casefilecloseddate Date [0..1] Udfyldes med den dato sagen opfattes som afsluttet CCYYMMDD, Jf. ISO 8601 sagnormtid casefileestimatedtime Integer(3) [0..1] Evt. fastsat normtid i dage for behandling af sagen sagnettosagsbehandlingstid CaseFileActualWork Integer(3) [0..1] Skønnet nettosagsbehandlingstid i dage. Dvs. antal kalenderdage brugt til egentlig behandling af sagen og dermed undtaget de dage hvor sagen behandles udenfor institutionen (er i høring, behandles af anden institution, afventer svar fra part etc.) emneidentifikator termidentifier char(34) [1] Dette er den entydige identifikator for emnet indenfor systematikken. Identifikatoren er en streng, hvor tilladte karakterer er alle alfanumeriske tegn plus tegnet punktum (. ). emnekvalificeretemneid termuniquetermidentifier URI [1] Dette er en generelt entydig identifikator for emnet. Identifikatoren er en URI dannet ved sammensætning af den URI-baserede identifikator for emnesystematikken + URI-fragmentsymbolet # + emneid. emnedeskriptortekst termdescriptortext Text [1] Kortfattet, præcis titel for emnet. Denne ID skal gøre det muligt for eksterne parter og systemer entydigt at genkende og identificere klassificering foretaget med emnesystematikken. I tilfælde, hvor der foretages lovlige udvidelser af en emnesystematik med ekstern forfatter, udvides identifikatoren for emnesystematikken med en organisationsreference. sagsikkerhedsklassifikation casefilesecurityclassifcation char(50) [0..1] Sikkerhedsklassifikationskode. Sikkehedsklassifikation er beskrevet i FES- Dstandarden for BrugerAdministration Beskrivelse af elementet SagsPart meta Indeholder information om sagens parter. Part skal her forståes bredt, som personer, organisationer, genstande, mv. Elementet er primært opbygget af elementer fra FESD adressemodel, som ikke beskrives her. Der henvises til beskrivelse af adressemodellen på oio.dk: 17 / 28

18 Type Kardinalitet Beskrivelse sagspartrolle casefilereferencerole ShortText [0..1] Den rolle (part, fuldmægtig advokat eller lign.) kontaktpersonen har i sagen. Fri tekst. Eventuelt hentet fra opslagstabel. sagspartuofficielindikator casefilereferenceunofficielindicator Indicator [0..1] Udfyldes hvis oplysninger om sagsparten er undtaget almindelig offentlighed. Hvis sagsparten er en person, må sagspartsoplysningrne ikke umiddelbart offentliggøres. Der kan også findes andre årsager til at sagspartsoplysningerne ikke umiddelbart må offentliggøres. Værdi, hvortil der bør anvendes følgende udfaldsrum: 1 hvis sagsparten ikke umiddelbart kan offentliggøres ellers 0. sagspartkommentar casefilereferencecomment Text [0..1] Kommentar der beskriver sagspartens forhold til sagen. Fri tekst Elementet JournalPost Type Indeholder grundoplysningerne om en Journalpost. Anvendes til at registrere grundoplysninger om hoveddokument, eventuelt med underdokumenter og/eller bilag. Kardinalitet 18 / 28 Beskrivelse journalpostidentifikator recordidentifier UUID [1] Unik nummerering af samtlige Journalposten for at sikre teknisk entydighed. Anvendes som teknisk reference for Journalposten, hvilket muliggør skabelse af referentiel integritet. journalpostdokumentnummer SequenceNumber Sequence- Number UUID (Universal Unique Identifier) anvendes (jf. ISO/IEC :2005 fra International Telecommunication Union). ). Anføres på formen: urn:uuid:<uuid-identifier> [1] Dokumentnummeret indenfor sagen. Anvendes til at definerer dokumentets rækkefølge i sagen. I Noark 4 tildeles nummeret automatisk og kan kun ændres ved en flytning eller omregistrering af sagen. Entydigt maskingenereret løbenummer knyttet til dokument i sagen. journalpostregistreringsdato RegistrationDate date [1] Registreringsdato for journalposten. Anvendes til at registrere det tidspunkt, hvor journalposten er registreret i systemet. Retningslinierne for udfyldelsen af dette felt bør hænge sammen med processen for modtagelse af dokumenter. Registreringsdato CCYYMMDD, Jf. ISO dokumenttypebetegnelse name Name [1] Dokumenttypen i klar tekst. journalpostdokumentdato documentdate Date [1] Dokumentdato for dokumentet. Anvendes til at registrere den dato, der er påstemplet eller på anden måde registreret på dokumentet. Dokumentdato

19 journalpostudateret Kardinalitet documentdateunknownindicator Type Beskrivelse CCYYMMDD, Jf. ISO Indicator [1] Værdi der dokumenterer, om dokumentet er udateret. Et dokument betragtes som udateret, hvis det ikke er muligt at lokaliserer en dato af brevheaderen eller specifikt markeret som afsendelsesdato. journalpostindholdsbeskrivelse descriptiontext Text [1] Tekst der beskriver indholdet af journalposten. Anvendes til at beskrive indholdet af journalposten, der kan være tale om et hoveddokument med underdokumenter, eller bilag, eller enkeltstående dokumenter. Fri tekst. Om journalposten. journalpostindholdsbeskrivelseuofficiel journalpostindholdsbeskrivelsalternativ descriptionunofficialindicator Indicator [0..1] Udfyldes hvis oplysninger om Journalpostens indholdsbeskrivelse er undtaget almindelig offentlighed. Hvis beskrivelsen af journalpostens indhold indeholder personoplysninger, eller anden fortrolig information markeres det i dette felt. alternativedescriptiontext Text [0..1] Kan indeholde en alternativ beskrivelse. Hvis indholdsbeskrivelse af journalpost er uofficiel, kan dette felt indeholde en alternativ officiel journalpost beskrivelse til postlister etc. journalpostafskrivningsdato depricationdate date [0..1] Registrerer dato for hvornår dokumentet er færdigbehandlet. I den offentlige forvaltning skal det sikres, at alle henvendelser besvares, og at de besvares indenfor en given tidsramme. Feltet anvendes som basisinformation for denne type af opgaver. Færdigbehandletdato CCYYMMDD, Jf. ISO journalpostekspederetdato responsedate date [0..1] Registrerer dato for hvornår dokumentet er ekspederet. Knytter sig til sagsbehandlingsdelen af systemet. Ekspeditionsdato CCYYMMDD, Jf. ISO journalpostforfaldsdato responsedeadlinedate date [0..1] Forfaldsdato registrerer, hvornår dokumentet senest skal være ekspederet. Knytter sig til sagsbehandlingsdelen af systemet. Fristdato for ekspedition CCYYMMDD, Jf. ISO journalpostundtagetoffentlighed publicationindicator ShortText [0..1] Henvisning til den lovgivning under hvilken denne journalpost er undtaget offentlighedsloven. Udfyldes hvis journalposten er undtaget fra almindelig offentlighed. Udfyldes med henvisning til den lovgivning, hvis hjemmel anvendes for at undtage journalposten fra almindelig offentlighed. Der vil ofte være tale om persondatabeskyttelseslovgivningen eller lign. Fri tekst. journalpostoffentlighedsvurderet publicationevaluationdate Date [0..1] Dato for hvornår journalposten er blevet offentlighedsvurderet. Anvendes til at beskrive hvornår Journalposten er blevet offentlighedsvurderet. Kan anvendes i forbindelse med aktindsigtsregler og/eller åbne postlister. Offentlighedsvurderet dato CCYYMMDD, Jf. ISO journalpostpapir PaperStorageIndicator Indicator [1] Skal journalposten arkiveres i papirform eller elektronisk. Angiver om journalposten arkiveres på papirform eller elektronisk. 19 / 28

20 Type Beskrivelse journalstatusbetegnelse recordstatusname ShortText [1] Journalstatus i klar tekst. Beskriver Journalstatus. journalpostansvarligenhed casefilemanagerreference Char(50) [0..1] Udfyldes med information om hvem der er ansvarlig sagsbehandler. Kardinalitet journalpostansvarligsagsbehandler recordrecipientunitreference Hentes fra Bruger.brugerNavn char(50) [0..1] Udfyldes med information om ansvarlig organisation/afdeling for journalposten. Enhedsnavnet hentes fra OrgEnhed.enhedsNavn journalpostskandato recordscandate Date [0..1] Datoen hentes fra scandatatime efter evt. skanning. Formatet er CCYYDDMM, jf. ISO 8601 journalpostskantid recordscantime Time [0..1] Tidspunktet hentes fra scandatetime efter evt. skanning. Formatet er hh:mm:ss, jf. ISO 8601 journalpostsikkerhedsklassifikation recordsecurityclassifcation char(50) [0..1] Sikkerhedsklassifikationskode. Sikkehedsklassifikation er beskrevet i FES- Dstandarden for BrugerAdministration. journalpostkategorikode recordcategorycode Code [0..1] Kategori af Journalposten. Denne kan være indgående, udgående, notat. Udfyldes med I, U, N Beskrivelse af elementet JournalpostPart meta Type Indeholder information (navn adresse etc.) som beskriver den/de person, virksomhed, myndighed eller organisation, som er part i dokumentet (afsender/modtager). Kardinalitet 20 / 28 Beskrivelse personcprnr personcprnumber integer(10) 0-1 Entydig identifikation på en person. Noter at cprnr ikke fungerer som entydig identifikator for klassen, da cprnr ikke kan forventes kendt for alle instanser. Udfyldes såfremt personorganisationindikator angiver at der er tale om en person. personadresseringsnavn personaddressname Name 1 Fornavn, mellemnavn og efternavn, sammenstillet. Elementet er ikke nødvendigvis konstrueret af de selvstændige elementer fornavn, memmelnavn og efternavn, men kan i sin helhed være tolket eller indtastet i forbindelse med indskanningen. Udfyldes såfremt personorganisationindikator angiver at der er tale om en person. personfornavn personsurname char(50) 0..1 Den samlede længde af fornavn må ikke overskride 50 karakterers længde personmellemnavn personmiddlename char(40) 0-1 Den samlede længde af mellemnavn må ikke overskride 40 karakterers længde personefternavn personfamilyname char(40) 0..1 Feltets indhold kan bestå af flere navne adskilt af en blank position eller af en

21 Type Kardinalitet 21 / 28 Beskrivelse bindestreg. Feltet kan være blank for børn, hvis disse endnu ikke er navngivet. organisationcvrnr organizationcvrnumber integer(8) 0-1 Afsenderorganisationens CVR nummer. Udfyldes såfremt personorganisationindikator angiver at der er tale om en organisation. organisationorganisationsnavn organizationorganization- Name char(50) 0..1 Navnet på organisationen eller virksomheden. Udfyldes såfremt personorganisationindikator angiver at der er tale om en organisation. personorganisationindikator personorganizationindicator indicator 1 Angivelse af om part er en person eller en organisation, og således hvilke oplysninger der skal være tilstede. adressekommunekode addressmunicipalitycode char(4) 0..1 Det af Indenrigsministeriet fastsatte nummer for kommunen. Refererer til klassen Kommune. Herfra kan kommunenavn hentes. adresselandkodealfa2 addresscountrycodealpha2 Code 1 ISO-betegnelsen for land. adressevejkode addressroadcode char(4) 0..1 Vejkoden består af fire cifre i intervallet Intervallet kaldes 'højvejkode' og er afsat til særlig anvendelse. Vejkode angiver koden for den gade/vej, hvor ejendommen/bygningen/enheden er beliggende. Vejkode danner sammen med kommunekode en entydig kode for en vej i mark. Refererer til klassen Vej. Herfra kan udledes såvel vejnavn som vejadresseringsnavn adressehusnr addresshousenumvber char(4) 0..1 Nummerbetegnelse inkl. et evt. stort bogstav, som identificerer en bestemt adgang til en bygning, en grund eller et teknisk anlæg og lign. med udgangspunkt i dén navngivne vej som giver adgang hertil. Ved Husnummer forstås i mark altid husnummer inkl. evt. bogstav. Indgår et bogstav i adressen, er dette en nødvendig del af den fuldstændige og korrekte adresse. Et husnummer består af et tal i intervallet Husnummeret kan have tilknyttet et bogstav fra A til Z. adresseetage addressflorrefernce char(2) 0-1 Etagen, hvor enheden er beliggende. Etagen kan antage følgende værdier: Den etage hvis gulvplan ligger i eller umiddelbart over gadeniveau benævnes ST De følgende etager herover benævnes nedefra og opefter 1, 2, 3, til 99 Kældre (etagerne under gadeniveau) benævnes KL K2 K3 til K9 i retning ovenfra og nedefter Etagen angives ikke, hvis der kun er en enhed i bygningen.

22 Type Kardinalitet Beskrivelse adressedoerbetegnelse addressdoorreference char(4) 0-1 Identifikation som beskriver beliggenheden af en bestemt indgangsdør på en etage (trappeafsats) i den pågældende opgang. Betegnelserne tv, mf og th bruges når der er indtil tre døre på trappeafsatsen. Hvis der er flere døre anvendes tallene 1, 2, 3, 4 osv. Andre betegnelser på indil 4 tegn kan dog også fastsættes. På etager med fire enheder kan betegnelserne TV, MFTV, MFTH og TH anvendes. adresselinie1 addressline1 char(50) 0-1 c/o reference. Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. adresselinie2 addressline2 char(50) 1 Gade, husnummer, etage. Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. adresselinie3 addressline3 char(50) 0-1 Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. Anvendes ikke hvis landekodealfa2 er DK adresselinie4 addressline4 char(50) 0-1 Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. Anvendes ikke hvis landekodealfa2 er DK adresselinie5 addressline5 char(50) 0-1 Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. Anvendes ikke hvis landekodealfa2 er DK adressepostboks addresspostboxreference Char(4) 0-1 Nummer eller anden identifikation jf. Post mark adressepostnr addresszipcode char(4) 1 Et postnummer består af fire cifre. Refererer til klassen PostDistrikt. Herfra kan postdistrikt hentes (tekstbetegnelse for distriktet) adressebynavn addresscityname char(34) 1 Det fastsatte bynavn præciserer beliggenheden inden for en kommune eller postdistrikt. Et evt. bynavn er en nødvendig del af den fuldstændige og korrekte adresse. Et bynavn skal fastsættes når der findes ens eller enslydende vejnavne i postdistriktet eller kommunen. bynavn kan bestå af indtil 34 tegn. adresselokalitetsnavn addresssitename char(34) 0-1 Ikke entydigt navn for lokalitet. lokalitetsnavn (gårdnavn, bygningsnavn e.l.) kan knyttes til en enkelt eller flere adresser i en bygning eller et bygningskompleks lokalitetsnavn består af indtil 34 tegn som indgår i den officielle adressebetegnelse, f.eks. fra CPR Reglerne herom findes i 17, stk. 3, i Cirkulære om ajourføring af CPRs vejog boligregister (Cirkulære nr. 130 af 25. november 2002). epostadresse addressidentifier MailToURI adresse i standard uri-form; 22 / 28

23 Type Beskrivelse journalpostfaxnummer recordpartyfaxnumber char (20) 0..1 Faxnummeret på person, virksomhed, myndighed eller organisation der er part i sagen. Faxnummer, eventuelt foranstillet + journalpostparttlf recordpartyphonenumber char (20) 0..1 Telefonnummer på person, virksomhed, myndighed eller organisation der er part i sagen. Telefonnummer, eventuelt foranstillet + journalpostpartrolle recordpartyrole char (70) [0..1] Den rolle (part, fuldmægtig advokat eller lign.) kontaktpersonen har i sagen. Fri tekst. Eventuelt hentet fra opslagstabel. kontaktnavnadressebeskyttelse Kardinalitet contactnameaddressprotection boolean 1 Markering der viser om personen har navne-/adressebeskyttelse journalpostpartuofficiel recordpartyunofficial char (1) [0..1] Udfyldes hvis oplysninger om journalpostparten er undtaget almindelig offentlighed. Hvis journalpostparten er en person, må journalpostpartsoplysningrne ikke umiddelbart offentliggøres. Der kan også findes andre årsager til at journalpostpartsoplysningerne ikke umiddelbart må offentliggøres. Værdi, hvortil der bør anvendes følgende udfaldsrum: 1 hvis journalpostparten ikke umiddelbart kan offentliggøres ellers Beskrivelse af elementet Dokument meta Denne klasse indeholder information vedrørende dokumenter, der kan knyttes til en bestemt sag. Type Kardinalitet Beskrivelse dokumentidentifier documentidentifier UUID [1] Unik nummerering af samtlige dokumenter for at sikre teknisk entydighed. Anvendes som teknisk reference for dokumenter, hvilket muliggør skabelse af referentiel integritet. dokumentkategoribetegnelse description Name [1] Dokumenttilknytningstypen i klar tekst. Beskriver informationstypen. dokumenttitel titletext Text [1] Feltet indeholder dokumentets titel, der er ingen krav om entydighed, blot at titlen afspejler dokumentets Origin Dokument UUID (Universal Unique Identifier) anvendes (jf. ISO/IEC :2005 fra International Telecommunication Union). ). Anføres på formen: urn:uuid:<uuididentifier> DokumentKategori Dokument 23 / 28

24 Type Kardinalitet Beskrivelse indhold. Feltet bidrager sammen med andre dokumentinformationer til, at sagsbehandleren/journalføreren kan vurdere dokumentets indhold og dermed relevans for den opgave vedkommende skal løse. dokumentpapirplacering dokumentpaapapir paperstorageindicator Indicator [1] Angiver om sagen arkiveres på papirform eller elektronisk. documentpaperstoragelocation Text [0..1] Fri tekst der angiver papirets fysiske placering. Feltet anvendes til at beskrive, hvor papirdokumenter i form af tykke rapporter, publikationer, der ikke indskannes i deres fulde omfang, fysisk placeres. Origin Dokument Dokument dokumentstatusbetegnelse name name [1] Dokumentstatus i klar tekst. Beskriver dokumentstatus. DokumentStatus dokumentudarbejdetaf creatorreference Char(50) [0..n] Udfyldes med information om hvem der har udarbejdet dokumentet. Hentes fra Bruger.brugerNavn dokumentundtagetoffentlighed nondisclosurediscriptiontext char(16) [0..1] Henvisning til den lovgivning under hvilken dette dokument er undtaget offentlighedsloven. Udfyldes med henvisning til den lovgivning, hvis hjemmel anvendes for at undtage dokumentet fra almindelig offentlighed. Der vil ofte være tale om persondatabeskyttelseslovgivningen eller lign. Fri tekst. dokumentversionloebenummer number integer(5) [1] Indeholder dokumentets versionnummer indenfor dokumentet. Tildeles ofte automatisk. Entydigt maskingenereret løbenummer. varianttypebetegnelse name Name [1] Varianten i klar tekst. Beskriver varianten. VariantType lagringsformatfiltype DokumentVersion storageformatdefaultfiletype LongCode [0..1] Angiver standardformat filtyper eksempelvis DOC for Word. Tekst. dokumenttilknytningsbetegnelse documentlinktypename ShortText [1] dokumenttilknytningsbetegnelse i klar tekst. Beskriver informationstypen. 24 / 28

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22 august 2007. IT- og Telestyrelsen København 12. juli 2007 FESD-standardisering FESD Datafølgeseddel.

Læs mere

FESD Datafølgeseddel

FESD Datafølgeseddel FESD Datafølgeseddel Standard IT- og Telestyrelsen København den 11. december 2008. FESD-standardisering FESD Datafølgeseddel. Protokol. Version 1.1 Kolofon: FESD-standardisering. FESD Datafølgeseddel.

Læs mere

FESD standardisering Udveksling Version 1.0

FESD standardisering Udveksling Version 1.0 FESD standardisering Udveksling Version 1.0 Kolofon: FESD standardisering. Udveksling Version 1.0 FESD udvekslingspakke Udarbejdet af IT- og Telestyrelsen, IT-strategisk kontor, FESD standardiseringsgruppen

Læs mere

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat. Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012

Læs mere

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 FESD standardisering FESD-modul. Skanningsmodul Version 1.0 Kolofon: FESD moduler. Skanningsmodul. FESD standardisering. Skanningsmodul

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

Læs mere

Att: Mads Ellehammer:

Att: Mads Ellehammer: KL Att: Mads Ellehammer: 27. august 2008 FESD-standardiseringsgruppen har nu færdigbehandlet de indkomne svar til høringen, som løb fra den 22. marts 2008 til 23. maj 2008, og ønsker med dette brev at

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Adresser UBL 2.0 Address G36 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Adresser Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 IT- og Telestyrelsen København den 12. juli 2007 FESD-standardisering Grænseflade

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Boligportal.dk s kravspecifikation til XML-feed

Boligportal.dk s kravspecifikation til XML-feed Boligportal.dk s kravspecifikation til XML-feed Introduktion I forbindelse med automatisk import af lejeboliger til Boligportal.dk skal der udarbejdes en XML-feed, som Boligportal.dk kan hente på en URL.

Læs mere

Svar på spørgsmål om Nyt BBRs adresser og adressekonvertering

Svar på spørgsmål om Nyt BBRs adresser og adressekonvertering 28. oktober 2009 Rev. 6./11. november 2009 Svar på spørgsmål om Nyt BBRs adresser og adressekonvertering Sag 07/ mli 1. Indledning Dette notat skal søge at svare på en række spørgsmål som KL har modtaget,

Læs mere

Dette svarbrev publiceres på www.hoeringsportalen.dk. De godkendte standarder vil være at finde via www.oio.dk.

Dette svarbrev publiceres på www.hoeringsportalen.dk. De godkendte standarder vil være at finde via www.oio.dk. Devoteam Consulting Att: Mark Breitner 2. oktober 2007 FESD-standardiseringsgruppen har nu færdigbehandlet de indkomne svar til høringen, som løb fra den 12. juli 2007 til 22. august 2007, og ønsker med

Læs mere

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008.

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008. FESD Arkivstruktur Standard IT- og Telestyrelsen København den 10. december 2008. FESD-standardisering Arkivstruktur. Datamodel Version 1.1 Kolofon: FESD-standardisering. Arkivstruktur. Datamodel. Version

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Datatyper UBL 2.0 Datatypes G29 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail:

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Stamoplysninger for en person CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Valutakurser og -koder UBL 2.0 Currency Exchange Rates G18 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Valutakurser og -koder Version

Læs mere

Vejledning om avanceret afhentning. i Digital Post på Virk.dk.

Vejledning om avanceret afhentning. i Digital Post på Virk.dk. Vejledning om avanceret afhentning og sortering i Digital Post på Virk.dk. Denne vejledning beskriver, hvordan virksomheder, foreninger m.v. med et CVR-nummer kan modtage Digital Post, herunder hvordan

Læs mere

OIOXML dokumentationsguide Person

OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person . Ejerskab Indenrigs og Sundhedsministeriets CPR-kontor i medfør af Bekendtgørelse af lov om Det Centrale Personregister, jf. lov nr.

Læs mere

Denne vejledning beskriver integration mellem miljø- og byggesagssystemet GeoEnviron (GE) og ESDH-systemet edoc, der er udviklet af Fujitsu.

Denne vejledning beskriver integration mellem miljø- og byggesagssystemet GeoEnviron (GE) og ESDH-systemet edoc, der er udviklet af Fujitsu. Integration mellem edoc og GeoEnviron Denne vejledning beskriver integration mellem miljø- og byggesagssystemet GeoEnviron (GE) og ESDH-systemet edoc, der er udviklet af Fujitsu. 1. Målsætning Miljø- og

Læs mere

OIOXML Adresseguide. 1. Baggrund. 2. Formål

OIOXML Adresseguide. 1. Baggrund. 2. Formål OIOXML Adresseguide Denne guide er udarbejdet af en arbejdsgruppe under den såkaldte Nøgledatagruppe under XML-projektet i Ministeriet for Videnskab, Teknologi og Udvikling. Arbejdsgruppen består af: Morten

Læs mere

DAR OIO vejledning Version 1.2

DAR OIO vejledning Version 1.2 DAR OIO vejledning Version 1.2 Indhold 1 Ændringer i forhold til forrige version... 2 2 Introduktion... 3 2.1 Formål... 3 2.2 Læsevejledning... 3 3 Beskrivelse... 3 3.1 Fælles elementer og strukturer...

Læs mere

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere

OIOUBL Kodeliste. OIOUBL AccountTypeCode K01. Version 1.1. Published under Creative Commons license, attribution 2.0

OIOUBL Kodeliste. OIOUBL AccountTypeCode K01. Version 1.1. Published under Creative Commons license, attribution 2.0 OIOUBL Kodeliste K01 Version 1.1 Published under Creative Commons license, attribution 2.0 Kolofon Kontakt: IT- og Telestyrelsen E-mail: plb@itst.dk Version 2.01 April 2007 Ministry of Science, Technology

Læs mere

Udkast til: Cirkulære om anmeldelse og godkendelse af it-systemer

Udkast til: Cirkulære om anmeldelse og godkendelse af it-systemer Udkast til: Cirkulære om anmeldelse og godkendelse af it-systemer I medfør af 3, stk. 2, og 5, stk. 1 samt 10 i bekendtgørelse nr. 591 af 26. juni 2003 om offentlige arkivalier og offentlige arkivers virksomhed

Læs mere

FESD Brugeradministration

FESD Brugeradministration FESD Brugeradministration Standard IT- og Telestyrelsen København den 10. december 2008 FESD standardisering Brugeradministration. Datamodel Version 1.1 Kolofon: FESD standardisering. Brugeradministration.

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel Indhold > Indledning 3 Standarder 5 OIOUBL 5 OIO RASP 6 OIO SMI 7 Biblioteker 8 Web applikationer 9 Fakturablanket 9 NemHandel Registrering 9 NemHandel.dk 10 Web services

Læs mere

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 1 Indholdsfortegnelse G.1 INTRODUKTION 4 G.1.1 OVERBLIK OVER HVORDAN DIGITAL POST KAN TILGÅS 4 G.1.2 FLOW SOM EN DIGITAL

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Værgeoplysninger CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Håndbog

Læs mere

bips F104, Dokumenthåndtering

bips F104, Dokumenthåndtering bips F104, Dokumenthåndtering af Gunnar Friborg & Charlotte Lund Poulsen Disposition Introduktion Tidsforløb og historik Hvad erstatter anvisningen? Baggrund Struktur og tankesæt Dokumenthåndtering Genfinding

Læs mere

Det skal understreges, at kassation af dokumenter er en mulighed, og ikke en pligt for kommunerne.

Det skal understreges, at kassation af dokumenter er en mulighed, og ikke en pligt for kommunerne. KL notat 26-06-2014/FLN Beslutning om kassation i ESDH-systemer med tjekliste Notatet er til brug for den kommunale myndigheds beslutning, om den vil gøre brug af muligheden for kassation fra ESDH eller

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Dokument Reference UBL 2.0 Document Reference G21 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen

Læs mere

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg

Læs mere

Underbilag 2O Beskedkuvert Version 2.0

Underbilag 2O Beskedkuvert Version 2.0 Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Bilag 1 Vurdering af økonomiske konsekvenser af beslutningsforslag B 103 1. Indhold i beslutningsforslag B 103 Det overordnede

Læs mere

DKAL Snitflader Masseforsendelse

DKAL Snitflader Masseforsendelse DKAL Snitflader Masseforsendelse 1 C.1 Indholdsfortegnelse C.1 INDHOLDSFORTEGNELSE... 2 C.2 LÆSEVEJLEDNING... 3 C.3 TILMELDINGSLISTE... 4 C.3.1 RECORD-STRUKTUR... 4 C.3.2 OIOXML-STRUKTUR... 5 C.4 MATERIALE-INDLÆSNING...6

Læs mere

Captia - kvik guide Personalesager

Captia - kvik guide Personalesager Captia - kvik guide Personalesager 05-05-2015 Aalborg Universitet, HR-afdelingen HR@adm.aau.dk Indhold Inden du går i gang... 1 Søg efter en medarbejder (på C-adressat)... 1 Opret C-adressat... 2 Oprettelse

Læs mere

Guide til Frivillige foreninger

Guide til Frivillige foreninger Brug Frivillige foreninger på Virk.dk til at oprette et CVR nr. til din frivillige forening. Det er også her, du retter i foreningens oplysninger, fornyer og lukker dens CVR nr.. Du kan tilgå løsningen

Læs mere

IT-sikkerhedsbestemmelser for anvendelse af e-post

IT-sikkerhedsbestemmelser for anvendelse af e-post Bilag 8 IT-sikkerhedsbestemmelser for anvendelse af e-post Formålet med sikkerhedsbestemmelserne er at beskrive, hvordan medarbejdere i Randers Kommune, som anvender e-post via kommunens udstyr og e-postadresser,

Læs mere

FESD Ledelsesinformation

FESD Ledelsesinformation FESD Ledelsesinformation Version 2.1 Standard IT- og Telestyrelsen København den 18. december 2008. FESD-standardisering Ledelsesinformation. Modul. Version 2.1 Kolofon: FESD-standardisering. Ledelsesinformation.

Læs mere

FORSLAG TIL MASSEAFSENDELSE

FORSLAG TIL MASSEAFSENDELSE FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11 Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding Nuværende OIO-REST løsning Digital post De nuværende Digital Post

Læs mere

Baggrundsinformation

Baggrundsinformation 1. Begreber Baggrundsinformation Sags- og Dokumentindekset skal indeholde sags- og dokumentmetadata, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres

Læs mere

Leverancebeskrivelse - Bilag 1

Leverancebeskrivelse - Bilag 1 Leverancebeskrivelse - Bilag 1 Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service Juli 2008 Dato: 17-07-2008 Kontor: Udviklingsenhed J.nr.: I4148 Sagsbeh.: CHS Fil-navn: Leverancebeskrivelse bilag

Læs mere

IKT-teknisk kommunikationsspecifikation

IKT-teknisk kommunikationsspecifikation Bilag til IKT Ydelsesspecifikation Dato 2012-10-01, Revisionsdato: 2013-04-15 Samarbejdsdokument for byggesagens parter Projekt: Byggesag: Projektledelse: IKT Koordinator: Dato: Revision: Revision dato:

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 17.06.2014 PKR Første udkast 0.2 18.06.2014 MBS Tilføjet afsnit om Søgeresultater 0.3 26.06.2014

Læs mere

Tilslutning til ecomone Basis (OIO Faktura)

Tilslutning til ecomone Basis (OIO Faktura) Tilslutning til ecomone Basis (OIO Faktura) 1. november 2009, Version 1.1 1. POST DANMARKS ECOMONE BASIS (OIO FAKTURA)... 3 1.1 BEGREBER... 3 2 KANALER... 3 3 MODEL FOR DATAUDVEKSLING... 4 4 KOMMUNIKATION...

Læs mere

Find det relevante dokument på rekordtid med A104 Dokumenthåndtering Gunnar Friborg, bips

Find det relevante dokument på rekordtid med A104 Dokumenthåndtering Gunnar Friborg, bips Find det relevante dokument på rekordtid med A104 Dokumenthåndtering Gunnar Friborg, bips Dokumenthåndtering er nøglen Nøglen til dokumenterne Nøglen til informationerne Nøglen til data Preben Mejer, Innovation

Læs mere

Lovtidende A 2010. Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) 16. november 2010.

Lovtidende A 2010. Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) 16. november 2010. Lovtidende A 2010 16. november 2010. Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) I medfør af 4, stk. 4, og 8, stk. 2, i lov om bygnings- og boligregistrering,

Læs mere

Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH

Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH FAABORG-MIDTFYN KOMMUNE Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH KMD-sag-edh Side 1 af 10 MÅL MED ELEKTRONISK DOKUMENTHÅNDTERING 4 AFGRÆNSNING 4 SIKKERHED 4 DOKUMENTER 5 Dokumentdefinition

Læs mere

Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011

Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011 Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011 Indholdsfortegnelse 1. Indledning... 3 1.1 Baggrund... 3 1.2 Blanketternes anvendelse... 4 1.3 Den papirbaserede arbejdsgang... 5 1.4 Den fremtidige

Læs mere

Integration mellem Acadre og GeoEnviron

Integration mellem Acadre og GeoEnviron 1. MÅLSÆTNING... 1 2. OPSÆTNING AF STAMDATA... 2 2.1 KL journalplan... 2 2.2 Parametre til GeoEnvirons mappe-struktur... 3 3. FUNKTIONALITET I GE BYGGESAG... 4 3.1 Oprettelse af ejendomme... 4 3.2 Søgning

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 17-06-2014 MST Oprettelse af krav 0.2 18-05-2014 MST Tilretning af tabeller 0.3 18.06.2014 PKR

Læs mere

Alle dokumenter der oprettes på en sag i GE på fanen Dokument gemmes i mappen for den pågældende sagstype.

Alle dokumenter der oprettes på en sag i GE på fanen Dokument gemmes i mappen for den pågældende sagstype. Integration mellem edoc og GeoEnviron - version 1 Med GeoEnviron 6.4.1 frigives integrationen mellem ESDH-systemet edoc, som er udviklet af Fujitsu, og GeoEnviron Miljø og Byggesag. I det følgende kaldes

Læs mere

FESD Sikker epostløsning

FESD Sikker epostløsning FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 23. august 2006. FESD-standardisering Sikker epostløsning. Grænsesnit Version 1.0 Kolofon: FESD-standardisering. Sikker epostløsning.

Læs mere

Krav til dataformat ved indberetning

Krav til dataformat ved indberetning Bilag 1 Krav til dataformat ved indberetning Dette bilag beskriver data struktur og format for de data som energileverandørerne skal indberette. Formatet på filen er en csv eller xls fil som består af

Læs mere

Personnummerregister / CPR Importer

Personnummerregister / CPR Importer Personnummerregister / CPR Importer 1 Indbakke Forventer biblioteker i sin indbakke indeholdende filer kodet i tegnsættet ISO-8859-1 der overholder følgende navngivningsmønster: D.{6}\.L4311.* Filerne

Læs mere

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

Aktør-adresse. Konceptuel model. Fællesoffentligt modeludkast. 7. december 2005. Version 1.1

Aktør-adresse. Konceptuel model. Fællesoffentligt modeludkast. 7. december 2005. Version 1.1 Aktør-adresse Konceptuel model Fællesoffentligt modeludkast 7. december 2005 Version 1.1 Indholdsfortegnelse 1 INDLEDNING... 3 1.1 ARBEJDSMETODE... 3 1.2 FORUDSÆTNINGER... 3 1.3 AFGRÆNSNINGER... 4 1.4

Læs mere

Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL

Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL 4. januar 2013 Indhold UTS og forskellen i forhold til det gamle format...2 Udfordringer med UTS...2 Tiltag med henblik på at afhjælpe udfordringerne...3

Læs mere

Vejledning til leverandører ifm. CPR-abonnement

Vejledning til leverandører ifm. CPR-abonnement Vejledning til leverandører ifm. CPR-abonnement Dette notat beskriver de forhold som man som leverandør og kommune skal være opmærksom på når man ønsker at modtage CPR-data i abonnement fra Serviceplatformen.

Læs mere

Vejledning til blanket ved syn og skøn

Vejledning til blanket ved syn og skøn Vejledning til blanket ved syn og skøn Anvendelse af blanketten Ved syn og skøn skal blanketten syn og skøn benyttes. Du må ikke lave din egen blanket, og du må ikke ændre i blankettens tekst hverken som

Læs mere

Personnummerregister / CPR Importer

Personnummerregister / CPR Importer Personnummerregister / CPR Importer 1 Indbakke Forventer biblioteker i sin indbakke indeholdende filer kodet i tegnsættet ISO-8859-1 der overholder følgende navngivningsmønster: D.{6}\.L4311.* Filerne

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline UBL 2.0 Signature OIOUBL Signatur G31 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Signatur Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

FIE brugervejledning

FIE brugervejledning FIE brugervejledning Hvad er FIE?... 2 Hvordan bruger jeg FIE?... 2 Hvor finder jeg FIE?... 2 Hvordan logger jeg ind?... 3 Hvordan uploader jeg data?... 4 Hvad sker, når mine data er behandlet?... 4 Efter

Læs mere

BBR-Kommune Inddataboks

BBR-Kommune Inddataboks BBR-Kommune Inddataboks Brugervejledning Version 1.0 Indholdsfortegnelse 1.1. Forord... 3 1.2. Formål... 3 1.3. Adgang... 3 1.4. Opbygning af vejledningen... 4 2. Inddataboksen set i sammenhæng... 5 2.1.

Læs mere

Høringssvar vedrørende forslag til lov om ændring af lov om aktie- og anpartsselskaber og forskellige love (Obligatorisk digital kommunikation)

Høringssvar vedrørende forslag til lov om ændring af lov om aktie- og anpartsselskaber og forskellige love (Obligatorisk digital kommunikation) Erhvervs- og Vækstministeriet Slotsholmsgade 10-12 1216 København K Sendt til: om2@evm.dk Høringssvar vedrørende forslag til lov om ændring af lov om aktie- og anpartsselskaber og forskellige love (Obligatorisk

Læs mere

Automatisk og obligatorisk tilslutning. Hvis du blev tilmeldt Digital Post inden 1. november 2014. Mulighed for fritagelse

Automatisk og obligatorisk tilslutning. Hvis du blev tilmeldt Digital Post inden 1. november 2014. Mulighed for fritagelse Automatisk og obligatorisk tilslutning 1. november 2014 blev det lovpligtig at være tilsluttet Digital Post fra det offentlige. Denne dato skete der derfor en automatisk og obligatorisk tilslutning for

Læs mere

Digitale boligstøtteansøgninger. En administrativ fordel med voksende effekt for både borgere og administration

Digitale boligstøtteansøgninger. En administrativ fordel med voksende effekt for både borgere og administration Digitale boligstøtteansøgninger En administrativ fordel med voksende effekt for både borgere og administration JUNI 2003 1 Titel: Digitale boligstøtteansøgninger En administrativ fordel med voksende effekt

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

Læs mere

E-BOLIGHANDEL. Send sag til den finansielle sektor samt advokater tilmeldt e-bolighandel

E-BOLIGHANDEL. Send sag til den finansielle sektor samt advokater tilmeldt e-bolighandel Send sag til den finansielle sektor samt advokater tilmeldt e-bolighandel INDHOLD Indhold Indledning 3 Inden du går i gang 4 Tilslutnings aftale hos e-nettet 4 Opsætning af dine firmaoplysninger 4 Salgsopstilling

Læs mere

CVR i DPR. Database- og feltbeskrivelse

CVR i DPR. Database- og feltbeskrivelse CVR i DPR Database- og feltbeskrivelse 20. november 2013 CSC Danmark Copyright ll Rights Reserved. Side 2 af 25 Indholdsfortegnelse 1. Indledning... 3 2. Introduktion... 3 3. Databasebeskrivelse... 4 3.1

Læs mere

Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem

Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem 1 Indholdsfortegnelse A3.1 INTRODUKTION 3 A3.1.1 HENVISNINGER 3 A3.1.2 LÆSEVEJLEDNING 4 A3.1.2.1 SÅDAN

Læs mere

Bekendtgørelse om vejnavne og adresser

Bekendtgørelse om vejnavne og adresser Bekendtgørelse om vejnavne og adresser I medfør af 3c og 3f i lov om bygnings- og boligregistrering, jf. lovbekendtgørelse nr. 767 af 12. september 2002, som ændret ved 1 i lov nr. 601 af 24. juni 2005

Læs mere

En mappe anvendes til at organisere postkasser. Man kan godt lave et hierarki

En mappe anvendes til at organisere postkasser. Man kan godt lave et hierarki N OT AT Kontakthierarki i Dokumentboks Anbefaling fra KL Formålet med kontakthierarkiet i Dokumentboks er at henvendelser via Dokumentboks kommer til myndigheden ad den rette kanal, med de rette metadata

Læs mere

VEJDIREKTORATET. Vejdirektoratet DANBRO+ Modul 2 / Undermodul 2.3. DANBRO+ Forvaltningsmanual. Modul 2.3. Adresse- og telefonlister

VEJDIREKTORATET. Vejdirektoratet DANBRO+ Modul 2 / Undermodul 2.3. DANBRO+ Forvaltningsmanual. Modul 2.3. Adresse- og telefonlister Side: 1 af 11 VEJDIREKTORATET DANBRO+ Modul 2.3 Indholdsfortegnelse 1. INDLEDNING 3 2. FORMÅL OG ANVENDELSE 4 3. TEKNISK BESKRIVELSE INPUT AF DATA 4 3.1 Generelt 4 3.2 Adresse- og telefonlisten 4 3.3 Maillister

Læs mere

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. 1 2 KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. Det er frivilligt for kommuner at aftage systemet. Iht. den fælleskommunale

Læs mere

SIK-projektet Råd og anbefalinger for håndtering af virksomhedscertifikat

SIK-projektet Råd og anbefalinger for håndtering af virksomhedscertifikat SIK-projektet Råd og anbefalinger for håndtering af virksomhedscertifikat ne er 31. juli 2001, version Denne beskrivelse indeholder nogle råd og anbefalinger i forbindelse med bestilling, håndtering og

Læs mere

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen... 3 2 Formål

Læs mere

Vejledning til brug af dybe link i Digital Post

Vejledning til brug af dybe link i Digital Post Vejledning til brug af dybe link i Digital Post Denne vejledning beskriver hvordan man kan linke til forskellige dele af Digital Post fra eksterne hjemmesider Version: 2 Udarbejdet: juli 2015 Udarbejdet

Læs mere

e-tinglysning Digital signering

e-tinglysning Digital signering e-tinglysning Digital signering Søren Gjesse Business Systems Architect e-mail: sgjesse@csc.com Bjarne Hansen Business Systems Architect e-mail: bhansen4@csc.com Indledning Digital Signering i e-tinglysning

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

DOKUMENTBROKER Koncept

DOKUMENTBROKER Koncept DOKUMENTBROKER Koncept Copyright 2012 INDHOLDSFORTEGNELSE 1 Hvad er DokumentBrokeren?...1 1.1 Formål...1 1.2 Fordele...1 1.3 Baggrund...2 2 Komponenter...3 2.1 Dataflet...4 2.2 Platform og teknologi...4

Læs mere

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S 24-03-2009 Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S Problemstilling ved DBK integration i BIM Software Domæner og aspekter Det domæne, der primært

Læs mere

Eksempel 1: Kvalitetskontrol ved stikprøver og opslag i it-systemet

Eksempel 1: Kvalitetskontrol ved stikprøver og opslag i it-systemet Procedurer for kvalitetskontrol 3 eksempler ---------------------------------------------------------------------------------------------------------------------------------------------- Eksempelsamlingen

Læs mere

Høringssvar vedrørende Specifikation af serviceinterface for person (part)

Høringssvar vedrørende Specifikation af serviceinterface for person (part) IT- og Telestyrelsen Holsteinsgade 63 2100 København Ø Høringssvar vedrørende Specifikation af serviceinterface for person (part) Dette er KLs høringssvar på den offentlige høring om specifikation af serviceinterface

Læs mere

Blanketdokumentation LÆ 141, 142 & 145 v1.0 Februar 2011

Blanketdokumentation LÆ 141, 142 & 145 v1.0 Februar 2011 Blanketdokumentation LÆ 141, 142 & 145 v1.0 Februar 2011 Indholdsfortegnelse 1. Indledning... 3 1.1 Baggrund... 3 1.2 Blanketternes anvendelse... 4 1.3 Den papirbaserede arbejdsgang... 5 1.4 Den fremtidige

Læs mere

Håndter adgang til arkivalier

Håndter adgang til arkivalier Håndter adgang til arkivalier Samarbejdsproces mellem kommuner og Udbetaling Danmark - udmøntning af opgavesplit Udbetaling Danmark, 25. maj 2012 Version 1.5 1 Håndter adgang til arkivalier Definition

Læs mere

Brugervejledning for ansøgninger til Nordea-fonden Projekter med landsdækkende relevans

Brugervejledning for ansøgninger til Nordea-fonden Projekter med landsdækkende relevans Brugervejledning for ansøgninger til Nordea-fonden Projekter med landsdækkende relevans Før du begynder at udfylde den elektroniske ansøgning, anbefaler vi, at du skriver denne vejledning ud og gennemlæser

Læs mere

Digital post Snitflader Bilag C Filbaseret Version 6.3

Digital post Snitflader Bilag C Filbaseret Version 6.3 Digital post Snitflader Bilag C Filbaseret Version 6.3 1 C.1 Indholdsfortegnelse C.1 INDHOLDSFORTEGNELSE... 2 C.2 LÆSEVEJLEDNING... 4 C.3 TILMELDINGSLISTE... 5 C.3.1 RECORD-STRUKTUR... 5 C.3.1.1 HEADERRECORD...

Læs mere

Udvalget for Videnskab og Teknologi 2009-10 UVT alm. del Svar på Spørgsmål 33 Offentligt

Udvalget for Videnskab og Teknologi 2009-10 UVT alm. del Svar på Spørgsmål 33 Offentligt Udvalget for Videnskab og Teknologi 2009-10 UVT alm. del på Spørgsmål 33 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg 1240

Læs mere