Dagsorden. OIO- Komitéens 4. møde. d. 9. oktober Dagsorden

Transkript

1 Dagsorden, OIO-komitéens møde den 9. oktober 2008 Dagsorden OIO- Komitéens 4. møde d. 9. oktober 2008 Mødet afholdes d. 9. oktober 2008 fra kl. 13 i Mødelokal B, 4 sal, IT- og Telestyrelsen, Holsteinsgade 63. Dagsorden 1. Velkomst 2. Godkendelse af dagsorden og referat (B) (Bilag 1) 3. Meddelelser (O) 4. Præsentation af Digitalisér.dk (Bilag 2) (O) 5. Arkitekturkravsprojektet: Drøftelse af 15 skarpe og 10 principper (Bilag 3) (B) 6. Målgruppe OIO-udvalget for Social og Omsorg (Bilag 4) (B) 7. Semantikdefinitioner for OIOXML-kerneskemaer (Bilag 5) (B) 8. Ledelsesinformation FESD - (Bilag 6) (B) 9. Standard for integrationsmønstre - (Bilag 7) (B) 10. Standarder for procesbeskrivelse (Bilag 8) (B) 11. Eventuelt 12. Punkter til næste møde samt mødedatoer i 2009 (D) Sekretariatet foreslår datoerne: 29. januar, 6. marts, 23. april, 4. juni og 20. august. 30. september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Per de Place Bjørn Telefon E-post ppb@itst.dk Punkter mærket B, D, E, O er til henholdsvis (B) Beslutning (D) Drøftelse (E) Efterretning

2 Dagsorden, OIO-komitéens møde den 9. oktober 2008 (O) Orientering Dagsordenen er vedlagt en opdateret liste over standarder under behandling i OIO- Sekretariatet. 30. september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Per de Place Bjørn Telefon E-post ppb@itst.dk

3 Referat OIO komiteens 3. møde, den 21. maj Mødet afholdtes den 21. maj fra kl.12-14:45 i Direktionens mødelokale, 4. sal, IT- og Telestyrelsen, Holsteinsgade 63 Til stede: Per Schultz Eeg, ITST, formand Thomas Andersen, Beskæftigelsesministeriet Kristian Alstrup Baden, Region Nordjylland Frank Carvalho, Skat Kaspar Didriksen, Miljøministeriet Peter Greifenstein, Rigspolitiet Franci Johansen, Direktoratet for Fødevareerhverv Ole Makne Jørgensen, Direktoratet for Kriminalforsorgen Flemming Nissen, Kort & Matrikelstyrelsen Mogens Pedersen, Integrationsministeriet Christian Plaschke, Finansministeriet Torben Sløk, Vejdirektoratet Jan Dalsten Sørensen, Statens Arkiver Peter Thrane, KL Gitte Jeppesen, ITST Michael Bang Kjeldgaard, ITST Michael Busk-Jepsen, ITST Søren Klostergaard Pedersen, ITST Per de Place Bjørn, ITST, referat 1. Velkomst 2. Godkendelse af dagsorden og referat (B) (Bilag 1) - Dagsorden og referat godkendt 3. Det nye OIO katalog a) status og visioner (O) (Bilag 2) Oplæg fra IT- og Telestyrelsen, Thomas Maarup, er vedlagt referatet - KL, Peter Thrane, efterlyste en grafisk, semantisk definition til at understøtte OIO-kataloget. En måde til at veksle mellem teksten og en grafisk visning.

4 - Skat, Frank Carvalho efterlyste måder, hvorpå man kunne orientere sig, om den sti man havde fulgt undervejs når man bruger OIO kataloget, så man ikke mister orienteringen. Der er tale om at synliggøre den faktiske vej, ikke den konkrete placering. Altså et redskab der giver en fornemmelse af, hvor man befinder sig, i forhold til øvrig information. I øvrigt stor opbakning til projektet. Komiteen inviteres til live demo den 26. juni kl. 14. Tilmelding til tpm@itst.dk Fra komiteens side var der positive tilkendegivelser om deltagelse. b) Anvendelse af AGILE/SCRUM processer i udviklingen af OIO kataloget (O) (Bilag 3) Oplæg fra IT- og Telestyrelsen, Christian Lanng, er vedlagt referatet. - Skat, Frank Carvalho tilføjede til præsentationen, at en forudsætning for at AGILE/SCRUM er effektivt er, at have dygtige medarbejdere og en dygtig leverandør. Hvis en af delene svigter, har man et problem. Det kan derfor være risikabelt at køre et 100 millioners projekt på denne måde. - Det tilføjedes fra Sundhedsministeriet, Esben Dalsgaard, at man også kan stille spørgsmålet om man tør køre et traditionelt projekt til 100 millioner kroner, og at det er godt initiativ med at høste erfaringer med en ny udviklingsmetode. Der lægges op til på et senere tidspunkt at tage temaet op igen, når der er lidt flere erfaringer at trække på. Der blev tilkendegivet, at dette havde komiteens interesse. 4. OIO-udvalgene a) Skabelon for kommissorium for OIO udvalg (B) (bilag 4) -Kort- og Matrikelstyrelsen/Flemming Nissen delte overvejelser omkring kommissorier. I forbindelse med den konkrete skabelon for kommissorium for OIO udvalg påpeges det, at strategiafsnittet er mindst færdig. Det er vanskeligt at finde på relevante strategiformuleringer som passer ind i denne sammenhæng. -Velfærdsministeriet, Jesper Nielsen mente, at når man laver kommissorium skal man tænke over, hvor man placerer strategierne. I en række tilfælde vil strategierne være beskrevet i anden sammenhæng, fx i en domænebestyrelse eller styregruppe. Det kan i så fald være en fordel at pille noget governance ud, og bare komme i gang. - Generelt var der tilslutning til den eksisterende skabelon, og forslag om et lidt klarere fokus på principperne, og et forslag om en visuel demonstration til at belyse hvorledes OIO-udvalgene er placeret i fht. det øvrige organisatoriske setup. OIO-komitéen godkendte skabelonen for kommissoriet med de faldne bemærkninger. b) OIO udvalg for stedbestemmende referencedata (B) (bilag 5) -Kort- og Matrikelstyrelsen, Flemming Nissen fortalte om EU tiltag angående geografisk infrastruktur for at understøtte miljøet i EU som anledning til at binde danske og europæiske data sammen. Der blev foreslået at flere ministerier deltog i sådan noget arbejde. -OIO udvalget for referencedata blev godkendt uden kommentarer. c) OIO-udvalg for ESDH området (B) (Bilag 6)

5 - Komiteen var enige om udvalgets berettigelse, men udvalgets navn affødte en del diskussion da dette ikke var rammende nok, og samtidig inddrog et system. Der blev udtrykt ønske om at navnet skulle være systemafhængigt samt tydeligere signalere udvalgets område. - Der blev i stedet foreslået OIO udvalget for sags- og dokument håndtering eller OIO udvalget for tværgående sags og dokumenthåndtering. - Både Miljøministeriet og Undervisningsministeriet meddelte, at de ønskede at deltage i dette udvalg. - Udvalget blev godkendt med de faldne bemærkninger. d) Invitation til netværksmøde for OIO-udvalg (B) (Bilag 7) -Der var i Kommissionen enighed om, at netværksmøder for OIO-udvalg var en god ide, og der var tilslutning til forslag om et oplæg fra en udefra. - Mødet er fastsat til den 19. juni - Det blev desuden aftalt, efter forslag fra komiteen, at IT- og Telestyrelsen påtager sig den praktiske opgave med at opdatere mail- og kontaktoplysninger. 5. Arkitekturkrav opfølgning på workshop (B) (Bilag 8) Oplæg fra IT- og Telestyrelsen, Michael Bang Kjeldgaard, er vedlagt referatet. Som opfølgning på workshop i OIO komiteen den 8. maj blev det fremlagt, hvorledes der er arbejdet videre med arkitekturkravsprojektet. Efter et møde i KIU der havde tilkendegivet en accpet under forudsætning af opbakning i komitéen, var det op til komiteen at godkende de foreslåede indsatsområder, som derefter fremlægges for STS. -Sundhedsministeriet, Esben Dalsgaard mente, at det er en god ramme, der er blevet skabt. Kombination af ramme og iterativ proces er vigtigt. En ting der skurer lidt, er, at de overordnede principper er gledet ned i niveau. Sundhedsministeriet så det mere som noget der satte rammerne eller guidede. -Velfærdsministeriet, Jesper Nielsen kommenterede på formuleringerne i notatet. I forbindelse med fremlæggelsen for STS er det vigtigt at formulere sig klart, der hvor man gerne vil have myndighederne til at gøre noget. Samtidig skal man være varsom med at bruge ordet krav. - det blev pointeret, på baggrund af kommentarer fra komiteen som havde forstået visse dele af notatet anderledes, at pointen er, at myndighederne skal følge kravene, når det giver mening for dem. Kravet er således at de skal forholde sig til det. - Der skal derfor indskrives nogle ekstra elementer i notatet som gør dette klart for STS. - Der var tilslutning til de fem indsatsområder, dog med de faldne bemærkninger. Det blev desuden fremlagt at der muligvis ville blive planlagt en workshop mellem den 16. og 20. juni. [I skrivende stund regner vi ikke med at holde den./mbk] 6. Målgruppedefinition på det sociale område (O) (bilag 9) Velfærdsministeriet, Jesper Nielsen orienterede komiteen om velfærdsministeriets oplevelser med standardiseringsarbejdet. Erfaringen er, at selv om standarden er på plads kan processen tage lang tid.

6 - Der var enighed i komiteen om at denne erfaring var brugbar for andre, og at det var værd at overveje disse elementer i processerne. 7. Eventuelt Ingen kommentarer til punktet.

7 BILAG 2 Cover Dagsordenspunkt 4, OIO- komitéen, 9. oktober 2008 Orientering Præsentation af Digitalisér.dk Resumé Digitalisér.dk er resultatet af IT- og Telestyrelsens arbejde med at forny og konsolidere sine digitaliseringsplatforme. Projektet har hidtil har været omtalt som det nye OIO-katalog, men er gået i luften med nyt navn og adresse i en betaversion 1. oktober i år. OIO-komiteen har været orienteret undervejs, og på mødet 9. oktober vil vi berøre følgende emner: > Demonstration af Digitalisér.dk beta > Orientering om procedure for migrering og backup af data fra eksisterende systemer > Omtale af relaterede projekter og nye muligheder o NDR 4.0 o Minivejledning til OIOXML o OIO-check > Orientering om udviklingsplaner for Digitalisér.dk september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Per de Place Bjørn Telefon Telefax E-post ppb@itst.dk Sagsfremstilling Fuldmægtig Thomas Pilegaard Maarup orienterer på mødet. Indstilling Det indstilles at komitéen modtager orienteringen.

8 BILAG 3 Cover Dagsordenspunkt 5, OIO- komitéen, 9. oktober 2008 Beslutning Arkitekturkravsprojektet: Drøftelse af 15 skarpe og 10 principper Resumé IT- og Telestyrelsen lancerede den 26. september styrelsens bud på 10 overordnede it-arkitekturprincipper og 15 skarpe anbefalinger med direkte betydning for arkitekturtilgangen og best practise i digitaliseringsprojekter. Lanceringen skete som led i lanceringen af den nye portal digitaliser.dk, som bl.a. samler den tidligere Infostrukturbase og OIO-kataloget. IT- og Telestyrelsen ønsker en drøftelse af, hvorvidt de 15 anbefalinger efter OIO-komiteens anbefalinger kan skabe merværdi og af, hvorvidt de 10 principper er retningsgivende for god IT-arkitektur. Sagsfremstilling Dialogen med OIO-komitéen og andre nøgleinteressenter i første halvår har vist, at der ikke er en udbredt efterspørgsel eller behov for hårde krav til arkitektur. Omvendt er der klangbund for at præsentere nogle bedste praksis anbefalinger som umiddelbart kan omsættes til praksis. Komiteen har bl.a ønsket at anbefalingerne er enkle og overskuelige, at anbefalingerne er modne og tilfører projektet værdi, og at de giver mening for myndighederne. Før sommerferien godkendte OIO-komitéen og KIU en indstilling om at arbejde videre med et sæt overordnede principper, samt udvikling af krav inden for fire indsatsområder, nemlig Netsteder, Integration af forretningsservices, Fælles begreber og genbrug af data samt Arkitektur- og risikostyring. 30. september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Michael Bang Kjeldgaard Telefon Telefax E-post mbk@itst.dk Vi har derfor formuleret 15 anbefalinger, der er funderet i bedste praksis fra hele den offentlige sektor. Anbefalingerne giver værdi at følge lige nu, og der er empirisk belæg for dem alle. Desuden har vi formuleret 10 principper for it-arkitektur. Vi forventer, at principperne har en længere levetid end anbefalingerne../.. De 10 overordnede principper, 15 skarpe bedste praksisanbefalinger samt et dokument med uddybende eksempler og erfaringer er vedlagt. Arkitekturkravprojektet, kendt som initiativ 32 under den fællesoffentlige digitaliseringsstrategi, bliver således reformuleret til at dække følgende: Projektet opstiller overordnede principper og bedste praksis anbefalinger. Dermed opstilles der ikke hårde krav. Såvel principper som praksisanbefalinger formuleres som korte, konkrete og koncise sætninger og med henvisninger til yderligere oplysninger. Der sker kobling til forretningsbehov og værdi via eksempler på erfaringer.

9 For at sikre sammenhæng med styrelsen øvrige aktiviteter integreres principper og anbefalinger som nævnt i den nye portal digitaliser.dk. Målet er at integrere alt arbejde med standarder og arkitektur i én fælles proces og én fælles platform. Arkitekturkravprojektet omfatter også en leverance i form af en målemetode og måling af fremdrift. Dette behandles på komitéens næste møde. Indstilling Det indstilles, at OIO komitéen tager den justerede projekttilgang til efterretning at komitéen drøfter det vedlagte udkast til principper og anbefalinger at komitéen på baggrund af drøftelsen indstiller principper og anbefalinger til godkendelse i Styregruppen for Tværoffentligt Samarbejde. Ministeriet for Videnskab, Teknologi og Udvikling 2

10 It-arkitekturprincipper

11 > It-arkitekturprincipper It- og Telestyrelsens udkast til overordnede principper for offentlige itprojekter Udgivet af: IT- & Telestyrelsen Publikationen kan downloades på IT- og telestyrelsens hjemmeside og på ISBN (internet): IT- & Telestyrelsen Holsteinsgade København Ø Telefon: Fax:

12 > Principper for it-arkitektur It- og Telestyrelsens udkast til overordnede principper for offentlige it-projekter Et debatoplæg (denne version drøftes i OIO-komiteen ) IT- & Telestyrelsen oktober 2008

13 Indhold > Indledning 5 Byg rigtigt, når du bygger nyt 5 Ti overordnede principper for it-arkitektur 7 Forretningsbehov skal drive og definere løsningerne. 7 Borgere og virksomheder skal sættes i centrum. 7 Processer skal optimeres før digitalisering. 7 Data skal have entydigt ejeskab og skal genbruges. 8 Åbenhed skal sikre konkurrence og innovation. 8 Løsninger skal være løst koblede. 8 Løsninger skal være agile. 9 Løsninger skal være enkle og billige. 9 Informationssikkerhed fra start til slut. 9 Brug den fællesoffentlige ramme for it-arkitektur. 10

14 Indledning > Formålet med principperne for offentlige digitaliseringsprojekter og itinvesteringer er at gøre den offentlige it-portefølje så nyttig, innovativ, produktiv, fleksibel og kosteffektiv som mulig. IT- og Telestyrelsen har i samarbejde med en række statslige og kommunale aktører opstillet principperne. Lokale myndigheder kan anvende principperne helt eller delvist med udgangspunkt i lokale forretningsstrategier. Principperne er tænkt som en fælles ramme for den offentlige sektor. Ikke alle principper vil passe lige godt til det enkelte projekt nogle vil ramme mere plet end andre. It-arkitekturprincipper skal altid afvejes i forhold til situationen. Byg rigtigt, når du bygger nyt Nogle af principperne kan måske forekomme lige lovligt heroiske og vil koste en bondegård at implementere fuldt ud i alle eksisterende løsninger i dag. Derfor handler principperne om at gøre det rigtige, når der er en anledning til det. F.eks. når en myndighed bygger en ny webservice eller en ny indberetningsløsning. Eller når en myndighed moderniserer et eksisterende system. Principper skal følges pragmatisk, og myndighederne skal samtidig være opmærksom på de øvrige redskaber, som skal bruges ved større udviklinger og anskaffelser, som fx Finansministeriets business-case-model. De overordnede principper suppleres af en række konkrete anbefalinger om bedste praksis i digitaliseringsprojekter. 5

15 6 >

16 Ti overordnede principper for it-arkitektur > Princip 1: Forretningsbehov skal drive og definere løsningerne. Rationale: It-investeringerne skal understøtte forretningens opgaver, og ikke omvendt. Det er derfor forretningsbehovet, der skal drive og definere løsningerne, samt den arkitektur og de standarder, som løsningerne anvender. Implikationer: Offentlige myndigheder skal etablere organisatoriske og styringsmæssige rammer for en velfungerende koordinering mellem forretning og it. Der skal kunne svares positivt og konkret på spørgsmålet Hvordan sikrer I, at jeres valg af it-arkitektur, standarder og løsninger passer til jeres forretning? Princip 2: Borgere og virksomheder skal sættes i centrum. Rationale: It-investeringer skal skabe bedre service og nye digitale tjenester, som giver konkret nytteværdi og er enkle at anvende for borgere og virksomheder. Implikationer: Borgere og virksomheder bør inddrages i udviklingen af løsninger, fx ved brug af fokusgrupper og personas. Løsninger bør stilles til rådighed, så de altid er tilgængelige, og via de kanaler og terminaltyper, som er udbredte blandt brugerne. Det bør sikres, at brugergrænsefladen er brugervenlig og tilgængelig også for personer med funktionsnedsættelse. Princip 3: Processer skal optimeres før digitalisering. Rationale: Værdien ved digitalisering realiseres gennem bedre service og effektivisering fx ved hurtigere sagsbehandling eller ved at bruge færre ressourcer på at nå samme resultat. Forenkling og automatisering er en vigtig nøgle hertil. Derfor skal forretningsprocesser optimeres inden digitalisering. Implikationer: Forretningsprocesser bør så vidt muligt optimeres i forbindelse med digitalisering. De processer, som en myndighed udfører, bør kortlægges og analyseres for at identificere muligheder for mere effektive og værdiskabende processer. Især ensartede og tværgående, borgervendte processer og forretningsservices skal, hvor det er relevant, harmoniseres i og på tværs af myndigheder. Myndighederne skal samtidig have styr på data: Centrale forretningsbegreber skal defineres og udvekslingsformater skal fastlægges af forretningen ikke af it-leverandøren. 7

17 > Princip 4: Data skal have entydigt ejeskab og skal genbruges. Rationale: Borgere og virksomheder bør kun indberette oplysninger én gang og den offentlige sagsbehandling skal i højere grad ske automatisk. Dette skal understøttes af en mere smidig udveksling af data fra centrale registre og på tværs af myndigheder. Implikationer: Alle offentlige data bør have et tydeligt ejerforhold og et tydeligt identificeret ansvar for indsamling og vedligehold. Data, som én offentlig myndighed allerede har, bør genbruges, før man spørger borgere og virksomheder om data. Data skal udveksles i fælles datastandard. Princip 5: Åbenhed skal sikre konkurrence og innovation. Rationale: Åbne standarder og åbne arkitekturer, som tillader udvidelser og integration med nye softwarekomponenter, er et afgørende fundament for interoperabilitet og dermed forretningsmæssigt samarbejde og udvikling i den offentlige sektor. Åbne standarder er desuden vigtige for at skabe øget konkurrence og innovation på et åbent marked, hvor offentlige myndigheder gør sig uafhængige af enkeltleverandører. Implikationer: It-løsninger bør baseres på åbne standarder, som bl.a. kan findes på digitalisér.dk. Konkrete løsninger bør tage udgangspunkt i fællesoffentlige referencearkitekturer. Snitflader skal dokumenteres og udstilles på digitalisér.dk og i øvrigt kunne tilgås af alle relevante parter. Princip 6: Løsninger skal være løst koblede. Rationale: It-løsninger skal bygges efter princippet om løs kobling for at sikre fleksibilitet og genbrug af data og komponenter. På sigt giver dette billigere og bedre løsninger. Implikationer: Offentlige it-systemer bør udvikles, så afhængigheder mellem ellers integrerede dele af en it-løsning fjernes mest muligt, herunder bør brugergrænseflade, applikation og infrastruktur adskilles (løs kobling). Borgerog virksomhedsvendte services bør i særlig grad udvikles således, at brugergrænsefladen er udskiftelig og adskilt fra resten af it-løsningen, så de fx kan afvikles i flere relevante portaler og via flere kanaler, herunder ikke mindst mobile kanaler. 8

18 > Princip 7: Løsninger skal være agile. Rationale: Forretningsbehov skal bestemme kravene til fleksibilitet, skalérbarhed og robusthed det må ikke være teknikken, som sætter grænser for forretningen. Offentlige it-systemer og den bagvedliggende infrastruktur skal bygges med udgangspunkt i de forretningsmæssige krav og være i stand til at tilpasse sig ændrede forretningsmæssige behov. Implikationer: It-løsninger skal udformes, så de løbende kan tilpasses eller udvides i takt med forretningsmæssige behov. Understøttelse af tværgående arbejdsgange skal arkitekturmæssigt kunne afkobles fra de lokale systemer, således at udfald ikke blokerer for de primære, lokale arbejdsopgaver. For at imødekomme øgede it-omkostninger i fremtiden bør it-systemer bygges, således at kapaciteten kan op- og nedjusteres, og gøres robuste over for ændringer i organisatoriske opdelinger. Princip 8: Løsninger skal være enkle og billige. Rationale: Gennem at tilstræbe enkle løsninger frem for komplekse løsninger overalt, hvor det er muligt, opnås samlet set en væsentligt mere effektiv itinfrastruktur. Genbrug og samarbejde kan spare meget på it-budgettet og kan både sikre en mere konsolideret portefølje og efterspørgselskraft. Implikationer: Overvej genbrug af eksisterende systemer frem for indkøb af nye systemer. Overvej indkøb af standardsystemer frem for udvikling af nye systemer. Overvej fælles indkøb frem for individuelt indkøb. Overvej opsplitning af store, komplekse løsninger i mindre, simplere komponenter. Overvej fælles digitale løsninger og fælles drift. Brug altid andres services, hvis det er bedst og billigst. Og udstil altid dine egne mulige fælleskomponenter som services. Princip 9: Informationssikkerhed fra start til slut. Rationale: Borgere og virksomheder skal have tillid til digital forvaltning. Den offentlige forvaltnings håndtering af følsomme oplysninger skal sikre fortrolighed, privacy og administrativ robusthed. Offentlige it-systemer bør beskytte information og funktionalitet, så uvedkommende ikke kan tilgå disse. Information må ikke kunne kompromitteres hverken tilsigtet eller utilsigtet. Implikationer: Sikkerhed omkring håndteringen af data og driftens robusthed skal tænkes ind fra starten i såvel forretnings- som teknisk arkitektur og skal følge data fra vugge til grav. Offentlige myndigheder bør overholde relevante standarder for informationssikkerhed og privacy. 9

19 > Princip 10: Brug den fællesoffentlige ramme for it-arkitektur. Rationale: En fælles metoderamme og terminologi kan sikre gennemsigtighed og sammenlignelighed, når tværoffentlige projekter skal beskrive og analysere it-løsninger. Dermed kan dobbeltinvesteringer undgås. Implikationer: Digitaliseringsprojekter bør understøtte samarbejde og genbrug med udgangspunkt i den fællesoffentlige arkitekturramme for digitaliseringsprojekter, der fx omfatter OIO-arkitekturmetoden, den fælles offentlige referencemodel FORM, referencearkitektur for sags- og dokumentområdet mv. Brug redskaberne pragmatisk, dvs. dér hvor de skaber værdi for dit projekt. Alle relevante fællesoffentlige redskaber kan findes på digitalisér.dk. 10

20

21 15 skarpe til digitalisering af Danmark

22 15 mål at sigte efter Som offentlig it-chef, projektleder eller professionel der arbejder med digitalisering, skal du træffe mange valg i en hektisk hverdag. Derfor har IT- og Telestyrelsen samlet 15 klare best practice-anbefalinger, der kan bruges som en praktisk rettesnor i hverdagen. Vi håber, at vi med disse anbefalinger kan være med til at fremme god it-arkitektur i det offentlige. Anbefalingerne er rettet mod de udfordringer, som det offentlige står med lige nu, og bygger på aktuelle erfaringer fra hele den offentlige sektor. Læs mere på digitalisér.dk, og deltag i debatten om digitaliseringen af Danmark. Få styr på forretningsgangene 1 4 Modellér og dokumentér dine forretningsprocesser med beskrivelsesstandarden BPMN. Når du har styr på arbejdsgangene, har du skabt grundlaget for at optimere din organisation. Brug fleksible udviklingsmetoder Brug agile udviklingsmetoder og spis elefanten i små bidder. Nedbryd opgaver i mindre komponenter, og test løbende løsningerne i praktisk brug. Det giver bedre løsninger og mindre risiko for at overskride budget og tidsplan. Anvend fælles forretningsterminologi 2 5 Brug den fællesoffentlige referencemodel, FORM, især i digitaliseringsprojekter, der går på tværs af myndigheder. En fælles terminologi skaber overblik og sikrer fokus på, hvor man kan genbruge services. Dataudveksling skal anvende fælles datastandarder Brug OIO datastandarder / OIOXML i itløsninger, der udveksler data med andre myndigheder. Det giver billigere og bedre dataudveksling. Brug open source-software ved egenudvikling 3 6 Overvej open source, især når du selv udvikler. Udgiv egenudviklet software under open source-licens. Brug Softwarebørsen til at udstille og skaffe ny software. Offentlige portaler skal hænge sammen Brug den offentlige integrationsmodel for portaler til integration af webbaserede services. På den måde sikres sammenhæng mellem de store portaler og myndighedernes hjemmesider.

23 Webservices skal være nemme at finde og anvende 7 12 Dokumentér eksterne, digitale services med et servicestamkort på digitalisér.dk - så der er ét sted at finde de fælles ressourcer. Stil krav om åbne standarder Anskaf løsninger, der bygger på åbne standarder på digitalisér.dk. Åbne standarder fremmer interoperabilitet og konkurrence. Webservices skal kunne tale sammen 8 13 Anvend de anbefalede standarder i implementeringsmodel for forretningsservices ved implementering af web-services. Så er I fremtidssikrede i forhold til samspillet med resten af den offentlige sektor. Skab sikre løsninger Offentlige myndigheder bør udarbejde en Privacy Impact analyse (PIA), det vil sige en analyse af, hvordan hensynet til privatlivet inddrages, ved nye it-projekter. Brug digital signatur og single-sign-on 9 14 Følg de fællesoffentlige retningslinier og standarder for implementeringen af digital signatur og single-sign-on. Så kan alle offentlige løsninger tilgås på en ensartet måde, hvilket giver borgere og virksomheder værdi. Få styr på it-arkitekturen Brug OIO arkitekturmetoden og arkitekturreolen som fælles referenceramme for arbejdet i digitaliseringsprojekter. Så er der styr på dokumentationen og samarbejdet lettes. Basér indkøb og salg på den fælles infrastruktur for handel Brug NemHandels standarder, komponenter og infrastruktur, når du implementerer e-handel. På den måde bærer de fælles investeringer en stor del af dine omkostninger. Del viden og samarbejd på tværs Opret en gruppe på digitalisér.dk, når du starter et nyt it-projekt, og stil dokumentation til rådighed for andre myndigheder. På den måde er du med til at sprede erfaringer og bedste praksis. 11 Brug fælles sprog på sagsog dokumentområdet Brug OIO-referencearkitektur for sags- og dokumentområdet til at få styr på ESDH og omegn. Så er løsningen gearet til forretningsmæssige forandringer og nye integrationer. Læs mere om digitalisering

24 Digitalisér.dk På digitalisér.dk finder du konkrete eksempler, erfaringer og links til uddybende information om de enkelte anbefalinger. Her kan du også læse mere om de 10 overordnede principper for it-arkitektur, som ligger bag anbefalingerne. Digitalisér.dk er din nye indgang til offentlig itarkitektur og standardisering. Her finder du bl.a. en samlet oversigt over de fællesoffentlige anbefalinger om tekniske standarder (kendt som OIO-kataloget) og fællesoffentlige datastandarder (kendt som Infostrukturbasen, ISB en). Portalen vil løbende blive udbygget med nye tjenester og nyt indhold. Digitalisér.dk henvender sig til myndigheder, leverandører og andre, der ønsker at deltage i udviklingen af det digitale Danmark. Digitalisér.dk er udviklet af IT og Telestyrelsen bl.a. med brug af agile udviklingsmetoder og som open source. IT- og Telestyrelsen Holsteinsgade København Ø Telefon: itst@itst.dk

25 < Digitalisér.dk På digitalisér.dk kan du læse mere om it-arkitekturprincipper og anbefalinger Digitalisér.dk er din nye indgang til offentlig it-arkitektur og standardisering. Her finder du bl.a. en samlet oversigt over de fællesoffentlige anbefalinger om tekniske standarder (kendt som OIO-kataloget) og fællesoffentlige datastandarder (kendt som Infostrukturbasen, ISB en). Portalen vil løbende blive udbygget med nye tjenester og nyt indhold. Digitalisér.dk henvender sig til myndigheder, leverandører og andre, der ønsker at deltage i udviklingen af det digitale Danmark. Digitalisér.dk er udviklet af IT- og Telestyrelsen bl.a. med brug af agile udviklingsmetoder og som open source.

26 Her virker de 15 skarpe Best practice i digitalisering af Danmark

27 > Her virker de 15 skarpe Best practise i digitalisering af Danmark Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade København Ø Publikationen kan downloades på IT- og telestyrelsens hjemmeside og på ISBN (internet): Telefon: Fax:

28 > Her virker de 15 skarpe Best practise i digitalisering af Danmark IT- & Telestyrelsen oktober 2008

29 Indhold > 15 skarpe anbefalinger her virker de 5 Få styr på forretningsgangene 5 Anvend fælles forretningsterminologi 5 Brug open source-software ved egenudvikling 6 Brug fleksible udviklingsmetoder 6 Dataudveksling skal anvende fælles datastandarder 7 Offentlige portaler skal hænge sammen 7 Webservices skal være nemme at finde og anvende 8 Webservices skal kunne tale sammen 8 Brug digital signatur og single-sign-on 9 Basér indkøb og salg på den fælles infrastruktur for handel 9 Brug fælles sprog på sags- og dokumentområdet 10 Stil krav om åbne standarder 10 Skab sikre løsninger 11 Få styr på it-arkitekturen med metodik 11 Del viden og samarbejd på tværs 12

30 15 skarpe anbefalinger her virker de > 1. Få styr på forretningsgangene Modellér og dokumentér dine forretningsprocesser med beskrivelsesstandarden BPMN. Når du har styr på arbejdsgangene, har du skabt grundlaget for at optimere din organisation. Kortlagte og optimerede processer fremmer effektiv udnyttelse af ressourcer, forbedrer mulighederne for at have styr på forretningsbegreberne (datastandardisering) og øger mulighederne for at kunne udvikle/købe it, som understøtter forretningens behov. BPMN Business Process Modeling Notation er et sprog eller en standard for at lave procestegninger / arbejdsgangsdiagrammer. Nydefinerede processer skal udstilles med BPMN på digitalisér.dk, så de er søgbare for andre. Det giver mulighed for genbrug. Beskrivelser af arbejdsgange er en vigtig del af den fællesoffentlige referencearkitektur for sags- og dokumentområdet. KL har i en årrække med KL s arbejdsgangsbank arbejdet med at beskrive kommunale forretningsgange med brug af BPMN. 2. Anvend fælles forretningsterminologi Brug den fællesoffentlige referencemodel, FORM, især i digitaliseringsprojekter, der går på tværs af myndigheder. En fælles terminologi skaber overblik og sikrer fokus på, hvor man kan genbruge services. FORM er et fælles landkort over den offentlige sektor, der kan anvendes til at finde, analysere og udnytte moderniseringsmuligheder i den offentlige sektor, herunder specielt muligheder for fælles offentlig opgaveløsning og digitalisering. Med FORM sikrer man, at man anvender det samme fælles begrebsapparat som andre offentlige instanser. Dette letter samarbejdet på tværs og understøtter, at man kan finde mulighederne for genbrug af andres løsninger eller samdrift. En række store tværgående offentlige løsninger er opmærket med FORM fx borger.dk, mit virk.dk, den Fælles Offentlige Adressedatabase og digitalisér.dk og FORM er indarbejdet i KL-emnesystematik og KL s arbejdsgangsbank. 5

31 > 3. Brug open source-software ved egenudvikling Overvej open source, især når du selv udvikler. Udgiv egenudviklet software under open source-licens. Brug Softwarebørsen til at udstille og skaffe ny software. Genbrug af en it-løsning, som er finansieret af én myndighed, giver en besparelse hos andre myndigheder, som kan bruge samme løsning. Man kan også dele viden og erfaringer samt samarbejde om udvikling og vedligehold af løsningen. Gentofte Kommune havde behov for en let måde at publicere mødereferater m.v. på sit netsted. Løsningen blev en såkaldt integrationskomponent mellem kommunens ESDH og CMS-systemer, og resultatet blev lagt på Softwarebørsen. Region Midt har nu baseret store dele af et projekt på Gentoftes Kommunes komponent. Samarbejdet er udmøntet i projektet Tværoffentlig ESDH Samarbejdsforum på Softwarebørsen. En stor del af serviceudbyderne på borger.dk anvender open-source-toolkits til singlesign-on-integrationen. Dermed opnår de billigere integration og kan også dele integrationserfaringer indbyrdes. 4. Brug fleksible udviklingsmetoder Brug agile udviklingsmetoder og spis elefanten i små bidder. Nedbryd opgaver i mindre komponenter, og test løbende løsningerne i praktisk brug. Det giver bedre løsninger og mindre risiko for at overskride budget og tidsplan. Fleksible udviklingsmetoder som f.eks. Agile og Scrum fokuserer på løbende justering af mål, krav og leverancer igennem mange iterationer. Med fleksible metoder laver man løbende nye iterationer, hvor man kravspecificerer, udvikler og tester. Med fleksible metoder vil man hurtigt kunne teste delløsninger. De skal ses i modsætning til den traditionelle vandfaldsmetode, som fordrer definition af samtlige ønsker til funktionalitet i den færdige løsning ved en samlet kravspecifikation, inden man går i gang med selve udviklingen. Netstedet digitalisér.dk bygger på open source-komponenter og er udviklet med agil udviklingsmetode. 6

32 > 5. Dataudveksling skal anvende fælles datastandarder Brug OIO-datastandarder / OIOXML i it-løsninger, der udveksler data med andre myndigheder. Det giver billigere og bedre dataudveksling. Når der skal udveksles data, skal de forretningsmæssige begreber og de tekniske udvekslingsformater være klare, og data og definitioner skal generelt tænkes til genbrug. Data skal overholde OIO navngivnings- og designregler (OIOXML). Det sikrer, at itløsningerne kan tale sammen og ikke skal konvertere data. Det sikres også, at begreber og udvekslingsformater, som én gang er defineret, kan genbruges. Det effektiviserer udviklingen af it-systemer. Genbrug de relevante datadefinitioner, der ligger på digitalisér.dk. Findes der ikke datadefinitioner for dét, der er behov for, bør man oprette dem. Dette gælder i særdeleshed for data, der er af tværgående interesse. Fælles datastandarder giver i dag værdi på en række områder: Sygedagpengeløsningen på virk.dk, CPR, sektorstandardisering inden for fødevaresektoren og den kommunale blanketserver (OIB.dk) er eksempler på områder, hvor der er opnået fordele med OIOXML. Datastandardisering er også grundlaget for de store besparelser, som følger af elektronisk handel i såvel offentlige myndigheder som i private virksomheder. 6. Offentlige portaler skal hænge sammen Brug den offentlige integrationsmodel for portaler til integration af webbaserede services. På den måde sikres sammenhæng mellem de store portaler og myndighedernes hjemmesider. Integrationsmodellen understøtter genbrug af metoder og løsninger og giver dermed reducerede omkostninger til udvikling og integration hos portalejere og myndighederne. Integrationsmodellen indeholder konkrete retningslinjer for udvikling, integration, videreudvikling og brug af services til de offentlige portaler. Ved at benytte samme udviklingsmetoder og standarder kan leverandørerne tilbyde billigere portalløsninger til offentlige kunder, og de offentlige myndigheder kan anvende samme infrastruktur til at integrere til flere forskellige portaler med. Portalerne borger.dk og virk.dk anvender fx de samme standarder for single-sign-on. Det betyder, at hvis man kan integrere til den ene portal, kan man også gøre det til den anden. Det giver et stort besparelsespotentiale. Andre eksempler på metoder for integration i de to portaler er i første omgang integration via HTML-links eller som iframes, og senere integration via web-services, der følger metoderne i Implementeringsmodel for forretningsservices. 7

33 > 7. Webservices skal være nemme at finde og anvende Dokumentér eksterne, digitale services med et servicestamkort på digitalisér.dk så der er ét sted at finde de fælles ressourcer. De enkelte myndigheder skal dokumentere services med et servicestamkort på digitalisér.dk s serviceregister. Dokumentationen skal omfatte nogle få oplysninger formuleret i forretningsorienteret prosa. Services i form af data og funktionalitet kan først deles og genbruges, hvis de er identificerbare og tilgængelige. Når de er det, kan de enkelte projekter herefter spare både tid og penge ved at genanvende de services, der findes. I det omfang myndigheden er klar til det, bør også selve den tekniske servicedefinition og SLA beskrives. Erfaringer fra e-handel viser potentialet i registrering af services, idet der i efteråret 2008 er adskillige tusinde services hos såvel offentlige som private organisationer registreret i NemHandels serviceregister (UDDI). Det gør e-handel nemmere og billigere. Inden længe vil denne model blive udbredt i hele Europa. Fra 1. februar 2009 vil det være muligt generelt at registrere services på digitalisér.dk. Denne tjeneste vil omfatte både de forretningsmæssige og de tekniske registreringer. 8. Webservices skal kunne tale sammen Anvend de anbefalede standarder i implementeringsmodel for forretningsservices ved implementering af web-services. Så er I fremtidssikrede i forhold til samspillet med resten af den offentlige sektor. Når offentlige instanser udstiller og udveksler data via webservices, er det vigtigt, at grænsefladerne til disse webservices implementeres på en ensartet måde. Der er udarbejdet en implementeringsmodel for forretningsservices, der giver vejledning om valg af webservice-standarder i det offentlige. Modellen indeholder et antal metoder (mønstre) med tilhørende specifikationer, som dækker forskellige anvendelsessituationer og formål. For eksempel findes der mønstre for sikker og pålidelig udveksling af potentielt følsomme dokumenter og for sikker punkt-til-punkt-kommunikation mellem to sikkerhedsdomæner. Udbygningen af nationale løsninger på sundhedsområdet (f.eks. det Fælles Medicinkort) sker altid med en fælles webservice-standard, hvilket både giver færre omkostninger og hurtigere integration 8

34 > 9. Brug digital signatur og single-sign-on Følg de fællesoffentlige retningslinier og standarder for implementeringen af digital signatur og single-sign-on. Så kan alle offentlige løsninger tilgås på en ensartet måde, hvilket giver borgere og virksomheder værdi. Den digitale signatur giver mulighed for sikkert at identificere sig og dermed lave indberetninger, sende og udfylde blanketter, fortrolige dokumenter, kontrakter og meget mere direkte over nettet. Indberetninger og materialer kan sendes krypteret, så ingen uvedkommende kan få adgang til informationerne. Ligeledes kan tilbud og formularer publiceres på nettet, så kunder kan udfylde og underskrive med en digital signatur. Med single-sign-on koblet med digital signatur eller direkte fra eget netværks-log-in får borgere og virksomheder mulighed for at agere på tværs af myndigheder, uden at skulle logge ind flere gange. Samtidig opnås en række muligheder for tværgående integration: Medarbejdere får mulighed for at arbejde på tværs af systemgrænser på basis af roller og synkroniserede brugerdata. Muligheden for systemintegration og lettere arbejdsgange har stor potentiel værdi. Offentlige løsninger, der vil tilbyde single-sign-on, kan gratis tilslutte sig Nem-Login-løsningen, der er etableret i et fællesoffentligt samarbejde. NemLog-in anvendes blandt andet af løsningerne i den nye version af Borger.dk, Skats Tast-Selv-service, Min SU og studielånsløsningen. Den fællesoffentlige single-sign-on tjeneste er baseret på den tekniske standardprofil OIO SAML 2.0 til overførsel af information om identitet og rettigheder i forbindelse med tværgående bruger-styring og understøtter digital signatur. 10. Basér indkøb og salg på den fælles infrastruktur for handel Brug NemHandels standarder, komponenter og infrastruktur, når du implementerer e-handel. På den måde bærer de fælles investeringer en stor del af dine omkostninger. NemHandel er en samlet pakke til håndtering af forretningsdokumenter i forbindelse med køb og salg fx ordreafgivelse og fremsendelse af regning. Når virksomheder skal sende en regning til en myndighed, sendes den i et godkendt format. Selve udvekslingen kan ske med et NemHandel-program til at sende og modtage fakturaer. NemHandel omfatter processtandarder, begrebs- og datastandarder, arkitekturmønstre, profiler på anvendelse af tekniske standarder, open source softwarekomponenter og fælles infrastrukturservices. Det står alle softwareudviklere frit for at indbygge NemHandel i eksempelvis software til bogholderi. Flere kommercielle it-leverandører er allerede begyndt at indbygge NemHandel i deres eksisterende løsninger. 9

35 > 11. Brug fælles sprog på sags- og dokumentområdet Brug OIO-referencearkitektur for sags- og dokumentområdet til at få styr på ESDH og omegn. Så er løsningen gearet til forretningsmæssige forandringer og nye integrationer. Elektroniske sags- og dokumentbehandlingssystemer i offentligt regi skal kunne tale sammen på tværs, således at man kan følge en sag fra start til slut. Med én fælles arkitektur, informationsmodel og med standardiserede dataudvekslingsformater får kunder, udviklere og leverandører et fælles sprog til at tale om de konkrete løsninger. Det sparer udviklingsomkostninger og giver større træfsikkerhed. Referencearkitekturen lanceret i efteråret 2008 omfatter en række nye elementer, f.eks. en komponentstruktur med åbne standardiserede snitflader, der gør det lettere at integrere mellem ESDH og fagsystemer og genbruge komponenter på tværs af løsninger. Der er enighed blandt myndigheder og leverandører om, at referencearkitekturen er en milepæl i den fremtidige drøftelse og udvikling af ESDH i det samlede itarkitekturlandskab og i det offentliges systemportefølje. 12. Stil krav om åbne standarder Anskaf løsninger, der bygger på åbne standarder på digitalisér.dk. Åbne standarder fremmer interoperabilitet og konkurrence. Anvendelsen af åbne standarder fremmer interoperabilitet mellem it-systemer på tværs af den offentlige sektor og understøtter, at borgere og virksomheder har et friere valg af software og af leverandører. Alle myndigheder skal stille krav om, at leverandører overholder de obligatoriske og anbefalede åbne standarder på digitalisér.dk, når der anskaffes nye løsninger. Regeringens aftale med KL og Danske Regioner om anvendelse af åbne standarder for software i det offentlige og udmøntningerne heraf skal overholdes, fordi åbne standarder fremmer konkurrence og giver værdi. Fx gav det, at den fællesoffentlige single-sign-on-løsning er baseret på den åbne SAML 2.0-standard, en stor fordel ved valg af operatør, hvor man ikke var låst fast til kun at kunne kigge på operatører, som anvendte løsninger fra en specifik leverandør. 10

36 > 13. Skab sikre løsninger Offentlige myndigheder bør udarbejde en Privacy Impact analyse (PIA), det vil sige en analyse af, hvordan hensynet til privatlivet inddrages, ved nye it-projekter. En PIA skal sikre, at hensyn og lovgivning omkring privatlivets fred er behandlet og fastholdt under hele projektet, og dermed efterleves i det resulterende system eller tjeneste. Et centralt mål med udarbejdelsen af en PIA er desuden effektivt at kommunikere varetagelsen af hensyn til privatlivet indadtil og udadtil. Flere andre lande har erfaring for, at en offentliggjort PIA virker og giver værdi til offentlige it-projekter. Blandt de lande, der er længst fremme på området, findes Canada, Australien og New Zealand. En dansk model for PIA forventes offentliggjort på en nyt netsted privacyportal.dk om hensyn til privatlivets fred, som lanceres primo Få styr på it-arkitekturen med metodik Brug OIO arkitekturmetoden og OIO arkitekturreolen som fælles referenceramme for arbejdet i digitaliseringsprojekter. Så er der styr på dokumentationen og samarbejdet lettes. For at udvikle og indføre effektive og sikre it-løsninger til det offentlige er det vigtigt, at digitaliseringsprojekter arbejder professionelt med både forretnings- og itarkitektur. Fælles metodik og sprog om dokumentationen støtter samarbejdet om kortlægning, analyse, kravspecificering og design af løsninger. OIO arkitekturmetoden bruges både som ramme og støtte for planlægning af projekters fremgangsmåde og leverancer, og som systematik til klassifikation af dokumentation, samt som fælles sprog i dialog og koordinering. Metoderammen anvendes både af enkeltmyndigheder og i tværoffentlige projekter. Et konkret eksempel er projektet om referencearkitektur for sags- og dokumenthåndtering, der bruger OIO rammen som fælles sprog. Arkitekturmetodens trin og arkitekturreolens leverancer er løbende grundlag for dialog på tværs af de deltagende myndigheder og leverandører. 11

37 > 15. Del viden og samarbejd på tværs Opret en gruppe på digitalisér.dk, når du starter et nyt it-projekt, og stil dokumentation til rådighed for andre myndigheder. På den måde er du med til at sprede erfaringer og bedste praksis. På digitalisér.dk kommer der i begyndelsen af 2009 mulighed for, at de enkelte itprojekter kan oprette en gruppe, som kan udstille information om projektet som fx formål, tids- og leveranceplan, oversigt over projektmedlemmer, kontaktinformation og lignende. Det er tillige muligt at uploade/downloade projektdokumenter som fx arkitekturtegninger, XML-skemaer, servicestamkort, rapporter og andre ressourcer. De uploadede ressourcer vil indgå som ressourcer i det samlede digitalisér.dk med tydelig angivelse af projektets ejerskab. Det vil blive muligt at få kommentarer, kritik og konstruktive idéer fra andre brugere. Visionen kan sammenlignes med web 2.0-tjenester som Wikipedia og Softwarebørsen. Begge steder gælder det, at det er nemt at bidrage med lidt, og at der er stor værdi at hente. 12

38

39 < Digitalisér.dk På digitalisér.dk kan du læse mere om it-arkitekturprincipper og anbefalinger Digitalisér.dk er din nye indgang til offentlig it-arkitektur og standardisering. Her finder du bl.a. en samlet oversigt over de fællesoffentlige anbefalinger om tekniske standarder (kendt som OIO-kataloget) og fællesoffentlige datastandarder (kendt som Infostrukturbasen, ISB en). Portalen vil løbende blive udbygget med nye tjenester og nyt indhold. På digitalisér.dk kan du også læse mere om de 10 overordnede principper for itarkitektur, som ligger bag de 15 skarpe best practise-anbefalinger. Digitalisér.dk henvender sig til myndigheder, leverandører og andre, der ønsker at deltage i udviklingen af det digitale Danmark. Digitalisér.dk er udviklet af IT og Telestyrelsen bl.a. med brug af agile udviklingsmetoder og som open source.

40 BILAG 4 Cover Dagsordenspunkt 6, OIO-komitéen, 9. oktober 2008 Beslutning Servicestyrelsen Skibhusvej 52 B 5000 Odense C OIO-komitéen Tlf servicestyrelsen@servicestyrelsen.dk september / MTH Godkendelse af områdespecifik standard for målgruppe Formål Formålet med standarden er dels at skabe standardiserede grænseflader til dels at stille standardiserede grundbegreber til rådighed for udviklere af itsystemer på socialområdet. Under hele godkendelses forløbet er OIOXML-skemaet faktisk blevet bruget i flere andre itsystemer. I forbindelse med opbygningen af Tilbudsportalen har Servicestyrelsen analyseret begrebssystemer på socialområdet i samarbejde med relevante parter. Dette arbejde er beskrevet på Afleveringen indeholder skemaet for grundbegrebet målgruppedefinition til klassen for områdespecifikke standarder. Dette skema vedrører indberetninger til Tilbudsportalen. Sagsfremstilling Der er i 2006 offentliggjort "Strategi for digitalisering på det sociale område " (se Denne strategi har som et af sine indsatsområder "Fælles begrebsdannelse og anvendelse". Arbejdet med den aktuelle aflevering sker inden for rammerne af strategien. Standarden ønskes optaget i klassen af områdespecifikke standarder Semantikken for målgruppedefinitionen er godkendt i OIO-udvalget for Social og Omsorg efter, at den har været i høring. Det begrebsapparat, der ligger til grund for denne aflevering, kan ses på: Begreberne bag det indleverede skema er beskrevet i "Manual begrebsstrukturpostfinal.doc" Målgruppedefinitionen indeholder en række lister eller udfaldsrum. Disse er dokumenteret i skemaet, som er placeret i InfoStrukturbasen på følgende adresse: Skemaet har været igennem sagsbehandling i OIO-sekretariatet og NDR godkendt.

41 Overblik over namespace Namespace er delt ind som følger Schemaerne i denne aflevering ligger i "common". Senere afleveringer på området for social og omsorg kan placeres i mapper som dækker ældreområdet, børn og unge, handicapområdet mv. Overblik over begreber og værdilister Målgrupper Type Type - dokumentation Samling Samlingdokumentation Værdier Værdierdokumentation Skemanavn xml.schemas/social_maalgruppecode.xsd xml.schemas/social_maalgruppecode.xsd.meta.xml xml.schemas/social_maalgruppecodecollection.xsd xml.schemas/social_maalgruppecodecollection.xsd.meta.xml xml.docs/ext_maalgruppecode.xml xml.docs/ext_maalgruppecode.xml.meta.xml Begreber i indberetningsskema findes på Dokumenter er også vedlagt som bilag. Indstilling Det indstilles at OIO-komitéen godkender standarden for målgruppedefinition som områdespecifik standard, med virkefelt sammenfaldende med OIO-udvalget for Social og Omsorgs forretningsområde. For OIO-udvalget for Social og Omsorg, Michael Dyhr Thomsen IT konsulent mth@servicestyrelsen.dk /5

42 BILAG: SOCIAL_YdelseMaalgruppeKode.xsd

43 4/5

44 5/5

45 BILAG 5 Cover Dagsordenspunkt 7, OIO- komitéen, 9. oktober 2008 Beslutning Semantikdefinitioner for OIOXML- kerneskemaer Resumé Forslag til semantikdefinitioner for de eksisterende OIOXML-kerneskemaer har været i høring fra 1. september 2008 til 21. september På baggrund af de indkomne bemærkninger er der udarbejdet et revideret forslag til forelæggelse for OIO-Komitéen. Sagsfremstilling Kernekomponent-arbejdsgruppen under OIO-Datastandardiseringskomitéen har udviklet OIOXML skemaer til anvendelse ved udveksling af informationer om personer baseret på CPR s dataregister. Standard-forslaget har været i offentlig høring i perioden 1/ /9-08 og der er i alt indkommet 20 høringssvar hvoraf de 8 indeholder kommentarer og forbedringsforslag. Høringsmaterialet og høringssvarene kan ses på høringsportalen: På baggrund af indholdet af høringssvarene er der foretaget en tilretning af forslaget. Det oprindelige såvel som det reviderede forslag kan ses på ITSTs hjemmeside: om/kernekomponenter/semantikdefinitioner (i PDF, Excel, ODF og OOXML). 1. oktober 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Adam Arndt Telefon Telefax E-post adar@itst.dk Indstilling Det indstilles, at komitéen godkender de reviderede semantikdefinitioner for OIOXML-kerneskemaerne således, at disse kan udstilles i det nye OIO-Katalog. Bilag - Høringsnotat - Revideret forslag til semantikdefinitioner samt indhold af høringssvar.

46 Høringsnotat Semantikdefinitioner for OIOXML-kerneskemaer Resultat af høring om semantikdefinitioner for OIOXMLkerneskemaer Resumé Forslag til semantikdefinitioner for de eksisterende OIOXML-kerneskemaer har været i høring fra 1. september 2008 til 21. september Der er indkommet i alt 20 høringssvar, hvoraf de 8 indeholder kommentarer og forbedringsforslag. På baggrund af de indkomne bemærkninger er der udarbejdet et revideret forslag til forelæggelse for OIO-Komitéen. Sagsfremstilling Kernekomponent-arbejdsgruppen under OIO-Datastandardiseringskomitéen har udviklet OIOXML skemaer til anvendelse ved udveksling af informationer om personer baseret på CPR s dataregister. Standard-forslaget har været i offentlig høring i perioden 1/ /9-08 og der er i alt indkommet 20 høringssvar fra de nedenstående organisationer: BaneDanmark DANTERM Datatilsynet Domstolsstyrelsen Forbrugerstyrelsen Forsvarskommandoen Integrationsministeriet KMD Kommunernes Landsforening Kort- og Matrikelstyrelsen Ministeriet for Sundhed og Forebyggelse Odense Kommune OIO-Udvalget for Social og Omsorg Region Sjælland Rigsrevisionen Sikkerhedsstyrelsen SKAT Vejdirektoratet Velfærdsministeriet Økonomistyrelsen 12 af høringssvarene indeholder ingen kommentarer til standarden. Høringsmaterialet og høringssvarene kan ses på høringsportalen:

47 Tilretning af forslag til semantikdefinitioner På baggrund af de indkomne høringssvar har OIOXML-Sekretariatet udarbejdet et revideret forslag til semantikdefinitioner. Disse kan hentes fra IT- og Telestyrelsens hjemmeside: efinitioner/revideret-udkast-til-semantikdefinitioner-for-kerneskemaer Forslaget vil blive forelagt OIO-Komitéen til godkendelse på deres møde d. 9. oktober Ministeriet for Videnskab, Teknologi og Udvikling 2

48 Tema Udtryk Definition Forklaring Rationale Eksempel Schema URL Alternativt udtryk Person Køn Angiver individets køn ved at skelne mellem han- og hunkøn Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema DKCC_PersonGenderCode.xsd Fødselsdato Den dato et individs fødsel fandt sted Bruges fortløbende til at erklære en persons alder. Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema DKCC_BirthDate.xsd Nationalitet Nation, som en person har statsborgerskab i Begrebet statsborgerskab er traditionelt bundet til denne form for definition DKCC_PersonNationalityCode.xsd CPR-nummer Data om personer, der efter 2. april 1968 har været tilmeldt dansk folkeregister for Grønlands Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema CPR_PersonCivilRegistrationIdentifier.xsd vedkommende dog efter 1. maj Personer, der er bosat uden for Danmark, men som i kraft af medlemskab af ATP eller pligt til at svare skat, har fået tildelt et personnummer. Der tildeles desuden Unik identifikation af en person i Det Centrale Personregister personnumre til andet administrativt behov (administrative personnumre). Civilstand Om en person er eller har været gift eller på anden måde samlevende Definitionen tager udgangspunkt i registreringerne i CPR CPR_MaritalStatusCode.xsd med en anden person Mellemnavn Et eller flere navne som supplerer en persons fornavne og efternavn Baseret på gældende lovgivning om personnavne DKCC_PersonMiddleName.xsd Fornavn Et eller flere navne som identificerer en person indenfor en slægt Baseret på gældende lovgivning om personnavne DKCC_PersonGivenName.xsd Efternavn Et navn som angiver en persons tilhørsforhold til en slægt Baseret på gældende lovgivning om personnavne DKCC_PersonSurnameName.xsd Vej Metermål afstand fra et referencepunkt til en vejs startpunkt fratrukket antal hele angiver sammen med Kilometermål den præcise afstand fra startpunktet Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_RoadPointMetreMeasure.xsd kilomenter Kilometermål afstand fra et referencepunkt til en vejs startpunkt fratrukket antal hele angiver sammen med Metermål den præcise afstand fra startpunktet Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_RoadPointKilometreMeasure.xsd kilomenter Målemetode Generalisering af definition godkendt i fællesoffentlig høring som beskrivelse af OIOXMLkerneskema VEJSEKTOREN_RoadMeasureMethodCode.xsd metode til at foretage en måling Administrativt vejnummer unik kode til administrativ identifikation af en vej Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_RoadIdentifier.xsd Historisk Vejforgreningskode vejforgreningskode der har været i brug tidligere anførelse af hidtidig vejforgreningsbetegnelse som en huskehjælp til fagfolk. Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_RoadHistoricBranchCode.xsd Beskrivelse En fri tekst, der beskriver et objekt eller en egenskab Vejforgreningsnumre starter med 001, som angiver den første forgrening på vejen. Der er i mange sammenhænge behov for at videregive beskrivende information som det ikke VEJSEKTOREN_RoadDescriptionText.xsd er nødvendigt eller hensigtsmæssigt at strukturere formelt ForgreningsID løbenummer for vejforgrening på en administrativ vej Angiver vejforgreningens nummer, således at 001 er den første forgrening på vejen. Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_RoadBranchIdentifier.xsd Beskrivelse En fri tekst, der beskriver et objekt eller en egenskab Der er i mange sammenhænge behov for at videregive beskrivende information som det ikke VEJSEKTOREN_RoadBranchDescriptionText.xsd Vejforgreningsnumre starter med 001, som angiver den første forgrening på vejen. er nødvendigt eller hensigtsmæssigt at strukturere formelt Vejforgreningskode Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema sidevej VEJSEKTOREN_RoadBranchCode.xsd tilkørselsrampe frakørselsrampe kode for vejforgreningstypen parkeringsplads Administrativ Vejstrækning vejstrækning som er en del af en administrativ vej Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_NationalRoadCatalogueSegmentReferenceCollection.xsd Administrativ vej vej der er administrativt entydigt identificeret kan også benyttes til private veje og stier Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_NationalRoadCatalogueRoad.xsd Referencepunkt Et punkt har flere formål, dels at beskrive startpunkt og slutpunkt for en vejstrækning, dels at angive Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema VEJSEKTOREN_NationalRoadCatalogueReferencePoint.xsd geografisk placering af skilte, lysanlæg og andet fast udstyr. Desuden anvendes punkt til stedfæstelse identificeret punkt på en vej der anvendes som reference af uheld. Vejforgrening Generalisering af definition godkendt i fællesoffentlig høring som beskrivelse af OIOXMLkerneskema sideveje til en boligvej eller p- motorvejsramper, rundkørsler, VEJSEKTOREN_NationalRoadCatalogueBranch.xsd punkt på en vej hvor en anden vej eller en del af en vej har sit start- eller slutpunkt pladser knyttet til en vej. Kommentar En tekst relateret til et objekt eller en egenskab uden at videregive Generel definition som bør kontekstualiseres via indlejring i objekter og/eller specialisering VEJSEKTOREN_CommentText.xsd specifik strukturerbar information om subjektet Ejendom Stednavnidentifikator Unik identifikator brugt til at referere til et rumligt objekt, fx et punkt, en Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_PlaceNameIdentifier.xsd kurve eller en flade. Stednavn Et navn eller et toponomi element brugt til at referere til et rumligt objekt, Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_PlaceName.xsd fx et punkt, en kurve eller en flade Hovednoteringsnummer Identifikation for en samlet fast ejendom jf. udstykningsloven. Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_LandPropertyIdentifier.xsd Matrikelnummer Entydig identifikation af en flade/parcel inden for et ejerlav. Ikke entydig på landsplan uden LandsejerlavsKoden. Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_LandParcelIdentifier.xsd Fikspunktnummer Nationalt entydig identifikation af fikspunkter Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_GroundControlpointIdentifier.xsd Gitterelement Betegner cellestørrelsen og koordinaterne på det nederste venstre (SV) brugt til positionering af generaliserede hierakiske områder. Geodata brugt i forbindelse med gitteret Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_GridElementIdentifier.xsd hjørne af et kvadratisk område baseret på kortprojektionen: UTM zone 32skal konverteres til EUREF89 før denne forbindelse. datum EUREF89 Ejerlavsnavn Tekstmæssig betegnelse for et ejerlav. Ejerlavsnavnet er ikke entydig. Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_CadastralDistrictName.xsd Landejerlavskode En på landsbasis entydig identifikation af et ejerlav. Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema KMS_CadastralDistrictIdentifier.xsd Ejendom En unik nøgle til en ejendom i fx ESR stamregister og Nøglen består af to nøglefelter: Myndighedskode og ejendomsnummer Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_RealPropertyStructure.xsd Vurderingssystemet. Kommunalt ejendomsnummer Den kommunale fast ejendoms-identifikator identificerer den enkelte Den kommunale fast ejendoms-identifikator er opbygget af 5 cifre og et kontrolnummer. Den Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_MunicipalRealPropertyIdentifier.xsd ejendom indenfor kommunen. kommunale fast ejendoms-identifikator er unik indenfor den enkelte kommune. Når den kommunale fast ejendoms-identifikator komplementeres med kommunekoden identificerer den ejendommen unikt på landsplan. Bankkonto Internationalt Bankkontonummer En tekst som entydigt identificerer en bankkonto i en bank i et hvilket som Der er behov for at kunne identificere en bankkonto uafhængigt af, hvilket land, kontoførende ITST_ForeignBankAccountIdentifier.xsd helst land bank er beliggende i Filialnummer Et tal som entydigt identificerer en afdeling af en bank i Danmark, Alle filialer af danske pengeinstitutter har en entydig filialkode som indgår som en del af ITST_BankBranchIdentifier.xsd Grønland eller Færøerne identifikationen af danske bankkonti Bankkonto Entydig angivelse af en dansk, grønlandsk eller færøsk bankkonto Sammenstilles kontonummer med registreringsnummer fremkommer en unik identifikator for ITST_BankAccountStructure.xsd en konto i en dansk bank. Bankkontonummer Et tal som entydigt identificerer en bankkonto i en afdeling af en bank i Alle bankkonti har et nummer som er unikt indenfor filialen ITST_BankAccountIdentifier.xsd Danmark, Grønland eller Færøerne Adresse Enhedsadresse Entydig angivelse af danske enhedsadresser dvs. entrédøren inkl. evt. Struktureret, kodebaseret udveksling af adressedata fra system til system, når personens, Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) XKOM_AddressSpecific.xsd etage og dørbetegnelse, til bolig- og erhvervsenheder, baseret på de virksomhedens eller husstandens fuldstændige lejlighedsadresse er nødvendig. Eksempler: kunde- og officielle identifikationer (koder) fra CPR og BBR. kreditordatabaser, folke-, bolig- og virksomhedsregistrering mv. Nyt i denne version: Genbruger OIOXML-Kernekomponenten AddressAccess. Postadresse Struktureret tekstbaseret udveksling af komplette, læsbare Entydig angivelse af den komplette, skrevne postadresse, baseret på de læsbare adressebetegnelser Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) XKOM_AddressPostal.xsd postadresseoplysninger fra system til menneske eller fra system til (vejnavn, bynavn, postnummer, postdistrikt m.m.). Eksempler: kunde- og kreditordatabaser, system, når de tilhørende adressekoder fra CPR og BBR ikke er til medlemslister, postforsendelser og lign. Da datatypen er baseret på tekststrenge, og ikke på koder, er rådighed. den følsom overfor indtastningsfejl, forskellige stavemåder mv. Komplet adresse Struktureret format, der indeholder både koder og tekst i én og samme Kan bruges hvor en komplet adresse med koder og tilhørende tekst ønskes overført fra system til Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) XKOM_AddressComplete.xsd aggregering. system eller fra system til menneske. Adgangsadresse Entydig angivelse af danske adgangsadresser dvs. indgangsdøren i Struktureret, kodebaseret udveksling fra system til system, når hoveddørsadressen er tilstrækkelig. Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) XKOM_AddressAccess.xsd gadeplan, baseret på de officielle identifikationer (koder) fra CPR og BBR. Adresselinje En linje i en postadresse, der er registreret som et antal tekstlinjer uden DKCC_PostalAddressThirdLineText.xsd yderligere strukturering eller specificering Adresselinje En linje i en postadresse, der er registreret som et antal tekstlinjer uden DKCC_PostalAddressSixthLineText.xsd yderligere strukturering eller specificering Adresselinje En linje i en postadresse, der er registreret som et antal tekstlinjer uden DKCC_PostalAddressSecondLineText.xsd yderligere strukturering eller specificering Adresselinje En linje i en postadresse, der er registreret som et antal tekstlinjer uden DKCC_PostalAddressFourthLineText.xsd yderligere strukturering eller specificering Adresselinje En linje i en postadresse, der er registreret som et antal tekstlinjer uden DKCC_PostalAddressFirstLineText.xsd yderligere strukturering eller specificering Adresselinje En linje i en postadresse, der er registreret som et antal tekstlinjer uden DKCC_PostalAddressFifthLineText.xsd yderligere strukturering eller specificering Postboksnummer Identifikationsnummer for en postboks. Unikt indenfor det enkelte postdistrikt DKCC_PostOfficeBoxIdentifier.xsd Bygningsnummer Unikt tal, der repræsenterer en bygning/bygninger, som er en del af en Lov om bygnings- og boligregistrering DKCC_BuildingIdentifier.xsd ejendom. Vejnavn Det fastsatte navn på en vej, et torv, en plads, en sti og lignende. Vejnavne kan tillige fastsættes for andre særligt afgrænsede geografiske områder såsom Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_StreetName.xsd haveforeninger eller feriebebyggelser uden vejnet, mindre øer uden vejnet, større idrætsanlæg og lignende. Postnummer Post Danmarks landsdækkende postnummerkode. Postnumrene fastsættes af Post Danmark Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_PostCodeIdentifier.xsd Supplerende bynavn Navn på landsby, by, bydel eller andet lokalt stednavn som er fastsat for Et supplerende bynavn fastsættes for alle adresser i området, herunder for et nærmere bestemt antal Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_DistrictSubdivisionIdentifier.xsd at præcisere adressebetegnelsen. adresser på en vej (angivet ved intervaller af husnumre). Postdistrikt Navn på det område eller posthus som er knyttet til postnummeret Navnet fastsættes af Post Danmark Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_DistrictName.xsd Dørbetegnelse Identifikation, der beskriver placeringen af en specifik indgangsdør på en Betegnelserne tv, mf og th bruges når der er indtil tre døre på trappeafsatsen. Hvis der er flere Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_SuiteIdentifier.xsd etage eller en etageafsats i den opgang der refereres til døre anvendes normalt 1, 2, 3, 4 osv. Andre betegnelser på indil 4 tegn kan dog også fastsættes. Husnummer Nummergetegnelse incl. et eventuelt stort bogstav, der indentificerer en Husnumrene fastsættes i stigende orden langs vejen, normalt med lige numre på højre side og ulige Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_StreetBuildingIdentifier.xsd bestemt adgang til en bygning, en grund/jordstykke eller et teknisk anlæg numre på venstre side af vejen. Indgår et bogstav i adressen, er dette en nødvendig del af den o.lign. baseret på den navngivne vej eller gade, som giver adgang til fuldstændige og korrekte adresse. denne. Gård- eller bygningsnavn Gårdnavn, navn på ejendom, bygning eller bolig eller lignende navn på Lokalitet er et supplement til adressebetegnelsen som vil være entydig selvom det udelades. Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_MailDeliverySublocationIdentifier.xsd lokaliteten, som knyttes til en adgangsadresse. Etage Identifikation, der beskriver etagen eller etageafsatsen på hvilken en Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) DKCC_FloorIdentifier.xsd specifik indgangsdør, lejlighed, eller sidedør er placeret i den opgang der refereres til. Landekode Kode som identificerer en nationalstat DKCC_CountryIdentificationCode.xsd Postadresse* En postadresse, der er registreret som et navn plus 2-6 tekstlinjer uden CPR_CompletePostalLabel.xsd yderligere strukturering eller specificering

49 International postadresse Virksomhed Myndighed Adressepunkt Til brug på labels, rudekuverter og lign. Print af adresseoplysninger på formularer og brevforsendelser CPR_SecondaryPostalLabel.xsd og lign. baseret på CPRs standarder. Skal anvendes i adressesammenhænge, hvor der ikke er tale om en aktiv person i CPR-kontekst. Dvs. i de sammenhænge, hvor der er behov for at indsætte en af følgende adresser: 1. Kontaktadresse, 2. Supplerende adresse, 3. Valgadresse, 4. Værgeadresse Adresseoplysninger i form af tekstlinjer uden fast indhold eller bindinger eller 5. Udlandsadresse. Uformatteret postadresse En ustruktureret tekststreng som indeholder en postadresse CPR_CompletePostalLabelText.xsd Adressat Navnet på en postmodtager som angivet i en postlabel CPR_AddresseeName.xsd Vejadresseringsnavn En forkortelse af vejnavn. Vejadresseringsnavn angives hvis vejnavnet Bruges ved adressering på labels og rudekuverter og lign., hvor der ikke plads til det fulde vejnavn. Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) CPR_StreetNameForAddressingName.xsd er længere end 20 tegn. For navne op til 20 tegn er adresseringsvejnavnet det samme som vejnavnet. Vejkode Entydig identifikation af en navngiven vej, gade, plads, sti og lign., Egentlige vejnavne har koder i intervallet Koder >=9900 anvendes til administartive formål.adressebekendtgørelsen (BEK nr 1398 af 12/12/2006) CPR_StreetCode.xsd indenfor den pågældende kommune. Bestemt adgangsadresse Adgangsadresse, som er fastsat eller godkendt af kommunen efter Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006). Definition godkendt i fællesoffentlig BBR_AddressAccessDefinite.xsd bekendtgørelse om vejnavne og adresser, som er tildelt en globalt unik høring som beskrivelse af OIOXML-kerneskema og stabil adgangsadresseid og som er knyttet til en bestemt beliggenhed, repræsenteret af et adressepunkt Pnummer Kode som entydigt identificer lokaliterer som en virksomhed har eller har Pnummer er en forkortelse af Produktionsenhedsnummer Definition hentet fra Erhvervs- og Selskabsstyrelsen som tildeler numrene CVR_ProductionUnitIdentifier.xsd PNR haft aktiviteter fra. Ejerskabsart Kode for typen af ejerskab af en juridisk enhed, fx enkeltmandsfirma, Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema CVR_OwnershipTypeCode.xsd kompagniskab (evt. med begrænset ansvar), aktieselskab, regeringseller kommunal institution. Navn på juridisk enhed Tekst som angiver navnet på en juridisk enhed Ved en juridisk enhed forstås Lov om Det Centrale Virksomhedsregister (LBK nr 653 af 15/06/2006) CVR_LegalUnitName.xsd 1) En fysisk person i dennes egenskab af arbejdsgiver eller selvstændigt erhvervsdrivende. 2) En juridisk person eller en filial af en udenlandsk juridisk person. 3) En statslig administrativ enhed. 4) En region. 5) En kommune. 6) Et kommunalt fællesskab. Importørstatus Angivelse af om den pågældende juridiske enhed er registreret som Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema CVR_ImporterIndicator.xsd importør eller ej Eksportørstatus Angivelse af om den pågældende juridiske enhed er registreret som Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema CVR_ExporterIndicator.xsd eksportør eller ej CVRnummer Kode som entydigt identificer en virksomhed som har eller har haft Definition hentet fra Erhvervs- og Selskabsstyrelsen som tildeler numrene CVR_CVRnumberIdentifier.xsd aktiviteter i Danmark. Kommunekode Kode som entydigt angiver en bestemt dansk kommune Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema CPR_MunicipalityCode.xsd Myndighedskode Kode som entydigt angiver en bestemt dansk myndighed Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema CPR_AuthorityCode.xsd Geografisk punkt lokation Entydig angivelse af en position på jordens overflade i 2D eller 3D ved Bruges til at angive et punkts geografiske position (lokation) Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_GeographicPointLocation.xsd hjælp af geografiske koordinater i et bestemt referencesystem. Nordlig Nordlig værdi (y-værdi) i et geografisk koordinatsæt Bruges til at angive 2. koordinat i et koordinatsæt til et punkt Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_GeographicNorthingMeasure.xsd Højde Højde-angivelse (z-værdi) i et geografisk koordinatsæt Bruges til at angive 3. koordinat i et koordinatsæt til et punkt Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_GeographicHeightMeasure.xsd Østlig Østlig værdi (x-værdi) i et geografisk koordinatsæt Bruges til at angive 1. koordinat i et koordinatsæt til et punkt Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_GeographicEastingMeasure.xsd Koordinatsæt Et sæt af koordinater (østlig, nordlig samt evt. højde) i et bestemt Bruges til at angive et 2- eller 3-dimensionelt geometrisk punkt Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_GeographicCoordinateTuple.xsd geografisk referencesystem. Gyldig fra Den første dato hvor en given information er gyldig Bruges til at angive datoen fra hvilken en vis status for objektet er gældende Generel definition som bør kontekstualiseres via indlejring i objekter og/eller specialisering BBR_AddressPointValidStartDateTime.xsd Gyldig til Den sidste dato hvor en given information er gyldig Bruges til at angive datoen til og med en vis status for objektet er gældende Generel definition som bør kontekstualiseres via indlejring i objekter og/eller specialisering BBR_AddressPointValidEndDateTime.xsd Status Angivelse af en tilstand på et givet tidspunkt Bruges til at angive et kontrolleret udfaldsrum for en given status egenskab Generel definition som bør kontekstualiseres via indlejring i objekter og/eller specialisering BBR_AddressPointStatusStructure.xsd Opdateringstidspunkt Adressepunkt Koordinatkvalitetsklasse AdgangsadresseID adresse Angivelse af det klokkeslæt og dato, hvor en given information er Bruges til at angive databaseopdaterings- eller gyldighedstidspunkt for en opdateringshændelse Generel definition som bør kontekstualiseres via indlejring i objekter og/eller specialisering BBR_AddressPointRevisionDateTime.xsd opdateret Identifikation og beskrivelse af et geografisk sted (punkt) der Bruges til at repræsentere den geografiske belinegned af en bestemt adgangsadresse Adressebekendtgørelsen (BEK nr 1398 af 12/12/2006). Definition godkendt i fællesoffentlig BBR_AddressPoint.xsd repræsenterer beliggenheden af en bestemt adgangsadresse høring som beskrivelse af OIOXML-kerneskema Nøjagtighedsklasse for adressekoordinater (dvs. AddressPoint) jf. det Bruges til at angive en kvalitet for nøjagtigheden for et punkts geometriske position som funktion af Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_AddressCoordinateQualityClassCode.xsd offentlige adresseprojekt : hhv. absolut (A), dvs. korrekt positioneringsmetoden placeret, beregnet placering (B) eller uden koordinater (U), dvs ukendt placering. En global, unik og stabil identifikation (UUID) af en specifik Bruges også til at identificere en instans af et adressepunkt Definition godkendt i fællesoffentlig høring som beskrivelse af OIOXML-kerneskema BBR_AddressAccessIdentifier.xsd AdressepunktID adgangsadresse, uafhængig af adressens referencer til kommune, vejnavn eller husnummer. Den række af tegn der behøves for at en kan leveres til den Udfaldsrummet defineres i W3C-specifikationen RFC 822 XKOM_ AddressIdentifier.xsd korrekte postkasse til den påtænkte person, stilling eller kontor.

50 Høringspart Bemærkning ITSTs svar Økonomistyrelsen Økonomistyrelsens kommentar vedrører definitionerne for bankkonti, hvor det for filialnummer, bankkonto og bankkontonummer fremgår, at der skal være tale om banker i Danmark. Imidlertid anvender Statens Lønsystem også disse kerneskemaer til konti i banker på Færøerne og Grønland, hvor der er samme kontonummerstruktur. Vi foreslår derfor, at Færøerne og Grønland føjes til definitionen. Indarbejdes Forsvarskommandoen En række kommentarer til strukturerne i OIOXML kerneskemaerne Høringen omhandler ikke XML-skemaerne, men kun de semantiske definitioner. Disse kommenteres ikke i Forsvarskommandoens høringssvar Vejdirektoratet RoadDescriptionText; Udtryk bør rettes fra Beskrivelse til VejBeskrivelse; Definition bør rettes fra: En fri tekst, der beskriver et objekt eller en egenskab; bør rettes til: En fri tekst der beskriver en vej RoadBranchDescriptionText; Udtryk bør rettes fra Beskrivelse til VejforgreningsBeskrivelse; Definition bør rettes fra: En fri tekst, der beskriver et objekt eller en egenskab; bør rettes til: En fri tekst der beskriver en vejforgrening Det er intentionen at skrive en generisk definition af "beskrivelse" og lade konteksten præcisere anvendelsen Det er intentionen at skrive en generisk definition af "beskrivelse" og lade konteksten præcisere anvendelsen KMD Køn: ordet Erklærer bør fjernes eller ændres til f.eks.: Oplyser eller Angiver Indarbejdes Fødselsdato: Ordet Erklærer bør fjernes eller ændres til f.eks.: Oplyser eller Angiver ; Indarbejdes En persons alder beregnes eller udregnes Nationalitet: man er statsborger i et land/en nation Indarbejdes CPR-nummer: Uheldigt at detailbeskrivelsen indledes med: Personnummer (PNR), fordi Indarbejdes - feltet hedder CPR-nummer - PNR i virksomhedssammenhæng betyder: Produktionsenhedsnummer Udsagnet: Personnummeret kan også have værdien er forkert, når vi taler om unik identifikation. Derimod kan en persons relationer til andre personer (mor/far/ægtefælle/børn), kan det forekomme ifm. enten har ingen relation eller relation ikke oplyst Er der behov for definitioner af andre typer personnummer? 1. Erstatningspersonnummer som anvendes i kommunalt regi 2. Nationalt erstatningspersonnummer som anvendes i sundhedsvæsenet (Position 1=4-9; Position 2-9=0-9: Position 10=A-Z. Eksempel: D)) 3. Diplomatnummer som påtænkes anvendt af udenrigsministeriet (i et påtænkt CDR-system) Høringen omhandler alene semantikdefinitioner for eksisterende OIOXML-kerneskemaer, men forslagene er taget til efterretning. Fornavn, Mellemnavn & Efternavn: Bør slås sammen til en XML struktur indeholdende alle tre felter Hvorfor benyttes ikke i stedet feltet Adrdesseringsnavn, som netop er skabt til kommunikation/udveksling? Fornavn, Mellemnavn & Efternavn: Brug et andet ord end Erklærer Metermål & Kilometermål: Slå sammen til én XML struktur, navngives så det angiver relation til vej Beskrivelse: Begge udtryk navngives, så det tydeliggøres,at det er beskrivelse vedr. vej og vejforgrening ForgreningsID, Vejforgrening: Hvad er sammenhængen mellem disse? Kommentar: Hvorfor bruges kommentar i stedet for beskrivelse? Kommunalt ejendomsnummer: Ejendomsnummer er et 6-cfret nummer - altså uden kontrolciffer Internationalt Bankkontonummer: Det bør pointeres, at det drejer sig om IBAN nummer (hvis det er tifældet) Adresselinie (6 forekomster): Bør samles i én XML struktur, hvor fremgår, at der kan være op til 6 instanser (af adresselinier) Hvad er forskellen mellem Postadresse (defineret som et navn tekstlinier? Der er erklæret selvstændige kerneskemaer for såvel de enkelte "navnedele" som for det samlede adresseringsnavn, da der vurderes at være et behov for at kunne sende navne fuldt struktureret Indarbejdes Høringen omhandler ikke XML-skemaerne, men kun de semantiske definitioner. Det er intentionen at skrive en generisk definition af "beskrivelse" og lade konteksten præcisere anvendelsen De to begreber er semantisk forskellige Definitionen er baseret på den beskrivelse, der er godkendt af OIO-Datastandardiseringskomiteen efter offentlig høring. Begrundede ændringsforslag modtages gerne. Denne definition er ikke begrænset til IBAN Høringen omhandler ikke XML-skemaerne, men kun de semantiske definitioner. Postadresse er netop den struktur, der samler adresselinjerne til en hel adresse

51 Pnummer: Det bør tilføjes, at Pnummer betyder: Produktionsenhed Det bør tilføjes, at produktionsenhed ofte refereres til som: PNR Kommunekode & Myndighedskode: Ordet entydig anvendes 2 gange i samme sætning? Kommunekode & Myndighedskode: En kommune er i sig selv en myndighed. Er der så behov for en kommune(- myndigheds-)kode? Hvad med alle andre myndighedstyper (roller?)?? Indarbejdes Indarbejdes Kommunekode er en specialisering af myndighedskode, og dermed semantisk relevant. Øvrige myndighedstyper er også relevante, men endnu ikke kerne-godkendte Odense Kommune Samme semantik for opbygning af unik identifikation: I forhold til det foreliggende forslag ses en forskellighed i hvorledes at semantik for elementer som indgår i opbygning af unik identifikation er tilgængelig som separat udtryk. - Ved fx Kommunalt Ejendomsnummer er hverken Kommune-kode og Ejendomsnummer tilgængelig som separat udtryk. - Hvorimod ved Bankkonto har man valgt at have både Filial-nummer og Bankkontonummer som separat udtryk. Det bør overvejes generelt at anvende samme opbygning og dermed have separate udtryk for alle elementer som indgår i opbygning af unik identifikation. I det konkrete tilfælde er både kommunekode og ejendomsnummer faktisk defineret, men den generelle pointe om at tilsigte mere ensartethed i detaljeringsgraden er registreret Ang. udtryk og feltet Nationalitet under Tema Person - Er der taget højde for at en person kan have flere statsborgerskaber? Definitionen udelukker ikke eksplicit multiple statsborgerskaber - men sådanne registreres efter oplysning fra CPR ikke i CPR OIO-Udvalget for Social og Omsorg Semantikdefinitionerne i der fremsendte skema, er i flere tilfælde forskellig fra den definition, der er i OIO-kataloget (ISB'en). Flere steder er OIO-katalogets mere præcis. Køn: Definitionen giver ikke mulighed for at rumme tilstanden "ikke angivet". Civilstand: Definitionen giver fx ikke mulighed for at rumme tilstanden enke. Udtrykket Fornavn: Fornavn identificerer ikke en person indenfor en slægt. I forbindelse med dataudveksling er semantikdefinitionerne meget vigtigt for at sikre korrekt forståelse af data. Det er specielt vigtigt på nye område, som social og omsorg, hvor der ikke har været større dataudveksling, som gennem år har skabt en fælles forståelse. Konsekvensen for social og omsorg at beholde definitionerne, som de er, vil være, at der må forventes, at ske en udfladning af dataforståelsen på de områder, der i øjeblikket er i gang med digitaliseringsprojekter. Det drejer sig konkret om "Stofmisbrugsdatabasen", "Digitalisering - udsatte børn og unge" og på sigt "Digitalisering af udsatte-handicap voksne". Det vil være direkte ødelæggende for IT understøttelsen og dermed grundlaget for projekterne. OIO-udvalget for social og omsorg vil opfordre til, at der sker en mere terminologisk faglig gennemgang af semantikdefinitionerne. Dette udsagn må underbygges med konkrete henvisninger, hvis det skal kunne anvendes specifikt Det er efter ITSTs opfattelse ikke en del af den semantiske definition at kunne undlade at specificere denne egenskab Indarbejdes Definitionen er ikke optimal, men der savnes et konkret forbedringsforslag Det står OIO-Udvalget for Social og Omsorg og alle andre frit for at specialisere semantiske definitioner i OIO-Kataloget, så ITST deler som udgangspunkt ikke udvalgets bekymring om forfladigelse. Hvis udvalget kan påvise konkrete tilfælde hvor de foreslåede definitioner har skadevirkninger, vil ITST sætte pris på at blive informeret om dette samt om udvalgets forslag til forbedringer af definitionerne. DANTERM Forskellen mellem Beskrivelse og Kommentar er ikke klar. Forslag til mere præcise definitioner modtages gerne Det anbefales, at der anvendes egentlige begrebsdefinitioner, da formålet formodentlig er at brugerne skal forstå det bagvedliggende begreb. I den supplerende kommentar kan der så gives yderligere information om informationstypen, fx formålet og udformningen. Det er hensigten at adskille definition fra forklarende information, og forbedringsforslag modtages gerne for de tilfælde, hvor dette ikke måtte være lykkedes Det anbefales endvidere, at definitionerne så vidt muligt udarbejdes i overensstemmelse med de metoder og regler, der er beskrevet fx i ISO 704:2000 og i Håndbog i begrebsarbejde, SST Fikspunktnummer: Nationalt entydig identifikation af et fikspunkt Der er cirkularitet inden for denne definition. Hvis man ikke ved hvad fikspunkt er, bliver man ikke mere oplyst af denne definition. Metermål: Definitionen er upræcis: hvad er det for en afstand der angives? Forslag: afstand fra et referencepunkt til en vejs startpunkt fratrukket antal hele kilomenter Kilometermål: Definitionen er upræcis: hvad er det for en afstand der angives? Forslag: afstand fra et referencepunkt til en vejs startpunkt fratrukket antal hele kilomenter Målemetode: Forslag: metode til at foretage en måling ITST takker for forslaget, som vil indgå i det videre arbejde med udfærdigelse af et regelsæt for udformning af semantikdefinitioner Definitionen vurderes ikke at være cirkulær, men derimod mangler en definition på det nærmeste overliggende begreb, nemlig "Fikspunkt" Indarbejdes Indarbejdes Indarbejdes

52 SKAT Administrativt vejnummer: Forslag: unik kode til administrativ identifikation af en vej Historisk Vejforgreningskode: Forslag: vejforgreningskode der har været i brug tidligere Forslag til supplerende forklaring: anførelse af hidtidig vejforgreningsbetegnelse som en huskehjælp til fagfolk. ForgreningsID: Definitionen er upræcis. Forslag: løbenummer for vejforgrening på en administrativ vej Forslag til supplerende forklaring: Vejforgreningsnumre starter med 001, som angiver den første forgrening på vejen. Vejforgreningskode: Forslag: kode for vejforgreningstypen Administrativ Vej Strækning: Definitionen er upræcis. Kategorinavnet bør være: Administrativ vejstrækning. Forslag: vejstrækning som er en del af en administrativ vej Administrativ vej: Forslag: vej der er administrativt entydigt identificeret Referencepunkt: Definitionen er upræcis: alle identificered punkter på en vej behøver ikke at være referencepunkter. Forslag: identificeret punkt på en vej der anvendes som reference Vejforgrening: Denne definition er meget bred. Den dækker mere end vejforgrening. Forslaget til definition er baseret på definitionen af vej i Færdselsloven. Forslag: punkt på en vej hvor en anden vej eller en del af en vej har sit start- eller slutpunkt Forslag til suppelerende forklaring: Eksempler på forgreninger er tilslutning af en sidevej, en tilkørselsrampe, en frakørselsrampe, en parkeringsplads. Indsigelser overfor en række af forslagene: Definitionerne bør fremstå ensartet med henblik på sprogbrug, målgruppe og forståelighed. For at skabe ensartede, brugervenlige definitioner bør man: a. undgå kringlede formuleringer b. undgå upræcise definitioner eller unødvendig grundighed c. undgå at definere et begreb ved at lade det indgå i definitionen. d. undgå at definere cirkulært eller for bredt eller snævert Diverse korrekturbemærkninger Indarbejdes Indarbejdes Indarbejdes Indarbejdes Indarbejdes Indarbejdes Indarbejdes Indarbejdes Da bemærkningerne er formuleret som påtale af oplevede problemer frem for som konkrete ændringsforslag, er det svært at imødegå. En del af bemærkningerne bliver imødegået af ændringsforslag fra andre høringsparter. Nogle af bemærkningerne vedrører OIOXML-metadatafilerne i ISB og er dermed ikke omfattet af den aktuelle høring. De af bemærkningerne, der vedrører semantikdefinitionerne indarbejdes. Kort- og Matrikelstyrelsen Forslag om etablering af en topontologi Forslag til ændring af OIOs modellerings-struktur Forslag til forklaringer af definitionerne vedrørende adressepunkt Forslag til samordning af definitioner relateret til stedangivelser Der arbejdes pt. i andet regi på at etablere en topontologi for ressourcerne på digitalisér.dk Dette forslag kræver væsentlig uddybning og går langt udover de her foreliggende konkrete semantikdefinitioner. ITST foreslår, at KMS tager forslaget op med OIO-sekretariatet Indarbejdes Standardisering og harmonisering af stedangivelser i adresser, ejendomsregistrering mv. er væsentligt, og bør adresseres i rette fora - såsom et OIO-udvalg for stedbestemte data.

53 BILAG 6 Cover Dagsordenspunkt 8, OIO- komitéen, 9. oktober 2008 Beslutning Godkendelse af FESD standard Ledelsesinformation fase 2 Sagsfremstilling Det fremsendte udkast til standard er version 2.0 af standarden FESD Ledelsesinformation. Det blev oprindelig besluttet at dele standardiseringen af ledelsesinformationsmodulet op i to dele. En Fase 1 og en Fase 2. Version 2.0 af standarden dækker den nævnte Fase 2, og afslutter dermed udarbejdelsen af ledelsesinformationsmodulet. Ændringerne fra version 1.0 til version 2.0 er primært en færdiggørelse af del C, som indeholder specifikation af datasæt og dimensionstabeller. Disse var medtaget i den første version, som et appendix til orientering, men på grund af udeståender i standardiseringen af den samlede FESD Datamodel, kunne disse ikke færdiggøres i version 1.0. Proces Standarden har været i høring i perioden 23. april til 23. maj i år. Efter høringsperioden er de relevante høringskommentarer blevet indarbejdet i standarden. Høringsmateriale samt høringssvar kan ses på Høringsportalen: september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Per de Place Bjørn Telefon Telefax E-post ppb@itst.dk Indhold Det er almindeligt, at virksomheder anvender data i systemer, som kan bidrage med oplysninger om forretningens tilstand, udvikling, barrierer etc. altså ledelsesinformation og anden information til styringsmæssige formål. ESDH-systemer understøtter offentlige institutioner og organisationers sags- og dokumentbehandling og udgør her et centralt og ofte forretningskritisk system. Data i ESDH-systemet vil således ofte være væsentlige elementer i en samlet ledelsesinformation, som bør udnyttes. Skal ledelsesinformation m.v. ikke blot anvendes internt i en institution eller organisation men også kunne anvendes til benchmarking eller anden sammenligning mellem institutioner er det nødvendigt at standardisere også dette område. Endvidere ses sammenhængen med andre systemer end ESDH-systemer som et vigtigt element i dannelse og anvendelse af ledelsesinformation, og at dette kan ske på et standardiseret grundlag vil forenkle og fremme anvendelsen af ledelsesinformation. Sigtet med den foreliggende standard er således at definere og rent teknisk muliggøre ledelsesinformation i forbindelse med FESD-standardiserede ESDH-systemer. Standarden fastlægger endvidere en del udtræk på hvilken baggrund ESDH-ledelsesinformation kan dannes.

54 Indstilling Der indstilles, at OIO Datastandardiseringskomitéen godkender den vedlagte standard for FESD Ledelsesinformation fase 2. Bilag - Forslag til standard: FESD Ledelsesinformation fase 2. Ministeriet for Videnskab, Teknologi og Udvikling 2

55 Forslag til standard IT- og Telestyrelsen København den 9. september 2008 FESD-standardisering Ledelsesinformation. Modul Version 2.0

56 Kolofon: FESD-standardisering. Ledelsesinformation. Modul Version 2.0 Denne standard kan frit anvendes af alle. Citeres 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, Traen Informationssystemer A/S og CSC Danmark A/S. Kontaktperson i FESD-standardisering: Projektleder Rita Lützhøft, mail-adresse rla@itst.dk Traen Informationssystemer A/S CSC Danmark A/S Vesterbrogade 95 A Retortvej København K 1780 København V Telefon: Telefon: Web-adresse: Web-adresse: Software Innovation A/S Ministeriet for Videnskab, Teknologi og Udvikling Nærum Hovedgade 10 IT- og Telestyrelsen DK-2850 Nærum Kontoret for Standardiserings- og arkitekturpolitik Telefon: Holsteinsgade 63 Web-adresse: DK-2100 København Ø Telf Fax itst@itst.dk 2 / 30

57 Indholdsfortegnelse 1 Forord DEL A Indledning Området ledelsesinformation Formålet med ledelsesinformation Målgrupper og typer af ledelsesinformation DEL B Beskrivelse og afgrænsning af opgaven Arkitektur Overvejelser ved indførelse af ledelsesinformationssystem DEL C Indledning Grundstørrelser for ledelsesinformation Typer af Ledelsesinformation Kontrollister og anden god skik for udarbejdelse af ledelsesinformation Udtræksfunktion krav til ESDH-løsningen Datasamlinger Definitioner, oprindelse, anvendelse...18 BILAG 1. NOARK s behandling af ledelsesinformation og oversigter...26 Bilag 2. Anvendte typer i FESD-modellerne...27 integer...27 boolean...27 Identifikationstyper...27 char...28 date, datetime og time...28 string...29 float / 30

58 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 sagsog 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 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-Komitéen til godkendelse. Efter godkendelse bliver standarderne offentliggjort og indgår i IT- og Telestyrelsens 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. 4 / 30

59 2 DEL A Dette er version 2.0 af standarden FESD Ledelsesinformation. Det blev oprindelig besluttet at dele standardiseringen af ledelsesinformationsmodulet op i to dele. En Fase 1 og en Fase 2. Version 2.0 af standarden dækker den nævnte Fase 2, og afslutter dermed udarbejdelsen af ledelsesinformationsmodulet. Ændringerne fra version 1.0 til version 2.0 er primært en færdiggørelse af del C, som indeholder specifikation af datasæt og dimensionstabeller. Disse var medtaget i den første version, som et appendix til orientering, men på grund af udeståender i standardiseringen af den samlede FESD Datamodel, kunne disse ikke færdiggøres i version Indledning Det er almindeligt, at virksomheder anvender data i systemer, som kan bidrage med oplysninger om forretningens tilstand, udvikling, barrierer etc. altså ledelsesinformation og anden information til styringsmæssige formål. ESDH-systemer understøtter offentlige institutioner og organisationers sags- og dokumentbehandling og udgør her et centralt og ofte forretningskritisk system. Data i ESDH-systemet vil således ofte være væsentlige elementer i en samlet ledelsesinformation, som bør udnyttes. Skal ledelsesinformation m.v. ikke blot anvendes internt i en institution eller organisation men også kunne anvendes til benchmarking eller anden sammenligning mellem institutioner er det nødvendigt at standardisere også dette område. Endvidere ses sammenhængen med andre systemer end ESDH-systemer som et vigtigt element i dannelse og anvendelse af ledelsesinformation, og at dette kan ske på et standardiseret grundlag vil forenkle og fremme anvendelsen af ledelsesinformation. FESD-standardiseringen har på denne baggrund også opgaven med at udforme et ledelsesinformationsmodul knyttet til ESDH. Sigtet med den foreliggende standard er således at definere og rent teknisk muliggøre ledelsesinformation i forbindelse med FESD-standardiserede ESDH-systemer. 2.2 Området ledelsesinformation Begrebet ledelsesinformation, eller LIS, bruges ofte lidt i flæng om ofte forskelligartet information, der trækkes ud af et system med henblik på at give ledere eller andre oversigtsinformation for at opnå overblik, kunne udføre analyser eller blot for at tilgængeliggøre enkle, styringsmæssige redskaber. Ledelsesinformation kan dermed være meget forskelligt, hvorfor det er anset for nødvendigt i denne sammenhæng at beskrive, hvad FESD-standardiseringen opfatter som ledelsesinformation, og hvilken sammenhæng ESDH-ledelsesinformation skal indgå i. I FESD-standardiseringen tages udgangspunkt i Finansministeriets Økonomisk Administrative Vejledning (ØAV) i forhold til overordnet at beskrive, hvad ledelsesinformation er. Vejledningen beskriver på en god og oversigtlig måde ledelsesinformation og klargør sammenhængen til andre typer af ledelsesinformation, som ESDH-ledelsesinformation skal fungere sammen med Formålet med ledelsesinformation Følgende er uddrag fra Finansministeriets Økonomisk Administrative Vejledning (ØAV) om Ledelsesinformation (se Der er foretaget enkelte rettelser til den oprindelige tekst. Disse rettelser er markeret med fodnoter. Den rutinemæssige ledelsesrapportering bør være fokuseret på få, centrale informationer, der belyser status på de forhold, som er kritiske for at opnå institutionens mål. Det kan være særlige poster i de interne regnskaber, økonomiske nøgletal, og ikke-finansielle tal. Der kan være behov for at belyse styrings 5 / 30

60 spørgsmål som f.eks. service- og kvalitetsniveau, kundetilfredshed, produktivitet, produktionsflow, brugerog medarbejdertilfredshed mm. Ledelsen bør også løbende holdes orienteret om den faktiske økonomiske udvikling i forhold til budgettet. Idéen med ledelsesinformation er at følge op på både ressourceforbrug og målopfyldelse og dermed på både produktivitet og effektivitet. Ledelsesinformationen koncentrerer sig således ikke kun om traditionel økonomibaseret information (regnskab), men udarbejdes efter kravet om information der kan give fingerpeg om forhold, som ledelsen skal interessere sig nærmere for. Dermed støttes ledelsens handlekraft, og ledelsesinformationen bidrager til et godt beslutningsgrundlag. Ledelsesinformation anvendes også til styrkelse af det interne beredskab: løbende målinger, advarselslamper i tilfælde af store afvigelser mv., ligesom der fokuseres på de handlinger og processer, som har skabt resultaterne. Ledelsesinformation behøver ikke at være begrænset til ledelsen, men kan være tilgængelig for alle medarbejdere i institutionen, f.eks. på Intranettet, ligesom ledelsesinformation kan danne grundlag for offentliggørelse af data om institutionens virke for derigennem at dokumentere målopfyldelse hhv. afstemme forventninger. 1 Ofte er ledelsesinformationen knyttet sammen med institutionens overordnede mission. Dette skal bl.a. ses på baggrund af, at de forskellige dele af institutionen vil bruge ledelsesinformationen på forskellige måder. For at få sammenhængende informationer og et ensartet grundlag til at tage beslutninger på, kan et sammenhængende hierarki af informationer være brugbart. Samtidig kan den enkelte medarbejder få mulighed for at se sig selv og sine arbejdsområder i institutionens overordnede informationshierarki. Der kan opstilles nogle typiske krav til ledelsesinformation: - Målingerne skal kobles til strategiske mål. Afdelinger og enheder skal vide på hvilken måde, de hver især bidrager til institutionens overordnede mål - Systemet skal integrere finansielle og ikke-finansielle informationer - Informationerne skal være tilgængelige på en måde, så de kan bruges af de udførende enheder. Både ledelse og medarbejdere har brug for beslutningsstøtte i form af den rigtige information på det rigtige tidspunkt Informationssystemets største værdi er dækkende målinger, der fokuserer på primærinteressenternes krav og forventninger. Ledelsesinformation kan dermed tjene flere formål: - Overblik og gennemsigtighed - Overvågning - Beslutningsstøtte - Helhedsorienteret information, som kan danne nye vinkler og et styrket grundlag at træffe beslutninger på. De fleste institutioner og virksomheder har allerede i en eller anden udstrækning specifikke målepunkter for deres forskellige resultatområder (økonomi, kunder, medarbejdere, processer, mv.). De enkelte målepunkter dokumenteres sædvanligvis i et eller flere operationelle edb-systemer. Den typiske struktur eller systemsammenhæng er således, at ledelsesinformationen generer data fra de systemer, der på forhånd findes i institutionen. Det vil typisk sige et økonomisystem, et lønsystem, et tidsregistreringssystem, et ESDH-system 2, et produktionssystem, hvilket grafisk kan skitseres således 3 : 1 Den ikke-kursiverede del af sætningen er tilføjet af FESD-standardiseringsgruppen 2 et EDSH-system er tilføjet til listen af FESD-standardiseringsgruppen 3 ESDH-system samt pile er tilføjet til tegningen af FESD-standardiseringsgruppen 6 / 30

61 Prod. system Løn system Tidsreg. system Ledelsesinformation Økonomi system ESDH system Figur 1 LIS, som er et sammenhængende informationssystem til ledelse og styring af organisationen, bygger hovedsageligt på de systemer og data, som allerede findes i institutionen. LIS kan dels opfattes som en delmængde af de mange forskellige informationer og data, som delsystemerne kan tilvejebringe, dels som noget mere, idet det er en videreudvikling af de data, som delsystemerne indeholder. Sammenkoblingen af de forskellige systemer giver muligheder for, at foretage sammenligninger og beregninger på data fra systemerne. Således bliver det muligt at få nye oplysninger af f.eks. enhedsomkostninger pr. sag mm. Endvidere kan andre registreringer af oplysninger fra kunde- og medarbejdertilfredshedsanalyser, benchmarking, markedsanalyser, kompetence- eller videnopgørelse el.lign. inddrages. Denne sammenkobling af systemer kan teknisk ske ved at opbygge et datawarehouse eller anden tilsvarende 4 teknologi. LIS vil således indeholde data fra forskellige kilder og stille disse data til rådighed på en institutionsspecifik måde. LIS samler alle de gennemførte målinger og stiller dem til rådighed for topledelsen, hvor tallene kan vendes og drejes og gøres til genstand for analyser dels på tværs af organisationen og dels på vilkårlige niveauer i organisationen. De decentrale dele af organisationen kan selv arbejde med delresultaterne af de målinger, som er foretaget på deres eget niveau og dermed selv kontrollere, om de lever op til de målsætninger og resultatkrav, som de vil have en interesse i selv at følge med i. Når denne vertikale drill-down-mulighed, hvor det er muligt at vælge lavere niveauer i informationshierarkiet, suppleres med en horisontal integration af målingerne på tværs af organisationen kan LIS besvare spørgsmål, som inddrager viden fra både økonomiske og ikke-økonomiske målinger på tværs af hele organisationen. Det forudsættes at institutionens datagrundlag sættes i system, hvor alle de løse ender bindes sammen i strukturerede, emne-orienterede grupper, der er klar til at analysere og træffe beslutninger på. LIS indeholder typisk nogle værktøjer, som gør det muligt at bearbejde disse data og registreringer, både i henhold til opbevaring, behandling og præsentation af informationerne. ESDH-information skal, som vist, betragtes som en selvstændigt enhed med mulighed for bidrag til institutionens samlede ledelsesinformation i form af informationer om sags- og dokumentbehandlingen i institutionen samt information, som muliggør sammenkobling med et eller flere andre systemer. 4 tilsvarende er tilføjet af FESD-standardiseringsgruppen 7 / 30

62 FESD-standardiseringen på ledelsesinformationsområdet tager især udgangspunkt i ovenstående betragtninger fra Finansministeriets vejledning (ØAV), hvilket betyder, at denne standardisering fastlægger selvstændig ESDH-ledelsesinformation og faciliterer samtidig, at denne information kan integreres med information fra andre systemer med henblik på tilrettelæggelse af et samlet ledelsesinformationssystem. Det bør nævnes, at sammenknytningen stiller store krav til registreringspraksis, fælles nøgleværdier, periodeopfattelse mv. i det hele taget til alt hvad der kan kaldes fælles sprog - og disse afklaringer henholdsvis tilrettelæggelse er en af de store opgaver i forbindelse med implementering af et ledelsesinformationssystem. Selvom standarden peger på at man bør overveje mulighederne for at sammenstille data fra forskellige systemer, beskæftiger standarden sig ikke med selve implementeringsdelen. Standarden udgør således alene en standardiseret tilgang til de data der umiddelbart og bredt dækkende kan hentes fra ESDH systemer. 2.4 Målgrupper og typer af ledelsesinformation Tages der udgangspunkt i Finansministeriets vejledning (ØAV), kan der ses, at der er flere målgrupper for ledelsesinformation. Disse målgrupper er både på det styringsmæssige niveau i en virksomhed og på det udførende niveau, hvor der i begge tilfælde kan være behov for overblik og opfølgning. Hvad angår sagsbehandling i det offentlige, er der ofte også andre grupper, der har en interesse for sagsgange etc. Det er de parter, sagsbehandlingen vedrører (fx borgere eller virksomheder), såvel som offentligheden i almindelighed. ESDH-ledelsesinformation er information udtrukket af ESDH-systemet på baggrund af data, som er opsamlet i systemet og har forskellige brugere. På baggrund af ØAV, på baggrund af NOARK s behandling af området ledelsesinformation (bilag 1) og på baggrund af FESD-standardiseringens viden kan identificeres følgende interne og eksterne målgrupper for ledelsesinformation og styringsmæssig information vedrørende sagsbehandling, der kan trækkes ud af ESDH-systemer: 1. Ledelse (gradueret efter topledelse, taktisk ledelse, politisk ledelse, m.fl.) 2. Medarbejdere 3. Andre interessenter (Offentligheden, særlige interesseorganisationer, andre institutioner) Ledelsesinformation er dermed en bred betegnelse for lister, statistik og styringsinformation fra ESDHsystemet, som i høj grad afhænger af hvilken målgruppe, der gælder for den pågældende information. Ovenfornævnte interne og eksterne målgrupper kan illustreres, som følger: 8 / 30

63 Ledelse? ESDH Medarbejdere Offentlighed Figur 2 Dette er en overordnet opdeling af målgrupper, som bør dække det generelle behov for ledelsesinformation. Grupperne kan inddeles yderligere, ligesom der formodentlig kan identificeres grupper, som, man ikke umiddelbart finder, er dækket. Eksempelvis kan ledelse opdeles i Taktisk Ledelse, Politisk ledelse osv., hver med sit behov for information. Det, der er afgørende i forhold til målgrupper, er, at man som noget af det første i forbindelse med tilrettelæggelse af sit ledelsesinformationssystem, foretager en afdækning af behovene for de målgrupper, der findes i eller udenfor institutionen. Denne afklaring vil være kravsættende for en betydelig del af det øvrige tilrettelæggelsesarbejde. Grundlaget for udarbejdelsen af denne standard har været, at resultatet skal være en standard, der er bredt og acceptabelt dækkende, frem for at udvide arbejdet med en eksakt og total afdækning af alle målgrupper. 9 / 30

64 3 DEL B 3.1 Beskrivelse og afgrænsning af opgaven Arkitektur I forbindelse med FESD-standardisering af moduler er primært benyttet følgende opfattelse af hvad, der standardiseres i forbindelse med et modul: - Grænseflade et sæt af standardiserede funktioner/services i tilknytning til ESDHsystemet, som kan benyttes fra andre systemer - Funktion Funktionelle krav, inkl. grænseflader for et afgrænset modul, der kan isoleres fra ESDH-systemet. I forhold til ESDH-ledelsesinformation er ovenstående opfattelse af hvad, der skal standardiseres i forbindelse med et modul, ikke fundet hensigtsmæssig, hvorfor denne ESDH-ledelsesinformation-modulstandardisering afviger på visse punkter i forhold til standardisering af andre moduler i FESDsammenhæng. Følgende vurderinger er gjort: 1. Ledelsesinformation er oftest behandlet information (aggregeret, afledt, etc.). 2. Der er typisk tale om sammenstillet information fx information om et udsnit af sager hhv. dokumenter. 3. Ledelsesinformation skal ofte sammenstilles med tilsvarende information fra andre systemer for at give et meningsfuldt billede. 4. ESDH-systemerne er generelt mindre gode til at præsentere/behandle ledelsesinformation, sammenholdt med at der er et antal IT-leverandører, som har netop dette løsningsområde som sit primære forretningsfelt. 5. Selvom grundlaget for ledelsesinformationen er det samme (FESD-datamodel), vil der ikke i nødvendigt omfang enkelt kunne stilles krav til værdimæssige udfaldsrum og principper. 6. Der eksisterer anerkendte principper og metoder for opbygning af ledelsesinformationssystemer (management reporting / datawarehouse ) På denne baggrund er det besluttet jf. også Finansministeriets vejledning (ØAV), der kobler information fra forskellige systemer, - at standarden skal baseres på en datasamling, som dannes og frigøres fra ESDHsystemet. Arkitekturen kan illustreres på følgende måde: 10 / 30

65 FESD ESDH Eksport ESDH-LIS Ledelsesinformationsværktøjer kan være alt fra relativ simple regnearksmodeller til avancerede ledelsesinformationssystemer, hvor ESDH data kobles til andre typer ledelsesinformation i en datawarehouse løsning. Afhænger helt af behov og formåen, mv. LIS INFO (ESDH) Ledelses- Informations- Værktøjer (FESD / 3. part) LIS LIS LIS LIS (ANDRE) (ANDRE) (ANDRE) INFO (ANDRE) Figur 3 Som det fremgår, kan den standardiserede ESDH-ledelsesinformation bringes i anvendelse i forskellige ikke-esdh- (og ESDH-) systemer, afhængig af systemernes muligheder for præsentation og behandling af disse informationer samt naturligvis organisationens krav, ønsker, muligheder. Videre kan informationen anvendes i sammenhæng med information fra andre kilder (eksterne data i forhold til ESDH-data) og dermed udvide perspektivet for ledelsesinformation. Dette er et meget væsentligt element i forbindelse med standardiseringen. Generelt er området ledelsesinformation præget af stærk individualisering. Argumentet for dette er bl.a., at der er forskellige fokusområder og dermed forskellige krav til hvilken information, der ønskes. Men der synes at være en række områder, som kan behandles efter ensartede principper, og som dermed giver mulighed for dels at betragte disse områder på tværs i den offentlige sektor, dels virke motiverende for andre domæner end ESDH, i forhold til at følge samme princip om at stille data til rådighed for behandling udenfor det specifikke domænes system. Over tid kunne man forestille sig, at man vil se de forskellige domæne-ejere tilslutte sig denne arkitektur, med en standardiseret datasamling, som forholder sig til de eksisterende datasamlinger og dermed giver mulighed for, at såvel institutionerne som de forskellige leverandører kan udvikle værktøjer/løsninger til understøttelse af opbygningen af ledelsesinformationssystemer: 11 / 30

66 Økonomi ESDH Prod.X Økonomi ESDH Prod. X Løn Løn Ledelses- Informations system Prod. Y Prod. Y Tidreg. Projektstyring Prod. Z Tidreg. Projektstyring Prod. Z Figur 4 En væsentlig forudsætning for at kunne implementere ledelsesinformationssystemer med data fra flere forskellige systemer er, at der skabes sammenhæng mellem disse. Det vil sige, at der i de forskellige systemer registreres nøgleværdier, som knytter forekomster i systemet til forekomster i andre systemer. Sammenhængen kan også skabes eller afledes i ledelsesinformationssystemet, såfremt der her etableres regler/information om nøgleværdier, der kan danne grundlag for sammenhængen. Eksempelvis kunne man forestille sig, at man benyttede sagsnummer fra ESDH-systemet i forbindelse med sin tidsregistrering i et tidsregistreringssystem. Dette ville give mulighed for at etablere et ledelsesinformationssystem, hvor man ikke kun kan se behandlingstiden for sager, men også hvem og i hvilket omfang der udfører arbejdet med sagerne. Et andet eksempel kunne være, at man i forbindelse med implementering af et ledelsesinformationssystem fastlagde sammenhængen mellem økonomisystemets kontoplan og ESDH-systemets journalplan. Sammenhængen vil således kun eksistere i ledelsesinformationssystemet, men vil kunne give værdifuld information om fx sagsmængder/behandlingstid i forhold til budget/omkostninger. Finansministeriets vejledning (ØAV) nævner datawarehouse som en central metode for generering af ledelsesinformation. Generelt er det ved etablering af datawarehouses praksis, at der foretages indsamling af data fra forskellige kilder gennem såkaldte ETL-processer (Export, Transform and Load). ETL-processerne kan beskrives som de synkroniseringsmekanismer, der sikrer, at den tilgængelige ledelsesinformation er opdateret. Den typiske proces kan ses af følgende illustration: 12 / 30

67 Staging DW-House ETL Figur 5 En eller flere ETL-processer henter data fra forskellige kilder, og via et såkaldt staging area transformeres/renses data for endelig at blive indlæst i den database, som indeholder selve det etablerede datawarehouse, der danner grundlag for institutionens ledelsesinformationssystem. FESD-standarden er principielt at betragte som et element i et staging area. Der eksisterer et antal leverandører, som alene arbejder med tilrettelæggelse af datawarehouse-løsninger, udvikling af værktøjer til understøttelse af ETL-processerne osv. Dette løsningsområde har der traditionelt været mindre fokus på fra ESDH-leverandørernes side, og dette, sammenholdt med ønsket om at se ESDH-informationen i sammenhæng med andre domæners data, har dannet baggrund for den her foreslåede arkitektur. Indenfor ledelsesinformation, eller Management reporting, eksisterer der ingen de jure standarder, som man kan basere sig på, men der er en række principper, som er tilpas udbredt til at kunne anvendes som principielt grundlag for standardiseringen. Ved etablering af et datawarehouse specificeres såkaldte datamarts. Den grundlæggende struktur for datamarts kan illustreres på følgende måde: Sagsstatistik Dimensionstabeller Org KL Øko Faktatabel Figur 6 Et datamart indeholder en faktatabel og et antal dimensionstabeller, som tilsammen danner grundlag for at kunne producere statistikker, oversigter, kunne søge og afgrænse osv. Teknisk set er det en afgrænset og sammenhængende datasamling eller datamodel. Flere datamarts kan kombineres og/eller samles i et datawarehouse. Der eksisterer omfattende litteratur om dette, og standarden vil ikke her gå nærmere ind i teorien. For en kortfattet introduktion, kan følgende artikel læses: 13 / 30

68 Det vigtige i forhold til udarbejdelse af standarden for ESDH-ledelsesinformation er, at man gennem disse gældende principper er i stand til at beskrive et antal datasamlinger, inkl. udfaldsrum, principper for fx måling af tider, felter/formater etc. på en form, som umiddelbart vil kunne anvendes i en lang række sammenhænge. Samtidig giver netop denne form grundlag for videreudvikling af standarden i forhold til omfanget (antal datasamlinger fra ESDH) og i forhold til at motivere andre domæner til at specificere datasamlinger, som kan benyttes i sammenhæng med standarden. Ligeledes vil man i forbindelse med en aktuel implementering af et ledelsesinformationssystem kunne benytte de i denne standard specificerede datamarts i sammenhæng med andre (eksisterende eller nye) datamarts fra andre systemer på en veldefineret måde. FESD-standardiseringen vil således specificere de data fra ESDH-systemer, der kan indgå i datamarts. FESD-standardiseringen forsøger ikke en standardisering af al relevant ledelsesinformation knyttet til ESDH. FESD-standardiseringen vil alene standardisere de mest centrale udtræk og statistikker til forskellige målgrupper, bl.a. fordi det forventes, at behovet for konkret ESDH-ledelsesinformation med tiden vil øge i omfang og på i dag ukendte områder Overvejelser ved indførelse af ledelsesinformationssystem Som det fremgår af ovenstående afsnit, har det været vigtigt at finde en form, som kan tilgodese de brede behov i den offentlige sektor frem for at dække alle aspekter i den enkelte sektor, koncern eller institution, samtidig med at den valgte form er fleksibel og dermed giver mulighed for udvidelse/justering. Det er forventningen, at man ved tilrettelæggelse af ledelsesinformation skal foretage justering, præcisering eller udvidelse af den i standarden indeholdte datasamling. Eksempelvis kunne man forestiller sig, at man i den kommunale sektor har et ønske om, at sagsstatus benyttes med bestemte værdier, eller at KL-Journalplan afspejles på en bestemt måde. Tilsvarende kunne man forestille sig, at et ministerium ønsker at ensrette rapporteringen fra de forskellige styrelser og således diktere udfaldsrum og andre principper for ledelsesinformationssystemerne. Endelig er en række af de elementer, der indgår i de beskrevne datasamlinger, genstand for vurdering i forhold til den anvendte sagsbehandlings- og registreringspraksis i det aktuelle ESDH-system. Her tænkes fx på, hvordan sagsafslutning foretages (hvilke principper gælder, og hvordan skal man således anvende den information i ledelsesinformationssystemet), beregning af sagsbehandlingstider (hvilke principper ligger bag dannelsen af ledelsesinformationen) osv. Det ville have været hensigtsmæssigt om denne standard havde fastlagt alle udestående variable, men forudsætningen herfor er at der eksistere en fælles afklaret holdning til dette i den offentlige sektor, og det synes ikke at være tilfældet. Det skal derfor pointeres, at der for den enkelte organisation forestår en større opgave i at implementere et ledelsesinformationssystem og derigennem foretage de nødvendige afklaringer, fastlæggelse af principper, mv. Denne opgave løser standarden som nævnt ikke standarden tilvejebringer alene et struktureret grundlag for etablering af en ESDH dimension i et ledelsesinformationssystem. Dette skal der være mulighed for. Det er konstateret, at der er forskellige behov for ledelsesinformation i de forskellige institutioner, idet behovet naturligt hænger sammen med de visioner / mål, der er i den pågældende institution. Og det må være det vigtigste, at netop dette understøttes. Derfor kan der tillades en vis varians i anvendelsen af standarden i forbindelse med en konkret implementering af et ledelsesinformationssystem fx i forbindelse med udvidelse af den samlede ledelsesinformation med data fra andre systemer. Generelt i forbindelse med implementering er det vigtigt at kriterier, principper, mv. dokumenteres, så ingen er i tvivl om, hvordan ledelsesinformationen er tilvejebragt, og dermed hvordan den kan/bør anvendes. I forhold til benchmarking på tværs i den offentlige sektor (uden forudgående aftaler) vil man først kunne foretage dette, efter endt standardisering af den samlede FESD-datamodel samt afstemning af en række temaer i den offentlige forvaltning generelt. Det er vores vurdering, at den understøttelse, som standarden giver den enkelte institution eller koncern/sektor, på baggrund af en overskuelig afstemning er vigtigere end en samlet ensretning på tværs i den offentlige sektor på nuværende tidspunkt. 14 / 30

69 4 DEL C 4.1 Indledning Ledelsesinformationen indeholdt i denne standard skal bl.a. baseres på de dele af FESD-datamodellen, som tidligere er standardiseret med udgangspunkt i SAG og DOKUMENT. Udover data-elementer, der er hentet direkte fra datamodellen, vil der være dels data-elementer, som er beregnet eller afledt, dels dataelementer, der fremtidigt standardiseres. Der skal så vidt muligt forsøges at præcisere indhold og udfaldsrum, men det anbefales, at man i forbindelse med etablering af ledelsesinformationssystemer også foretager en gennemgang og præciserer indhold og betydning i forhold til den/de aktuelle institutioner. De ledelsesinformations-elementer, der nævnes i afsnit 3 Typer af ledelsesinformation nedenfor er friholdt fra informationer, som kunne indeholde følsomme oplysninger, eller oplysninger som vil betyde, at informationerne skulle behandles ud fra de rettighedsprincipper, der gælder for den aktuelle ESDHanvendelse. Dette har den konsekvens, at informationerne ikke kan benyttes til analyser/rapportering, hvor det enkelte objekt præsenteres (SAG/DOKUMENT). Såfremt man ønsker at tilrettelægge ledelsesinformationssystemer, hvor dette skal være muligt, kan man under iagttagelse af den deraf følgende rettighedsproblematik udvide den samlede model for hhv. SAG og DOKUMENT med en dimensionstabel, der indeholder de relevante oplysninger. Eksempelvis kunne denne dimensionstabel for SAG indeholde sagstitel, udvalgt partsinformation, mv. Som udgangspunkt kan det ikke anbefales at medtage denne type information. Der skal fremhæves, at der i det følgende kun beskrives ledelsesinformation etc. Hvorledes informationen præsenteres på lister, i diagrammer, kurver etc. af hensyn til formidlingen berøres ikke. 4.2 Grundstørrelser for ledelsesinformation I det følgende er angivet definitionen på en række dataelementer, der er en central del af grundlaget for ESDH-ledelsesinformation. Sagsbehandlingstid 5 (bruttosagsbehandlingstid): Den tid der går, fra sagen opstår (borgeren/virksomheden henvender sig, eller sagen optages på eget initiaitv), til sagen afsluttes (afgøres, lukkes etc. det vil sige sidste trin inden en arkivering jf. Hvidbog om fælles kommunalt administrationssprog FKAS ) Nettosagsbehandlingstid 6 : Sagsbehandlingstid (bruttosagsbehandlingstid) minus de dage, hvor sagen behandles andetsteds (fx hos parten, er i høring, behandles af anden myndighed o.l.). Nettosagsbehandlingstid er således det antal kalenderdage, som institutionen bruger til behandling af en sag internt i institutionen. Gennemsnitlig sagsbehandlingstid (nettosagsbehandlingstid): Adderet sagsbehandlingstid (nettosagsbehandlingstid) for et antal sager divideret med antallet af sager. Beregnet for det konkrete udtræk. Knyttes typisk men ikke nødvendigvis til bestemte sagstyper. Kan beregnes for en fastlagt periode. Normtid (nettonormtid) for sager: Den ønskede sagsbehandlingstid (nettosagsbehandlingstid) eller frist - for en bestemt sagstype eller kategori af sager. Normtid (nettonormtid) kan fastlægges arbitrært eller efter fastlagte beregningsmetoder af institutionen. 5 Definition baseret på: Sagsbehandlingstider i staten, Finansministeriet, Oktober Definition baseret på: Sagsbehandlingstider i staten, Finansministeriet, Oktober / 30

70 Normtid for brevbesvarelsestid: Den ønskede tid svar på brevet er afsendt. eller frist fra et brev er modtaget i institutionen, til Åben sag. En sag der er oprettet, men endnu ikke afsluttet, dvs. endnu ikke arkiveret 4.3 Typer af Ledelsesinformation ESDH-ledelsesinformation rettes mod forskellige målgrupper jf. tidligere afsnit. I forbindelse med udarbejdelsen af standarden er en række institutioner blevet spurgt, om hvilke spørgsmål de forventer besvaret af ledelsesinformation. Nedenstående tabel viser en del af disse spørgsmål, som vil kunne besvares ved anvendelse af de standardiserede datasamlinger. Oversigten er ikke komplet der er langt flere spørgsmål, der kan besvares på baggrund af de specificerede datasamlinger, der standardiseres i FESD Ledelsesinformation. Fase 2. Hvad angår det anvendte begrebsapparet, som ikke er defineret i denne standard (fx begrebet sagstype) henvises til Hvidbog om fælles kommunalt administrationssprog FKAS Nr. Definition Primær målgruppe 1 Antal igangværende sager for en specifik organisationsenhed. Ledelse 2 Antal sager for en specifik organisationsenhed, hvor ansvarlig sagsbehandler ikke er påført. 3 Enhedens opdeling af sager på sagstyper (fx hovedsagstyper: klagesager, tilsynssager etc.). Ledelse Ledelse 4 Enhedens gennemsnitlige sagsbehandlingstid for sager (brutto/netto). Ledelse, medarbejdere, 5 Fordeling af sagsbehandlingstider på antal af sager i enheden. Ledelse, medarbejdere, offentlighed 6 Antal sager fordelt på sagsstatus (trin eller fase for sagen), evt. opdelt pr. organisationsenhed. Ledelse, medarbejdere, offentlighed 7 Antal indkomne dokumenter til institutionen fordelt på tidsperiode. Ledelse, medarbejdere, offentlighed 8 Alle sager fordelt på enheder i organisationen. Ledelse, medarbejdere 9 Alle åbne sager fordelt på enheder i organisationen. Ledelse, medarbejdere 10 Institutionens gennemsnitlige sagsbehandlingstid for sager. Samlet og fordelt på sagstype. 11 Fordeling af sagsbehandlingtider på antal af sager. Ledelse Ledelse, medarbejdere, offentlighed 12 Antal sager med behandlingstid afvigende i forhold til normtid. Ledelse 16 / 30

71 4.4 Kontrollister og anden god skik for udarbejdelse af ledelsesinformation Af hensyn til kvaliteten af den ledelsesinformation, der hentes ud af ESDH-systemer, er det nødvendigt at gøre sig klart, at denne kvalitet svarer til kvaliteten af ind-data eller den registreringsprakis, der benyttes ved journalisering af sager, dokumenter mv. I forbindelse med implementering af et ledelsesinformationssystem bør man derfor ikke undervurdere den opgave, der ligger i at gennemgå og kvalitetssikre de informationer, der er registreret/registreres i ESDHsystemet, og evt. gennemføre saneringer og ændring af eksisterende anvendelsesvejledninger. Hvis registreringsoplysninger, der lægges ind i ESDH-systemer, er fejlagtige, vil også ledelsesinformation baseret på disse fejlregistreringer blive fejlagtig. Organisationer som har implementeret ledelsesinformationssystemer, på basis af informationer fra idriftsatte ESDH-systemer, har typisk oplevet en længere indkøringsperiode, hvor organisationen reagerer på den viste ledelsesinformation med påstand om, at den er fejlagtig. Typisk viser det sig at være fejlagtig eller mangelfuld registrering i ESDH-systemet, hvorfor kvaliteten af registreringen og dermed af ledelsesinformationen over tid øges. At ledelsesinformationen kan give anledning til at man konstaterer at registreringspraksis ikke følges, er naturligvis positivt, men der er en risiko for at brugere af ledelsesinformationen ikke stiller kritiske spørgsmål til denne, og dermed risikerer at anvende fejlagtige informationer som grundlag for beslutninger. Derfor tilsiger god skik i forbindelse med ledelsesinformation, at der udføres jævnlige kontroller af de felter i databasen, der benyttes til ledelsesinformationsudtræk, beregninger og statistik. 4.5 Udtræksfunktion krav til ESDH-løsningen For at kunne realisere ovenstående må der som en del af ESDH-løsningen være en funktion, der kan danne de beskrevne datasamlinger. Følgende er de overordnede krav, der er til denne funktion. Udtræksfunktionen skal tilrettelægges, så det er muligt at eksekvere den i bestemte intervaller uden brugerinteraktion. Nødvendige parametre skal kunne angives i en parameterfil eller tilsvarende, altså uden brugerinteraktion på kørselstidspunktet. Det gælder fx placering af filer og filformat. FORMATER Udtræksfunktionen skal kunne generere de beskrevne datasamlinger i formatet XML efter et af FESDstandardiseringsgruppen defineret XML-schema. Leverandøren kan vælge at implementere yderligere formater. FILNAVNE OG PLACERING De beskrevne tabeller skal eksporteres, én fil pr. tabel. Følgende filnavne skal benyttes: [TabelNavn]-[AAAAMMDD]-[TTMM].XML Dato og tid angiver det tidspunkt, hvor udtrækket foretages. Det forudsættes, at der ikke foretages udtræk af samme tabel indenfor samme minut på en given dato. Eksempel på filnavn for faktatabellen SAG: LISCase XML Placering af udtrækket skal kunne angives som en fast værdi, fx i en tilhørende parameterfil. SELEKTIONSKRITERIET Udtræksfunktionen skal som udgangspunkt fortage udtræk af alle forekomster i tabellerne SAG og JOURNALPOST (Ref. FESD-datamodel) samt tilhørende værdier i dimensionstabellerne. 17 / 30

72 Evt. styring af versioner af udtræk, forskelle mellem to givne tidspunkter mv. påhviler det ledelsesinformationssystem, der benytter udtrækkene. Udtræksfrekvens og anvendelse i ledelsesinformationssystemet fastlægges i forbindelse med implementering af ledelsesinformationssystemet. 4.6 Datasamlinger Definitioner, oprindelse, anvendelse Som tidligere beskrevet, er den standardiserede ledelsesinformation en samling data, der dannes ved et udtræk fra ESDH-databasen. Udtrækket kan herefter anvendes som grundlag for opbygningen af ledelsesinformationssystemer. En række af informationerne i datasamlingerne er ikke direkte henførbare til den standardiserede FESDdatamodel af flere årsager: a) En del felter kan kun beregnes på udtrækstidspunktet tider og mængde. b) Nogle felter er medtaget for at forenkle den senere anvendelse f.eks. at gøre rapporter enklere at udarbejde, give mulighed for anvendelse af mere simple ledelsesinformationssystemer (f.eks. regneark). c) Nogle felter er vurderet afgørende for at give ledelsesinformationen mening, selvom standardiseringsarbejdet på dette område endnu ikke er tilendebragt. d) Og endelig er der medtaget felter, som alene eksisterer i datasamlingerne. Særligt i forhold til benchmarking er det hensigtsmæssigt, hvis alle felter kunne henføres direkte til FESDdatamodellen. Gængs praksis ved implementering af ledelsesinformationssystemer/datawarehouse er, at de udtræk, der foretages, transformeres i nødvendig grad for at passe bedst muligt til det ledelsesinformationssystem, der implementeres. Principielt kan man forestille sig, at der skete yderligere transformationer/tilføjelser i forbindelse med f.eks. import af de beskrevne datasamlinger i et datawarehouse. Det er her vigtigt at gentage behovet for kontrol/kvalitetssikring. Når der i forbindelse med udtrækket foretages transformation af de informationer, der ligger til grund for udtrækket, er det vigtigt, at dette dokumenteres og at der tilvejebringes kontrolmekanismer, så man periodisk kan foretage kontrol af den ledelsesinformation, der præsenteres for de forskellige målgrupper, og som dermed danner grundlag for vurderinger/beslutninger, mv. For felterne i nedenstående beskrivelse er oprindelse angivet. Her kan man se, om det enkelte felt er direkte henførbart til FESD-datamodellen, om det er afledt information, beregnet information eller alene er dannet i udtrækket til anvendelse i ledelsesinformationen. Der er anvendt følgende notation: FESD:<feltnavn> [AFLEDT] [BEREGNET] Angiver at feltet er direkte henførbart til FESD-datamodellen Angiver at feltet afledes af et eller flere logisk sammenhængende felter i FESD-datamodellen. Det kan også betyde, at feltet meningsmæssigt er til stede i FESD-løsningerne, men endnu ikke er standardiseret i FESDdatamodellen og at afledning dermed forventes mulig. Angiver at værdien er beregnet på udtrækstidspunktet. 18 / 30

73 [SPECIFIK] Angiver at feltet alene er medtaget i udtrækket og at der ikke nødvendigvis er mulighed for at udtrække/aflede informationen fra den aktuelle database. 2 Faktatabel SAG (LISCase) Faktatabellen sag indeholder nøgleoplysninger om sagen. Primær kilde i FESD-datamodellen er tabellen SAG. LIS Feltnavn Oprindelse Beskrivelse Type Kar dinalitet LISCaseIdentifier FESD: casefileidentifier Unik nummerering af samtlige UUID 1 sager for at sikre teknisk entydighed. Anvendes som teknisk reference for sag, hvilket muliggør refrentiel integritet. LISCaseYear FESD:caseFileYear Årstal for sagens oprettelse. Year 1 Anvendes til at angive sagens oprettelsesår, og indgår i nogle tilfælde som en del af journalnummeret. CCYY. Gyldige årstal 0 - N hvor N ikke kan overstige dette År. LISCaseTypeCode FESD:caseFileTypeCode Sagstype. Ref, til dimensionstabellen Code 1 LISCaseType- Table. LISCaseCategoryLev1 FESD:TermIdentificator Saggruppe for sagen. For at understøtte forskellig registreringspraksis i de forskellige sektorer, er der defineret op til 9 saggrupper, som kan benyttes til at angive sagens emnemæssige indplacering. Ved fastlæggelse af institutionens ledelsesinformationssystem, må det besluttes hvorledes disse felter skal Char(34) 1..* benyttes som primær, sekundær, osv., som sidestillede emner, som primær, sekundær, samt funktionsfacet, mv. Ref, til dimensionstabellen LISCaseCategoryTable. LISCaseCreationDate LISCaseClosed FESD:caseFileCreationDat e FESD:caseFileStatusClose dindicator Oprettelsdato for sagen. Bør tildeles automatisk. Anvendes som bl.a. afgrænsiningsparameter ved søgninger. Sagsoprettelsdato CCYYDDMM, Jf. ISO Markering for at sagen er afsluttet. 1=afsluttet, 0=ikke afsluttet Date 1 Boolean 1 19 / 30

74 LISCaseClosedDate [AFLEDT] Dato for afslutning af sagen. Skal være udfyldt såfremt LISCaseClosed er sat til værdien 1. Sammen med LISCaseCreationDate kan bruttosagsbehandlingstiden beregnes LISCaseUpdatedDate LISCaseDisposalDate LISCaseRetentionTime LISCaseStatusTermination FESD:caseFileLatestUpdat edate FESD:caseFileDisposalDat e FESD:caseFileRetentionTi meyear FESD:caseFileStatusRegis trationnullificationindicator Dato for seneste opdatering i sagen. Udfyldes hvis sagen er opdateret. 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. Angiver om sagen er omjournaliseret eller af anden grund udgår. Feltet anvendes hvis en sag er oprettet ved en fejl og sagsregistreringen udgår. Sagsmarkeringen slettes ikke, men feltet her markerer at der er tale om en fejlregistrereing. 1=Udgår LISCaseStatusCode FESD:caseFileStatusCode Status for sagen. Ref, til dimensionstabellen LISCaseStatusCodeTable. LISCaseException [AFLEDT] Angivelse af at sagen er undtaget offentlighed. 1=Undtaget, 0=ikke undtaget Date 1 Date 1 Date 1 Antal år sagen skal bevares. Anvendes typisk i forbindelse med Kassationsbestemmelser fra Statens Arkiver og/eller sletningsfrister jf. Registerforeskriften fra Datatilsynet. Integer(2) 1 Boolean 1 Code 1 Boolean 1 LISCaseExceptionRule LISCaseResponsibleCode FESD:caseFileNotPublicLe gislationtext FESD:caseFileManagerReference 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. Identifikator på den sagsbehandler der er registreret som ansvarlig på sagen. Name 1 UUID 1 20 / 30

75 LISCaseOrgRefCode FESD:OrgUnitnameShortn amecode Organisatorisk tilknytning (afdeling, kontor, sektion, mv.). Ved flere forekomster, betragtes første forekomst som den primære organisationsenhed, som sagen er direkte knyttet til. LISCaseEstimatedWork [SPECIFIK] Evt. fastsat normtid i dage, for behandling af sagen. Bestemmes typisk ved sagens oprettelse, af den anførte sagstype, men kan også angives eksplicit for den enkelte sag. Hvis SagNormtid=0, er der ikke fastsat normtid for sagen. Kan opgøres per sagstype LISCaseActualTime [BEREGNET] Bruttobehandlingstid i dage for sagen. Bruttosagsbehandlingstid forståes som antallet af kalenderdage fra sagens oprettelse til sagens afslutning. For åbne sager, er angivelsen antal dage fra sagens oprettelse, til dato. LISCaseActualWork [SPECIFIK] Nettobehandlingstid i dage for sagen. Nettosagsbehandlingstid forståes som det antal kalenderdage, institutionen bruger til behandling af en sag internt i institutionen og dermed undtaget de dage hvor sagen behandles udenfor institutionen (Er i høring, behandles af anden institution, i afventen af svar fra part i sagen, etc.) LISCaseNoDocuments [BEREGNET] Antal journalposter i sagen. Antal dokumenter i sagen kan anvendes til at opstille beholdningsoversigter, samt i nogle tilfælde at indikere kompleksiteten i sagerne. LISCaseNoDocumentsIn [BEREGNET] Antal Indgående dokumenter i sagen LISCaseNoDocumentsOut [BEREGNET] Antal Udgående dokumenter i sagen LISCaseNoDocumentsMemo [BEREGNET] Antal Notater i sagen alle dokumenter i sagen som ikke er betegnet som hhv. indgående eller udgående, falder i denne kategori. Code 1..* Integer(3) Integer(3) Integer(3) Integer(10) Integer(10) Integer(10) Integer(10) LISCaseGroupTerm [SPECIFIK] Muligt samlebegreb, som kan anvendes i tilfælde hvor der benyttes et projektbegreb, et samlesagsbegreb eller tilsvarende til at identificere en samling af sager. Name 1 21 / 30

76 4.3 Dimensionstabeller knyttet til datasamlingen SAG LISCaseOrgRefTable Felt navn Beskrivelse Felt type LISCaseOrgRefCode Organisatorisk tilknytning (afdeling, Code kontor, sektion, mv.). FESD:OrgUnitNameShortnameCod e LISCaseOrgRefDescription Beskrivelse af organisationsenhed FESD:OrgUnitName Text LISCaseResponsibleTable Felt navn Beskrivelse Felt type LISCaseResponsibleCode Identifikator på den sagsbehandler UUID der er registreret som ansvarlig på sagen. FESD:UserIdentificator LISCaseResponsibleName Beskrivelse af organisationsenhed FESD:UserName Text LISCaseCategoryTable Felt navn Beskrivelse Type LISCaseCategoryName Unik identifikation af saggruppe. Name LISCaseCategoryDescription- Text Beskrivelse af Saggruppe. Text LISCaseStatusTable Felt navn Beskrivelse Felt type LISCaseFileStatusCode Forkortelse af SagsStatusBetegenelse code unik identifikation af sagsstatusen. LISCaseFileStatusName Sagsstatus betegnelse i klar tekst. Name LISCaseTypeTable Felt navn Beskrivelse Felt type LISCaseFileTypeCode Forkortelse af SagsTypeBetegnelse. Code Anvendes som unik iden tifikation af sagstypen. LISCaseFileTypeName Sagstypebetegnelsen i klar tekst. Name 22 / 30

77 4 Faktatabel DOKUMENT (LISDocRecord) Faktatabellen DOKUMENT indeholder nøgleoplysninger om sagsarkivets dokumenter (journalposter). Primær kilde i FESD-datamodellen er tabellen JOURNALPOST. LIS Feltnavn Oprindelse Beskrivelse Felt type Kardinalitet LISDocRecordIdentificator FESD:recordIdentifier Unik nummerering af samtlige Journalposten, for at sikre teknisk entydighed. Anvendes som teknisk reference for Journalposten. UUID 1 LISDocRecordYear FESD:recordCreation YearIdentifier Årstal for journalpostens oprettelse. Year 1 LISDocRecordCase- FileIdentifier LISDocRecordSeqNo FESD:recordCaseFileI dentifier FESD:recordSequenc enumber LISDocRecordTypeCode FESD:recordTypeCod e Sagsreference til sag, journalposten er knyttet til. Kan benyttes til sammenknytning af de to standardiserede datasamlinger. Dokumentnummeret indenfor sagen. Anvendes til at definerer dokumentets rækkefølge i sagen. Entydigt maskingenereret løbenummer knyttet til dokument i sagen. Dokumenttype. Ref. til dimensionstabellen LISDocRecordType- Table. UUID 1 Integer(4) 1 Code 1 LISDocRecordCategory [AFLEDT] Dokumentkategori Indgående, Udgående, Notat. Er supertype i forhold til dokumenttype. Værdier I, U, N Char(1) 1 LISDocRecordResponstime [BEREGNET] Gælder Indgående dokumenter. Antal dage regnet fra dokumentdato, til dato for afskrivning. Integer(3) 1 LISDocRecordHandlingtime [BEREGNET] Gælder Indgående dokumenter. Antal dage regnet fra dokumentdato, til dato for ekspedition. LISDocRecordWorktime [BEREGNET] Gælder Indgående dokumenter. Antal dage regnet fra registreringsdato, til dato for afskrivning. Integer(5) LISDocRecordCreation- Date FESD:recordRegistrati ondate 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 dokumen- Integer(5) 1 1 Date 1 23 / 30

78 ter. LISDocRecordLetterDate FESD:recordDocumen tdate Dato der er påstemplet eller på anden måde registreret på dokumentet. Date 1 LISDocRecordDeprDate FESD:recordDepricati ondate 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. Date 1 LISDocRecordHandling- Date FESD:recordRespons edate Dato for hvornår dokumentet er ekspederet. Date 1 LISDocRecordHandling- Deadline FESD:recordDueDate Dato for hvornår dokumentet senest skal være ekspederet. Date 1 LISDocRecordStatus- Code FESD:recordStatusCo de Journalpoststatus. Ref. til dimensionstabellen LISDocRecordStatusTable. LISDocRecordException [AFLEDT] Angivelse af at journalposten er undtaget offentlighed. 1=Undtaget, 0=ikke undtaget Code 1 Boolean 1 LISDocRecordExceptionRule FESD:recordPublicatio nindicator Henvisning til den lovgivning under hvilken denne JournalPost er undtaget offentlighedsloven. Udfyldes hvis JournalPosten er undtaget fra almindelig offentlighed. shorttext 1 LISDocRecordOnPaper FESD:recordPaperSto rageindicator [BEREGNET] Skal journalposten arkiveres i papirform eller elektronisk. Der bør anvendes følgende udfaldsrum: 1 = journalposten arkiveres på papir, ellers 0. Angiver antallet af dokumenter og/eller bilag i journalposten. Boolean 1 LISDocRecordNoDocuments Integer(4) 1 LISDocRecordRegisteredBy Entydigt brugernavn som angiver den person der har registreret journalposten. Er angivet med oprindelse [AFLEDT], idet FESDdatamodellen pt. indeholder en fremmednøgle (JournalPostRegistreretAf ), men ændringer er under udarbejdelse på baggrund af standardisering af brugeradministrationsmodulet. Entydigt brugernavn som angiver den person der er ansvarlig for journalposten. Er angivet som LISDocRecordResponsible [AFLEDT] [AFLEDT] Char(32) 1 Char(32) 1 24 / 30

79 afledt, idet FESD-datamodellen pt. indeholder en fremmednøgle (JournalPostAnsvarligSagsbehandler), men ændringer er under udarbejdelse på baggrund af standardisering af brugeradministrationsmodulet. LISDocRecordAnswer [AFLEDT] Identifikator knyttet til svardokument med henblik på registrering af svarrelation mellem et indgående og udgående dokument UUID 1 5 Dimensionstabeller knyttet til datasamlingen DOKUMENT LISDocRecordTypeTable Felt navn Beskrivelse Felt type LISDocRecordTypeCode Unik identifikation af dokumenttype. Code LISDocRecordTypeDescription LISDocRecordStatusTable Dokumenttypen beskrevet i klar tekst. Name Felt navn Beskrivelse Felt type LISDocRecordStatusCode Unik identifikation af dokumentstatus. Code LISDocRecordStatusDescription Dokumentstatus beskrivelse i klar tekst. Name 25 / 30

80 BILAG 1. NOARK s behandling af ledelsesinformation og oversigter Da FESD-standardiseringen tager udgangspunkt i den norske standard NOARK, er det skønnet nødvendigt kort at beskrive, hvorledes NOARK behandler området ledelsesinformation. Der skal allerede her gøres opmærksom på, at NOARK på dette område ikke i så høj grad fokuserer på informationsbehov for ledelsen, men i højere grad har sit fokus på det operationelle niveau, på journalførere etc. NOARK-standarden beskriver en række anbefalede rapporter og statistikker. Rapporterne kan være enten obligatoriske eller anbefalede. Statistikker er alene anbefalede. De obligatoriske rapporter er som følger med summarisk beskrivelse: - Arkivoversigt der giver overblik over hvilke dele, arkiver er opdelt i - Oversigt over alle journalførte dokumenter pr. dag - Offentlige dokumenter med overblik over dagens offentliggjorte dokumenter - Restanceliste over ubehandlede dokumenter - Sager med overskredet sagsbehandlingsfrist - Liste over dokumenter til udtagning - Kassationsliste - Afleveringsliste over materiale til andre arkiver etc. De anbefalede rapporter er som følger i uddrag: - Observationsliste over sager der skal genoptages på bestemt dato - Liste over udlån på sager og dokumenter - Sags- og dokumentoversigt - Dokumenter, der indgår i flere sager - Afsender/modtager-liste - Datokontrol De anbefalede statistikker kan kort opsummeres som: - Behandlings- og restancestatistik for dokumenter - Restancestatistik for sager - Sagsbehandlingstid for dokumenter - Sagsbehandlingstid for sager - Antal journaliserede dokumenter over tid - Antal journaliserede sager over tid - Statistik over korrespondancepartnere - Statistik over anvendte arkivkoder Fælles for alle listede statistikker er, at man kan foretage udtrækket i forhold til organisatoriske enheder, typer og tidsdimensioner. 26 / 30

81 Bilag 2. Anvendte typer i FESD-modellerne FESD-modellerne er udarbejdet i UML med det formål at beskrive den logiske informationsarkitektur i en FESD-løsning. UML-modellen er opbygget af et antal klasser, der igen er opbygget af relationer til andre klasser og primitive typer, så man kan opfatte UML-modellen som opbygget af byggesten, hvoraf den mindste er de primitive datatyper. I UML-modellen beskriver de primitive datatyper det logiske domæne, som datatypen kan antage, men ikke hvordan den fysiske repræsenation af data skal være. En gennemgang af de FESD-modeller, der på nuværende tidspunkt foreligger, viser, at vi har anvendt nedenstående primitive datatyper. I skemaerne ses for hver primitiv datatype, der anvendes i FESD-UMLmodellen, den tilsvarende datatype for hhv. SQL og XSD. integer Benyttes til angivelse af heltal. Der kan benyttes en angivelse af max længde hvis intet er angivet,vil domænet være i intervallet mellem og Anvendte længder i den nuværende model: 2, 3, 4, 6, 8, 10. Benyttes alene til naturlige tal (positive heltal). Benyttes også til at danne identifikator med udfaldsrum Nedenstående skema viser eksempler på heltalstyper og deres repræsentation i hhv. SQL og XSD UML Type Beskrivelse SQL datatype XSD datatype Integer Heltal i rummet mellem og , begge tal inclusive. NonNegativeInteger boolean Er en grundtype i UML. Den maksimale længde angives i modellen (*Hvordan?*) Naturlige tal Heltal i rummet mellem 0 og , begge tal inclusive NUMBER(Maksimal længde) NUMBER(Maksimal længde) xsd:int xsd:int UML Type Beskrivelse SQL datatype XSD datatype Boolean Udfladsrummet er binært true / false (eller rigtigt / forkert). BOOLEAN xsd:boolean Identifikationstyper UML Type Beskrivelse SQL datatype XSD datatype URI Enhver mulig lovlig URI. Der kan evt. anvendes en maxlængde. STRING xsd:anyuri 27 / 30

82 HttpURI Lovlig http(s)-adresse STRING xsd:anyuri MailToURI Smtp-adresse på en mailmodtager. STRING Evt. restrictions der afgrænser til http. xsd:anyuri UUID Identifikator på objekt UUID xsd:anyuri Evt. restrictions der afgrænser til mailadresser. Evt. restrictions der afgrænser til UUID. char Benyttes til karakterstrenge af varierende længde, men med en defineret maksimal længde. Anvendte længder: 1, 2, 3, 4, 15, 16, 20, 34, 40, 50, 60, 70, 110, 120, 255. Benyttes også nogle steder til at angive en boolskværdi. Bør ændres så typen alene bruges til tekststrenge: UML Type Beskrivelse SQL datatype XSD datatype Char ShortText Text Code Name ReferenceText date, datetime og time. Den minimale og maksimale længde er angivet i modellen. Anvendes til felter der indeholder en kort beskrivende tekst Anvendes til en beskrivende tekst med en fast længde. Anvendes til at beskrive en kode, der er nøgle/fremmednøgle i en opslagstabel. Anvendes tilfelter der indholder navne, der kan opfattes som brugervendte nøgler. Anvendes til at felter der indholder tekster, der af brugerne opfattes som fremmednøgler. Typen Date bruges til at angive dato. VARCHAR(maksimal længde) VARCHAR(70) VARCHAR(255) VARCHAR(2) VARCHAR(70) VARCHAR(40) xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Typen DateTime bruges til Dato og tidspunkt, også i betydningen tidsstempel. Typen Time bruges til klokkeslæt. UML Type Beskrivelse SQL datatype XSD datatype Year Årstal VARCHAR (4) xsd:gyear Date Dato DATE xsd:date DateTime Dato og tidspunkt DATETIME xsd:datetime Med restriction på den maximale længde 28 / 30

83 Time Tidspunkt uden datoangivelse TIME xsd:time string Er en grundlæggende type i UML. UML Type Beskrivelse SQL datatype XSD datatype String Tekststreng af vilkårlig længde STRING xsd:string float Defineres som sådan: UML Type Beskrivelse SQL datatype XSD datatype Float Decimaltal hvor længde og præcision begrænses til en samlet størrelse på 16-bit. DECIMAL(X,Y) xsd:float 29 / 30

84 30 / 30

85 BILAG 7 Cover Dagsordenspunkt 9, OIO- komitéen, 9. oktober 2008 Beslutning Standard for integrationsmønstre Resumé Projektet Web Service Integration mellem Sager og Dokumenter (WS I-SD) har haft standard for hændelse i høring. Høringen har givet anledning til, at ITST værksætter en åben OIO proces for at nå en standard for hændelse, at ITST indstiller at integrationsmønstrene fra projektet ophøjes til standarder. Sagsfremstilling Projektet Web Service Integration mellem Sager og Dokumenter (WS I-SD) har haft standard for hændelse i høring. Høringssvarene falder i tre kategorier: 1) mindre ændringer ønskes 2) inddragelse af andre myndigheder/områder, før der vedtages en egentlig OIO-standard, ønskes OG der ønskes reelle erfaringer med definitionen af hændelse, før den ophøjes til standard 3) det ønskes, at en OIO-standard forhold sig mere eksplicit til internationale standarder Projektet har tilrettet sin beskrivelse af hændelse jf. kommentarer i kategori 1. ITST adresserer bemærkninger i kategori 1 og 2 ved at invitere til en åben OIO proces for standardisering af hændelse. Projektet har samtidig peget på tre relevante integrationsmønstre: link mellem fagsystemsag og ESDH-sag, der anbefales ved simpel integration, hvor der ikke udveksles information. Links på brugergrænsefladen SOA integration i form af webservices, når det handler om sagsoverblik på tværs af systemer hændelsesbaseret, asynkron integration på tværs af systemer, når det drejer sig om udveksling af meddelelser med forretningsværdi, og hvor de respektive systemer ikke bør sættes i stå ved at afvente svar fra hinanden. 1. oktober 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Per de Place Bjørn Telefon Telefax E-post ppb@itst.dk Se den udførlige projektdokumentation på Indstilling ITST indstiller, at OIO-komiteen godkender at ITST iværksætter en åben OIO-proces for standard for hændelse de kontekstspecifikke integrationsmønstre

86 BILAG 8 Cover Dagsordenspunkt 10, OIO- komitéen, 9. oktober 2008 Beslutning Standar der for procesbeskrivelse Resumé Forslaget til optagelse af tre procesbeskrivelsesstandarder BPMN, XPDL og BPDM - har været i høring fra d. 1. september 2008 til 21. september Der er modtaget 19 høringssvar - alle positive hvorfor de tre standarder forelægges til optagelse i det nye OIO-katatalog med indstillingerne henholdsvis anbefalet, anvendelig og under observation. Sagsfremstilling Indstillingen til OIO-Komitéen vedr. standarderne BPMN, XPDL og BPDM skal efterkomme ønsket om standarder for procesbeskrivelse i OIO-kataloget. Interessen for offentlige forretningsprocesser (i nogle sammenhænge kaldet arbejdsgange) er stor; idet den offentlige sektor gennem stadig bedre udnyttelse af digitale muligheder skal levere bedre, mere sammenhængende og effektiv service til borgere og virksomheder. Kortlagte og optimerede processer fremmer effektiv udnyttelse af ressourcer, forbedrer mulighederne for at have styr på forretningsbegreberne (forudsætning for datastandardisering) og øger mulighederne for at kunne udvikle/købe it, som understøtter forretningens behov. BPMN har været i høring med indstilling anbefalet, XPDL med indstillingen anvendelig og BDPM med indstillingen under observation. Høringssvarene har alle været positive. 30. september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Benny Rysz Telefon Telefax E-post bery@itst.dk Det oprindelige forslag og høringssvarene kan ses på ITSTs hjemmeside: (i PDF, Excel, ODF og OOXML). I ndstilling Det indstilles, at komitéen godkender de tre standarder med den i forslaget angivne anbefalingsgrad således, at disse kan udstilles i det nye OIO-Katalog. Bilag - Høringsnotat af 30. september 2008 o Servicestyrelsens bemærkninger o KMDs bemærkninger - Høringsbrev af 29. august 2008

87 BILAG 8 Høringsnotat Dagsordenspunkt 10, OIO- komitéen, 9. oktober 2008 Beslutning Høringsnotat om procesbeskrivelsesstandarder Der er indkommet 19 OIO-høringssvar: Følgende 17 respondenter har ingen kommentarer eller bemærkninger: Sikkerhedsstyrelsen Forsknings- og Innovationsstyrelsen Patent- og Varemærkestyrelsen Kulturministeriets Administrationscenter Undervisningsministeriets Departement og Skolestyrelsen. Ministeriet for Videnskab, Teknologi og Udvikling Domstolsstyrelsen Banedanmark IT Ministeriet for Sundhed og Forebyggelse Integrationsministeriet Dansk IT Beskæftigelsesministeriets IT Velfærdsministeriet med underliggende styrelser Erhvervs- og Selskabsstyrelsen - Center for IT Datatilsynet Region Sjælland Forsvarskommandoen 30. september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Benny Rysz Telefon Telefax E-post bery@itst.dk Følgende 2 respondenter har bemærkninger: Servicestyrelsen KMD Servicestyrelsen bemærker, at "de tre standarder allerede bruges i flere forskellige sammenhænge på området for social og omsorg." Styrelsens svarbrev er vedlagt sagen. KMD har den bemærkning, at "KMD bakker op om valget af BPMN til at understøtte design af procesmodeller, men vi bakker ikke op om BPMN til automatisk kodegenerering på basis af procesdiagrammer." KMD foreslår på den baggrund, at ITST i den endelige formulering præciserer anvendelsen af BPMN. KMDs svarbrev er vedlagt sagen. ITST er enig i KMD s forslag til præcisering vedr. anvendelse, og ITST agter at indarbejde denne præcisering i vejledningen til standarden.

88 IT- og Telestyrelsen Benny Rysz Servicestyrelsen Skibhusvej 52 B 5000 Odense C Tlf servicestyrelsen@servicestyrelsen.dk september / MTH Høringssvar om optalelse af tekniske standarder for procesbeskrivelse i OIOkataloget 2008 Baggrund IT- og Telestyrelsen har udsendt et nyt udkast til ajourføring af 3 tekniske standarder i offentlig høring, jf. høringsnotat af 29. august 2008 med bilag. Det drejer sig om følgende: Optagelse af 3 tekniske standarder i OIO- Kataloget. Udkastet til vejledning kan findes på: Kommentar og bemærkninger De tre tekniske standarder bruges i allerede i flere forskellige sammenhænge på området for social og omsorg. Konsekvenser Optagelse af de 3 tekniske standarder i OIO-kataloget vil kun have positive konsekvenser for social og omsorg, da det bl.a. ensretter notationen for processer. Venlig hilsen Michael Dyhr Thomsen IT-konsulent mth@servicestyrelsen.dk

89 IT- & Telestyrelsen att.: Benny Rysz Mail: Høringssvar vedr. Procesbeskrivelsesstandarder 19. september 2008 Ref.: PSB KMD har disse kommentarer til høringen vedr. "Optagelse af tekniske standarder for procesbeskrivelse i OIO-kataloget 2008". BPMN KMD støtter valget af BPMN som en simpel, forståelig de-facto standard for procesbeskrivelser. Men vi har et enkelt forbehold, som bedst forklares ved at gengive en passus fra side 11 i standarden (version 1.1): BPMN provides a Business Process Diagram (BPD), which is a Diagram designed for use by the people who design and manage business processes. BPMN also provides a mapping to an execution language of BPM Systems (BPEL4WS). Thus, BPMN would provide a standard visualization mechanism for business processes defined in an execution optimized business process language. KMD bakker om valget af BPMN til at understøtte design af procesmodeller, men vi bakker ikke op om BPMN til automatisk kodegenerering på basis af procesdiagrammer. Vi foreslår, at IT- og Telestyrelsen i den endelige formulering præciserer anvendelsen af BPMN. XPDL KMD støtter valget af XPDL til udveksling af BPMN-procesdiagrammer. BPDM KMD bifalder, at IT- og Telestyrelsen har sat BPDM under observation. Venlig hilsen Peter Bøttcher Software Proceschef Direkte telefon: psb@kmd.dk KMD A/S Udviklingssupport Lautrupparken Ballerup Tel Fax CVR-nr. DK Hjemsted: Ballerup Side 1 af 1 side(r) J.nr.: OIO-høring: Procesbeskrivelsesstandarder

90 Notat Høringsnotat om optagelse af tekniske standarder for procesbeskrivelse i OIO-kataloget 2008 Indhold 1. Indledning 2. BPMN 3. XPDL 4. BPDM Bilag 1: Uddybende skema vedr. BPMN Bilag 2: Uddybende skema vedr. XPDL Bilag 3: Uddybende skema vedr. BPDM 1. Indledning Standarder til beskrivelse af processer til OIO-kataloget: BPMN, XPDL og BPDM Denne indstilling til OIO-komiteen vedr. standarderne BPMN, XPDL og BPDM skal efterkomme ønsket om standarder for procesbeskrivelse i OIO-kataloget. Interessen for offentlige forretningsprocesser (i nogle sammenhænge kaldet arbejdsgange) er stor; idet den offentlige sektor gennem stadig bedre udnyttelse af digitale muligheder skal levere bedre, mere sammenhængende og effektiv service til borgere og virksomheder. Det er målsætningen, at offentlige myndigheder i stigende grad arbejder sammen om sammenlignelige processer. Standardiserede beskrivelser af forretningsprocesser er en forudsætning for at skabe sammenhæng i processer på tværs af myndigheder og udnytte muligheder for genbrug af løsninger. Dette er den overordnede begrundelse for, at det foreslås at optage standarder for procesbeskrivelse i OIO-kataloget. 29. august 2008 IT- og Telestyrelsen Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Benny Rysz Telefon Telefax E-post bery@itst.dk Sagsnr. Dok nr Side 1/2 2. BPMN (Business Process Modeling Notation) BPMN er en standardiseret grafisk notation, der primært er udviklet til at tegne forretningsprocesser i et workflow. En arbejdsgang noteres eller visualiseres i BPMN i enkle diagrammer med et mindre sæt af grafiske elementer, som gør det overskueligt for forretningsansvarlige at forstå og formidle virksomhedens processer til interessenter som f.eks. IT-udviklere.

91 BPMN-diagrammer kan dog ikke 'tale for sig selv' det er som regel nødvendigt at forsyne dem med 'ledsagetekst', som placerer dem i en forståelsesramme og rette kontekst. Et BPMN-diagram kræver ofte fortolkning. Et eksempel på anvendelse af BPMN i offentligt regi er KL s arbejdsgangsbank med administrative processer (kommunale arbejdsgange). BPMN standarden indstilles til anbefalingsniveauet anbefalet. 3. XPDL (Process definition Interchange) XPDL er den førende standard i markedet for lagring og udveksling af procesmodeller, ligesom en lang række produkter og applikationer har implementeret denne standard. Standardisering på dette område letter udveksling af procesmodeller med andre offentlige virksomheder og leverandører af ITløsninger. IT- og Telestyrelsen Side 2/2 XPDL standarden indstilles til anbefalingsniveauet anvendelig. 4. BPDM (Business Process Definition Metamodel) En principielt konkurrerende standard til XPDL er BPDM, som er udviklet af OMG, dvs. den samme organisation, der står bag BPMN, er på vej, men har p.t. nogle mangler, og det vurderes, at der vil gå nogen tid inden denne stabiliseres. Ved den fremtidig vedligeholdelse af anbefalingerne på dette område, bør denne standard vurderes sammen med XPDL. BPDM indstilles til anbefalingsniveauet 'under observation'.

92 Indstilling af standarden BPMN til OIO-kataloget 1. september Generelt 1.1. Navn (Standard): Business Process Modeling Notation 1.2. Betegnelse (standard akronym) BPMN 1.3. Version Standarden ejes og vedligeholdes af 'Object Management Group' (OMG). Den aktuelle version er Formål Grafisk notation til beskrivelse af standarder. 2. Vurdering 2.1. Åbenhed OMG er en organisation med en høj grad af åbenhed. Standarden vurderes som åben Markedsmæssige forhold Eneste betydende standard på dette område. Standarden støttes af en betydelig og stigende andel af leverandører. Det vurderes, at standarden har momentum til at blive den gældende standard for grafisk beskrivelse af forretningsprocesser Forretningsmæssig relevans Standardiserede beskrivelsesmetoder for forretningsprocesser er en forudsætning for genbrug af procesdiagrammer og modeller på tværs af offentlige virksomheder. 3. Tekniske forhold 4. Kontekst Generelt anvendelig. 5. Status 5.1. Status august 2008 Ikke med i OIO-kataloget Foreslået ny status: Indstilles til niveauet 'anbefalet' i OIO-kataloget Kort redegørelse for foreslået ændring BPMN har stigende betydning for offentlige (og private) virksomheder mht. visuel dokumentation af arbejdsgange, proces-flow og som værktøj ifm. effektivisering af forretningsprocesser gennem digitalisering. OIO - Kataloget over offentlige IT-standarder 1 af 1

93 Indstilling af standarden XPDL til OIO-kataloget 1. september Generelt 1.1. Navn (Standard): Proces Definition Interchange 1.2. Betegnelse (standard akronym) XPDL 1.3. Version XPDL version 2.1 er vedtaget i april Denne indoptager og understøtter al funktionalitet i version 1.1 af BPMN Formål At fastlægge standard i XML-baseret format for lagring og udveksling af procesmodeller beskrevet i BPMN. 2. Vurdering 2.1. Åbenhed Standarden ejes og vedligeholdes af ' Workflow Management Coalition' (WfMC). WfMC er en bred organisation med en høj grad af åbenhed. Standarden vurderes som åben Markedsmæssige forhold XPDL er bredt accepteret på markedet og implementeret i en lang række produkter og applikationer Forretningsmæssig relevans Brug af XPDL bidrager konkret til Digitaliseringsprocessens målsætning om, at myndighederne i stigende grad skal arbejde sammen om sammenlignelige processer. 3. Tekniske forhold 4. Kontekst Generelt anvendelig. I det offentlige Danmark vurderer KL pt. XPDL i sammenligning med deres nuv. metode for XML-lagring i et repository og med kobling til begrebsdatabase i produktet Qualiware. 5. Status 5.1. Status august 2008 Ikke med i OIO-kataloget Foreslået ny status: Indstilles til niveauet 'anvendelig' i OIO-kataloget Kort redegørelse for foreslået ændring XPDL har betydning for offentlige (og private) virksomheder, der ønsker at lagre og udveksle visuel dokumentation af arbejdsgange og proces-flow-diagrammer udarbejdet i BPMN. XPDL muliggør udveksling af processer på tværs i og af organisationer og letter samarbejde om tværgående processer og hermed til udvikling og indkøb af mere effektive systemer. OIO - Kataloget over offentlige IT-standarder 1 af 2

94 Indstilling af standarden BPDM til OIO-kataloget 1. september Generelt 1.1. Navn (Standard): Business Process Definition Metamodel 1.2. Betegnelse (standard akronym) BPDM 1.3. Version Version Finalization underway pr. december Formål Formålet er at definere en formel metamodel for, hvordan en forretningsproces beskrives, som kan virke som fælles format mellem forskellige forretningsprocesnotationer. BPDM understøtter flere (model-) konstruktioner end BPMN. 2. Vurdering 2.1. Åbenhed Standarden ejes og vedligeholdes af OMG Obejct Management Group en organisation med en høj grad af åbenhed. Standarden vurderes som åben Markedsmæssige forhold BPDM kan det samme som XPDL, men inden for OMGs metasprog og formater, og organisationen OMG ønsker at fremme BPDM frem for XPDL hvad der på sigt kan gøre BPDM interessant. Standarden er stadig imidlertid stadig umoden i modsætning til XPDL, der er bredt implementeret og accepteret på markedet Forretningsmæssig relevans Kan på sigt få samme relevans som XPDL. 3. Tekniske forhold 4. Kontekst Forventes generelt anvendelig. 5. Status 5.1. Status august 2008 Ikke med i OIO-kataloget Foreslået ny status: Indstilles til niveauet 'under observation' i OIO-kataloget Kort redegørelse for foreslået ændring Indstilles i lighed med XPDL men foreløbig uden anbefaling. OIO - Kataloget over offentlige IT-standarder 1 af 1

95 Oversigt over standarder under behandling Den offentlige it-standardiseringsproces består i en række stadier, som standarder kan gennemløbe på deres vej mod godkendelse: Under forberedelse => Under Validering => I Høring => OIO IT-standard => Obligatorisk, åben standard Ikke alle standarder gennemløber alle stadier og standarder ender på forskellige stadier. Skiftet mellem stadier kendetegnes ved en aktiv proces, som oftest håndteres af IT- og Telestyrelsen i egenskab af varetager af OIO-sekretariatet Indlevering: Dette er det første trin, hvor en aktør foreslår en standard eller sekretariatet identificerer et behov. Validering: Dette trin indebærer, at sekretariatet undersøger tekniske aspekter af standarden i forhold til gældende retningslinier. Eventuelt undersøges økonomiske og juridiske aspekter, der kan øve indflydelse på udformningen eller bedømmelsen af standarden. Høring: Når valideringen succesfuldt afsluttet sendes standarden i tværoffentlig høring. Vedtagelse: Når høringsprocessen er afsluttet, og høringssvarene er indarbejdet, vedtages standarden i OIO-komitéen. Vedtagelse som obligatorisk, åben standard: Enkelte standarder gøres obligatoriske. Standarder, som i øjeblikket befinder sig i de ovennævnte stadier findes opgjort nedenfor. Standarderne er grupperet som Tekniske Standarder, Metodestandarder og Datastandarder og derefter organiseret efter det aktuelle stadie. På findes mere information om standardiseringsprocessen. 30. september 2008 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Per de Place Bjørn Telefon E-post ppb@itst.dk