Specifikation af Model for Sag Version 2.0
Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning.
Standarden er udarbejdet af en arbejdsgruppe under OIO-udvalget for sags- og dokumentområdet.
Version 1.2 er udarbejdet i regi af Den fællesoffentlige Styregruppe for Sag og Dokument.
Version 2.0 er udarbejdet i regi af den fællesoffentlige Styregruppe for Data og Arkitektur.
Arkitektur.digst.dk
Indledning
Formål med Sagsmodellen
Formålet med Sagsmodellen er at gøre det lettere at udveksle oplysninger om sager mellem to eller flere it-systemer, ved at skabe en fælles forståelse af hvad en sag er, og hvilke informationer en sag består af. Sagsmodellen definerer de begreber, forretningsobjekter, attributter, datatyper og relationer, som til sammen beskriver en sag.
Sagsmodellen definerer de fælles metadata for sager på tværs af fagområder. I modellen defineres derimod ikke attributter eller andre egenskaber, som er specifikke for anvendelse på de forskellige fagområder. For anvendelse af Sagsmodellen på specifikke fagområder skal modellen derfor specialiseres og tilføjes de domænespecifikke attributter og relationer, fx for ydelsessager på ydelsesområdet.
Sagsmodellen er det forretningsmæssige udgangspunkt for transformation fra model til konkrete repræsentationer af data i form af udvekslingsformater, som kan udveksles mellem it-systemer.
Ændringer siden version 1.2
Sagsmodellen er en revision af “Specifikation af serviceinterface for Sag. Version 1.2” (OIO Sag 1.2). Sagsmodellen er udarbejdet som en del af en samlet revision af specifikationerne, som samlet set omtales standarderne for OIO Sag og Dokument:
- Specifikation af serviceinterface for Dokument, Version 1.1.1 (OIO Dokument).
- Specifikation af serviceinterface for Organisation, Version 1.1 (OIO Organisation).
- Specifikation af serviceinterface for Klassifikation, Version 1.1 (OIO Klassifikation).
- Specifikation af serviceinterface for Sag, Version 1.2 (OIO Sag).
- Specifikation af serviceinterface for Arkivstruktur, Version 1.1 (OIO Arkiv).
- Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet, Version 1.1 (OIO Generelle egenskaber).
OIO Arkiv har ingen kendte implementeringer. Endvidere har ingen af de adspurgte interessenter udtrykt et forretningsbehov for at tage den i anvendelse. Specifikationen revideres derfor ikke, men afpubliceres og udgår som standard.
OIO Generelle egenskaber indeholder specifikke krav til udstilling af data i webservices. Erfaringerne fra implementering af standarderne er, at de generelle egenskaber er svære at forstå og kommunikere. Det kan give anledning til misforståelser mellem kravstillere og udviklere. Specifikationen revideres derfor ikke, men afpubliceres og udgår som standard.
OIO Generelle egenskaber udgår. Derfor kan Sagsmodellen stå alene i forhold til forståelsen af modellens forretningsobjekter. I hver af de opdaterede specifikationer er der indført et afsnit om egenskaber for modellen. Her findes beskrivelse af modelnotation, forretningsobjekter, unik identifikation, attributter og relationer anvendt i Sagsmodellen. Denne beskrivelse er ens for de fire opdaterede standarder.
Egenskaber for Sagsmodellen
Sagsmodellen er en informationsmodel, der giver en grafisk og tekstuel beskrivelse af Sag (jf. [GODPRAKSIS]). I beskrivelsen er anvendt en række modelelementtyper:
- Som notation er anvendt UML klassediagram til beskrivelse af Sagsmodellen.
- UML-pakker er anvendt med henblik på sammenhæng og genbrug af modelelementer på tværs af modeller.
- Forretningsobjekter er i Sagsmodellen repræsenteret af en UML-klasse.
- Universelt unik, persistent identifikation af forretningsobjekterne er obligatorisk.
- Attributter beskriver informationsindholdet i Sagsmodellen.
- Relationer repræsenterer de strukturelle sammenhænge mellem forretningsobjekter i Sagsmodellen.
Modelelementtyperne og brugen af dem i Sagsmodellen er forklaret yderligere i de følgende afsnit.
Diagrammer
UML klassediagram udgør rammen for beskrivelse af Sagsmodellen og forretningsobjekterne, der indgår heri, og deres relationer. Formålet med diagrammet er visuelt at kommunikere de forskellige metadata, der indgår i beskrivelsen af en sag, når den skal udveksles mellem it-systemer. Diagrammet forklares uddybende i den medfølgende tekst.
Som en visuel hjælp til forståelsen af diagrammet benyttes i diagrammerne elementer, som ikke indgår i et normalt UML Klassediagram.
- Farvemarkering benyttes til at indikere, hvilke forretningsobjekter der defineres i modellen (grå), og hvilke der er eksternt definerede (blå).
- Part eksisterer ikke som en eksternt defineret model, men i modellen er Part alligevel vist som en UML Pakke, der rummer forretningsobjekterne Person og Virksomhed. Fremgangsmåden er anvendt for at kunne referere til de to objekter under et og i egenskab af Part.
Alle forretningsobjekter, attributter og relationer defineres og beskrives i afsnittene efter diagrammet.
Forretningsobjekter
Et forretningsobjekt er i UML Klassediagrammet for Sagsmodellen repræsenteret af en UML Klasse.
Forretningsobjekter i sagsmodellen er beskrevet som vist i Tabel 1 nedenfor:
Forretningsobjekt Navn |
Definition |
Beskrivelse |
---|---|---|
Entydigt klassenavn for det forretningsmæssige begreb. |
En kort og præcis definition. |
Uddybende beskrivelse og eksemplificering af forretningsobjektet. |
Universelt unik, persistent identifikation af forretningsobjekter
Universelt unik, persistent identifikation er obligatorisk for forretningsobjekterne i Sagsmodellen. Unik identifikation er beskrevet i attributten ID og bør være af typen http-URI.
Http-URI anvendes bl.a. af Grunddataprogrammet og i Den Fællesoffentlige Digitaliseringsstrategi 2016 – 2020. I retningslinjerne for stabile URI’er er beskrevet, hvordan eksisterende identifikatorer som fx UUID og URN kan genbruges med brug af http-URI (se [HTTPURI].
UUID (Universal Unique IDentifier jf. [RFC4122]) bør anvendes i konstruktionen af http-URI for forretningsobjekterne i Sagsmodellen. Egenskaberne ved UUID garanterer, at identifikatoren er universelt unik.
Eksempel på UUID:
91aa87da-9f06-11e7-abc4-cec278b6b50a
Eksempel på repræsentation af UUID i http-URI-form:
https://data.gov.dk/id/thing/91aa87da-9f06-11e7-abc4cec278b6b50
Http-URI’en bør konstrueres, så det kan resolveres, hvilken objekttype en UUID er identifikator for, fx om det er OrgEnhed, Dokument, Sag mv. Et eksempelvis på en http-URI for en konkret Sag kunne være:
https://data.gov.dk/id/case/case/91aa87da-9f06-11e7-abc4cec278b6b50a
Der kan være tilfælde, hvor det er nødvendigt at anvende en anden identifikator end UUID i konstruktion af http-URI. I retningslinjerne for stabile http-URI’er (se [HTTPURII]) er også anvist, hvordan en http-URI i så fald kan konstrueres:
Eksempel med emneklassen 27.34.02 i klassifikationssystemet KLE som identifikator, der indgår i konstruktion af http-URI:
https://data.gov.dk/id/classification/kle/subject#27.34.02
Eksempel med registreringsnummeret VZ26979 på køretøj som identifikator, der indgår i konstruktion af http-URI:
https://data.gov.dk/id/vehicle/registration#VZ26979
I tabellen nedenfor er vist, hvordan kravet om universelt unik, persistent identifikation af forretningsobjekter er beskrevet i modellen:
Betegnelse |
Beskrivelse |
Udfaldsrum |
---|---|---|
ID |
Forretningsobjektets universelt unikke, persistente identifikator. Angives som http-URI (se [HTTPURI]), eksempelvis:
Se også nærmere beskrivelse i afsnit ovenfor om universelt unik, persistent identifikation af forretningsobjekter. |
Http-URI |
Attributter
Sagsmodellens informationsindhold, fx titlen på en sag, er for de respektive forretningsobjekter, fx sagen, repræsenteret af attributter.
Attributter i Sagsmodellen er beskrevet som vist i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Datatype |
Regel for udfyldelse |
---|---|---|---|
Entydig navngivning af attributten inden for det enkelte forretningsobjekt. |
Den forretningsmæssige definition af attributten samt kort beskrivelse af dens anvendelse. Hvis attributten har et udfaldsrum, som ikke er givet i datatypen beskrives det også her. |
Angivelse af navn på datatype for attributten. |
Beskrivelse af de regler for anvendelse, der gælder for attributten, fx om den er obligatorisk. |
Beskrivelsen af attributter er yderligere uddybet og eksemplificeret i afsnittet ”Beskrivelser af attributter”, som følger efter tabellerne.
Datatyper
Sagsmodellen skal kunne anvendes som udgangspunkt for udvekslinger af oplysninger om sager mellem to eller flere it-systemer.
Angivelse af datatyper sikrer, at informationsindholdet beskrives og læses på samme måde af de it-systemer, som udveksler informationer, fx ved at deltagerne i en informationsudveksling bruger det samme datoformat.
Datatyperne præciserer modellens beskrivelser som udgangspunkt for transformation fra model til konkrete repræsentationer af data. Eksempelvis en XML-struktur som kan udveksles mellem itsystemer.
Datatyperne er beskrevet som vist i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Datatype grundlag |
Restriktioner |
---|---|---|---|
Navnet som anvendes til at angive datatype for en attribut. |
Beskrivelse af datatypen. |
Angivelse af den konkrete datatype med anvendelse af XSD-datatyperne jf. [XSD] |
Eventuelle restriktioner eller mønstre for datatypen. |
Nedenstående datatyper er anvendt i Sagsmodelle
Betegnelse |
Beskrivelse |
Datatype grundlag |
Restriktioner |
---|---|---|---|
Tekst |
Tekststreng. |
xsd:string |
|
Tekst(enumeratio n) |
Tekststreng med begrænsning i form af en kodeliste. |
xsd:string |
enumeration |
Heltal |
Helt tal uden decimaler.. |
xsd:integer |
|
Dato |
Dato uden tid |
xsd:date |
YYYY-MM-DD |
Dato og tidspunkt |
Præcis angivelse af dato og tid inkl. tidszone. |
xsd:dateTime |
YYYY-MMDDThh: mm:ss.sssTZD |
Http-URI |
For uddybende forklaring, se afsnit ovenfor om universelt unik, persistent identifikation af forretningsobjekter i Organisationsmodellen. |
xsd:string |
jf. [HTTPURI]
|
Boolean |
Anvendes med mulighed for at svare Ja/Nej. |
xsd:boolean |
True = ja, False = Nej |
Mulighed for tilpasning af attributters udfaldsrum
I Sagsmodellen er der attributter, hvor udfaldsrummet er angivet med brug af datatypen Tekst (enumeration).
Ved anvendelse af Sagsmodellen vil der opstå behov for at udvide de pågældende udfaldsrum i forhold til den konkrete forretningsmæssige anvendelsessituation. I de tilfælde kan udfaldsrummet tilpasses på en af følgende måder:
- Udarbejde en ny enumeration med det nye udfaldsrum på attributten.
- Udarbejde klassifikation til at rumme det nye udfaldsrum. De konkrete værdier udtrykkes som Klasser i Klassifikationen. Fra forretningsobjektet i Sagsmodellen tilføjes i modellen en relation til Klassifikationen, hvor Klasserne er udtrykt.
Ved tilpasning af udfaldsrum for attributværdier må gerne tilføjes men ikke fjernes værdier fra udfaldsrummet
Relationer
Relationer i Sagsmodellen er vist i diagrammer med betegnelse på relationen og kardinalitet på det forretningsobjekt, som relationen peger på.
Relationer er beskrevet som vist i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Objekttype |
Kardinalitet |
---|---|---|---|
Et beskrivende navn på relationen. |
En kort og præcis definition på relationen. |
Det forretningsobjekt relationen peger på. |
Angiver rammerne for relationen. |
Beskrivelsen af relationer er yderligere uddybet og eksemplificeret i afsnittet ”Beskrivelser af relationer”, som følger efter tabellerne.
Sagsmodellen
Sagsmodellen beskrives igennem:
- En introduktion til sagsbegrebet.
- Diagram for Sagsmodellen.
- Forretningsobjekter, attributter og relationer.
De enkelte punkter gennemgås i de følgende afsnit.
Sagsbegrebet
‘Sag’ som begreb er den dokumentationsenhed, der understøtter de offentlige institutioners journalisering.
De offentlige institutioner er underlagt et krav om at journalisere deres informationer. Journalisering er en proces, som indebærer registrering af indkomne og egenproducerede informationer samt deres forsvarlige opbevaring. Journalisering af informationer på sager understøtter de offentlige organisationer i udøvelse af god forvaltningsskik og overholdelse af den tværgående forvaltningslovgivnings krav til overblik over sagsbehandlingen, offentlighedens mulighed for indsigt, bevaring for eftertiden og forsvarlig behandling af personoplysninger.
Begrebet ’en Sag’ anvendes i mange forskellige sammenhænge og til mange forskellige formål, men udtrykker altid grundlæggende set det samme: En samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces, typisk til administrative formål, herunder til at træffe afgørelser.
En ‘Sag” skal påføres oplysninger om:
- Hvem sagen vedrører i form af oplysninger om sagens parter.
- Hvad sagen dokumenterer, i form af en sigende titel, emnemæssig opmærkning og den løbende registrering af tilknyttede dokumenter og øvrige informationer af betydning for sagsbehandlingen.
- Hvor sagen bliver behandlet og opbevaret i form af oplysninger om sagens organisatoriske tilhørsforhold og sagsbehandlere.
- Hvordan sagen hænger sammen med andre sager.
- Hvad sagens status er, og hvornår den er ændret.
- Hvorfor sagen behandles i form af en henvisning til den lovgivning, der gælder for sagen, samt hvor den findes.
For at skabe en fælles sagsmodel vil det være en fordel, at sagsbegrebet har fælles semantik og syntaks for at øge mulighederne for udveksling og gensidig forståelse af sager mellem myndighederne. Sagsmodellen giver en ramme for beskrivelse af sager igennem en fælles forståelse af ovenstående oplysninger.
Sager kan struktureres på forskellig vis i forhold til, hvor mange og hvilke informationer, der tilknyttes sagen. Sager lagret elektronisk i it-systemer bliver med fordel ofte struktureret som enkeltsager, som indeholder dokumentation om en enkelt administrativ proces, som fx en afgørelse eller en beslutning.
Opfordringen i Sagsmodellen er at strukturere organisationens sager som enkeltsager for at skabe de bedste forudsætninger for efterfølgende udveksling og visning af sager i overbliksløsninger.
Enkeltsag dækker Ombudsmandens og Forvaltningsjuraens krav om, at man kan fremlægge dokumentation (bevis) for de forskellige handlinger/aktiviteter i sagsbehandlingen.
Enkeltsag dækker ikke forskellige behov for at samle dokumentation i forhold til praktiske formål, fx i forhold til en borger/person (personsagen), en ejendom (byggesagen), en instans/part (institutionssagen), eller alle oplysninger om et bestemt emne eller en bestemt handling (fx alle sager om hjælpemidler eller alle klagesager). I en manuel sagshåndtering omtales samlinger som disse som ”samlesager” eller ”dossiersager”.
Sagsmodellen kan både beskrive enkeltsager og samlesager. I forhold til udveksling af sagsoplysninger har begreberne forskellig semantik, og man skal man være opmærksom på, at de to sagsbegreber kan være vanskelige at udveksle meningsfuldt:
- Én offentlig organisation kan have struktureret sine sager som samlesager, hvor alle oplysninger og dokumenter om én person er lagret i én samlesag centreret om personens CPR-nummer.
- En anden offentlig organisation kan have struktureret sine sager som enkeltsager, hvor oplysninger og dokumenter om hver enkelt afgørelse i forhold til en person er lagret på en enkeltsag.
- Selvom begge organisationer kan udveksle sager efter Sagsmodellen, kan de på grund af den forskellige strukturering af sager ikke uden en transformation udveksle sager på grund af forskellig struktur i sagsdannelsen.
Sagsmodellen giver mulighed for at relatere en sag til en oversag, så der kan skabes sammenhæng i enkeltsager, hvormed samlesager kan forstås som samlinger af enkeltsager.
Sagsmodellen beskriver kun de fælles metadata for sager. Ved anvendelse på specifikke fagområder specialiseres sagen og tilføjes fagområdets specifikke attributter og relationer. Det kan eksempelvis være en pensionssag eller en ydelsessag. Det er også her, at det fx kan være relevant at tilføje oplysninger om sagens genstand til sagen. Fx kan en model for sag, der omhandler ejendomme i en specialiseret anvendelse, med fordel inddrage en relation til en model for ejendomme.
Diagram for Sagsmodellen
Sagsmodellen og informationsindholdet heri er illustreret i Figur 1:
Sagsmodellen er samlet set grupperet ved hjælp af en pakke navngivet ”Sagsmodellen”, som anvendes ved ekstern reference til forretningsobjekter defineret og ejet af Sagsmodellen.
Diagrammet viser, at Sag er det centrale forretningsobjekt. Sagen og dens attributter er beskrevet i afsnittet omkring Sag.
Alle relationer i diagrammet peger væk fra det centrale forretningsobjekt Sag, som ejer relationerne. Der er ikke vist kardinalitet på Sag, som der altid skal være netop én af.
Dokumenters tilknytning til sagen sker igennem objektet Journalpost. JournalNotat er her defineret som en relation til et dokument, der ikke kan eksistere uden sagen.
Relationerne til Klasse i den eksternt definerede Klassifikationsmodel viser, at den relaterede værdi findes som en klasse i et klassifikationssystem.
Relation fra Sag til det eksternt definerede forretningsobjekt Retskilde beskriver de hjemler, der eventuelt måtte ligge til grund for en sag. For at kunne tilføje relationen en attribut i form af en beskrivelse af den konkrete paragraf, stk. nr. i retskilden er indsat objektet Sagshjemmel, som i praksis er en uddybende beskrivelse af relationen fra Sag til Retskilde.
Relationerne til sagens parter peger på en UML Pakke navngivet Part. Part findes ikke aktuelt som eksternt defineret forretningsobjekt. Derfor er Part som abstrakt betegnelse for personer eller virksomheder vist i diagrammet på denne måde i Sagsmodellen. Objektet Sagspart er en uddybende beskrivelse af relationen mellem sagen og dens parter og giver mulighed for at sætte en rolle på parten.
Relationerne til den eksternt definerede Organisationsmodel beskriver sagens stamdata i forhold til ejere, ansvarlige, behandlere og hvem der har oprettet og ændret sagen.
Relationerne til andre sager er vist i diagrammet ved, at der er indsat et nyt forretningsobjekt af typen Sag, som relationerne til andre sager peger på.
Forretningsobjekterne og deres relationer er beskrevet nærmere i de følgende afsnit.
Forretningsobjekter i Sagsmodellen
I Sagsmodellen indgår følgende typer af forretningsobjekter:
- Centrale forretningsobjekter, som er defineret og ejet af Sagsmodellen.
- Eksterne forretningsobjekter, som er defineret og ejet af andre modeller.
- Øvrige objekter som bidrager til beskrivelsen af informationsindholdet.
De forskellige objekttyper forklares nærmere i de følgende afsnit.
Centrale Forretningsobjekter
’Sag’ er Sagsmodellens centrale forretningsobjekt og er placeret i centrum af diagrammet.
Forretningsobjekt Navn |
Definition |
Beskrivelse |
---|---|---|
Sag |
Sag forstås som en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces, typisk til administrative formål, herunder til at træffe afgørelser. |
En sag består af et antal dokumenter, der vedrører det samme begivenhedsforløb. |
Eksternt definerede forretningsobjekter
I Sagsmodellen indgår en række forretningsobjekter, som er eksternt definerede.
Som en visuel hjælp til forståelse af diagrammet er eksternt definerede forretningsobjekter i diagrammet vist med blå farve.
Hvor forretningsobjektet er defineret og beskrevet i andre informationsmodeller, er det i diagrammet for Sagsmodellen modelleret ved hjælp af en pakke. Pakken angiver titlen på den eksterne informationsmodel, fx ”Organisation”, som angiver, at de eksternt definerede forretningsobjekter er defineret i Organisationsmodellen.
Betegnelse |
Definition |
Ekstern model |
Beskrivelse |
---|---|---|---|
OrgPerson |
OrgPerson repræsenterer en persons tilhørsforhold og medlemskab i Organisationer og Org-Enheder. |
Organisation se [ORG] |
OrgPersoner er personer med medlemskab af organisationen i en bestemt rolle, eksempelvis ansatte. |
Organisation |
En organisation er en anerkendt juridisk enhed med rettigheder og ansvar.
|
[ORG] |
Forretningsobjektet Organisation er den formelle præsentation i forhold til omverdenen.
Eksempler på organisationer er myndigheder (fx et ministerium, en styrelse, en kommune) eller virksomheder. |
OrgEnhed |
Forretningsobjektet Org-Enhed er som enhed en del af en Organisation og kan kun eksistere i forbindelse med denne. |
[ORG] |
Forretningsobjektet OrgEnhed giver struktur på organisationen og anvendes til at opbygge organisationshierarkier.
OrgEnheder kan spænde fra mindre enheder, som fx teams eller grupper, til store og komplekse enheder som indeholder andre enheder.
Eksempler på OrgEnheder er afdelinger, team, sektioner, kontorer, udvalg, projektgrupper, styregrupper, klasser, hold og lignende. |
Betegnelse |
Definition |
Ekstern model |
Beskrivelse |
Dokument |
Dokumenter er afgrænsede samlinger af informationer, i kendte strukturer, på kendte formater. |
[DOK] |
Dokumenter kan rumme tekster, tegninger, grafik, fotografier, video, tale og/eller meget andet.
Et dokument kan indgå i flere sager, dvs. have relation til flere begivenhedsforløb. |
Klasse |
Klasse er et begreb, som man ønsker at opmærke (klassificere) en sag med. |
[KLASSIFIKATION] |
En klasse kan fx være et emne, en handlingsfacet, et stikord mv. Klasser kan ordnes i lister eller hierarkier. |
Person |
Person er et individ, der er registreret i CPR-registeret med personnummer. |
[PERSON] |
Personer identificeres med CPR-nummer.
|
Virksomhed |
Virksomhed er en juridisk enhed registreret i CVR-registeret med CVR-nummer. |
[VIRKSOMHED] |
Organisatoriske aktører som sagspart registreres ved deres CVR-nummer.
|
Retskilde |
Er de faktorer, som danner grundlag for at opnå viden om, hvad der er gældende ret.
Retskildens relation til sagen er beskrevet igennem Hjemmel. |
[ELI] |
Alle danske retskilder er beskrevet og udstillet via https://www.retsinformation.dk og kan identificeres ved hjælp af den fælleseuropæiske identifikator for lovgivning “European Legal IDentifier” (Se [ELI]). |
Hjælpeobjekter i Sagsmodellen
Udover det centrale forretningsobjekt og de eksternt definerede forretningsobjekter er der i Sagsmodellen også defineret en række hjælpeobjekter, som bidrager til beskrivelsen af informationsindholdet.
Hjælpeobjekter i Sagsmodellen er uddybet i tabellen nedenfor:
Betegnelse |
Definition |
Relaterede objekter |
Beskrivelse |
---|---|---|---|
Sagspart | Sagspart er den part, som sagen omhandler eller påvirker. | Part | Nogle sagstyper skal have en sagspart, mens andre ikke skal. Klassen Sagspart bruges til at angive en parts rolle i forhold til sagen, fx en primær part eller sekundære partsroller som fx mor, far, kontaktperson mfl. |
Sagshjemmel |
Beskrivelsen af sagen kan beriges med information om den hjemmel, den behandles efter. En hjemmel kan være givet i en eller flere retskilder. |
Retskilde |
Alle danske retskilder er beskrevet og udstillet via https://www.retsinformation.dk og kan identificeres ved hjælp af den fælleseuropæiske identifikator for lovgivning “European Legal Identifier” (Se [ELI]). |
JournalNotat |
JournalNotat anvendes til at notere oplysninger, som er væsentlige for sagen, og som ikke fremgår af sagens øvrige dokumenter. |
JournalNotat |
JournalNotat er til det lovpligtige notat i afgørelsessager. Det er en del af sagen og kan ikke eksistere uafhængigt af denne. JournalNotat supplerer de oplysninger, der måtte fremgå af sagens relaterede dokumenter via JournalPost. |
Journalpost |
JournalPost anvendes til at berige tilknytninger mellem sagen og dokumenter med yderligere information. En Sags JournalPoster udgør sagens journal, og omfatter udover relationer til Dokumenter, også Journalnotater |
Dokument |
Eksempelvis kan et dokument vedlægges én sag, men tilakteres en anden sag. Eller et dokument kan vedlægges en dagsordenssag med én dokumenttitel og en byggesag med en anden dokumenttitel. På denne måde kan dokumenter indeholdes i flere sager og hver gang på nye betingelser. |
Sag
Sag er det centrale forretningsobjekt i Sagsmodellen. Den samlede beskrivelse af fænomenet ”en sag” gives igennem sagsmodellens objekter, attributter og relationer til eksterne forretningsobjekter.
Attributter
Sag har følgende attributter:
Betegnelse |
Beskrivelse |
Datatype | Regel for udfyldelse |
---|---|---|---|
ID |
Forretningsobjektets universelt unikke, persistente identifikator. Angives som http-URI (se [HTTPURI]), eksempelvis: Se også nærmere beskrivelse i afsnit ovenfor om universelt unik, persistent identifikation af forretningsobjekter. |
Http-URI |
Obligatorisk |
Sagsnummer |
Sagens identifikation ved et sagsnummer. Der er ikke noget standardiseret format for sagsnummer. Men da sagsnummeret også fungerer som brugervendt nøgle for sagen følger, at sagsnummeret skal være unikt inden for samme myndighed. Det betyder fx, at to sager i samme myndighed ikke må have samme sagsnummer, selvom de kommer fra to forskellige fagsystemer, mens én sag og ét dokument godt kan have samme brugervendte nøgle. Et eksempel på en konvention for sagsnumre er [emneklasse]-[oprettelsesdato]-[løbenr]. |
Tekst | Obligatorisk |
Titel |
Officiel sagstitel, som offentligheden må se. Sagens titel som er tilgængelig for offentligheden. Eksempelvis på åbne dagsordner for byrådsmøder publiceret på kommunens hjemmeside. Titel udfyldes altid. Hvis sagen er undtaget fra offentligheden, skal denne titel-attribut udfyldes med en titel, som offentligheden gerne må se (anvendes ved åbne dagsordenpunkter). Titlen som offentligheden ikke må se registreres i attributten ’OffentlighedUndtagetAlternativTitel’ (anvendes fx ved lukkede dagsordenpunkter). |
Tekst | Obligatorisk |
Beskrivelse |
Sagsbeskrivelse i fri tekst. Mulighed for at angive en beskrivelse af sagens indhold og formål. |
Tekst | Ikke obligatorisk |
OffentlighedUndtagetAlternativTitel |
Hvis der er truffet beslutning om undtagelse fra offentligheden angives den titel, som offentligheden ikke må se, i denne attribut. Denne titel angives kun, hvis sagen er undtaget fra offentligheden. I denne attribut skrives den sagstitel, som offentligheden ikke må se, hvorimod den titel, som offentligheden gerne må se skrives i attributten ’Titel’. |
Tekst | Obligatorisk hvis relationen Hjemmel/OffentlighedUndtaget Hjemmel er udfyldt. |
Principielindikator | Indikator for om sagen er udnævnt som principsag, som kan danne præcedens for andre sager. | Boolean | Ikke obligatorisk |
Afleveretindikator |
Indikator for om sagen er afleveret til offentligt arkiv. Må kun anvendes, når det offentlige arkiv har godkendt den arkiveringsversion, som sagen indgår i. Det skal ved udarbejdelse af arkiveringsversion sikres, at indikatoren på sagsniveau kan omsættes til til dokumentniveau for sagens tilknyttede dokumenter. |
Boolean |
Ikke obligatorisk |
Kassationsindikator |
Styrer om sagen skal bevares og dermed afleveres til offentligt arkiv, eller om den må kasseres. |
Boolean |
Ikke obligatorisk Udfyldes kun ved afvigelse fra Kassationskode som følger af emne- og handlingsklasse. |
SagsTilstand |
Sager har følgende tilstande, der indikerer sagens forretningsmæssige fremdrift i forhold til behandling:
De nævnte tilstande udtrykker alene selve sagens tilstand og udtrykker således ikke noget processuelt i forbindelse med sagsbehandlingen, som fx at sagen er sendt i høring. Tilstand forstås altså i specifikationen som den passive dokumentation for, hvad der er sket med sagen, og dermed hvilken tilstand den er bragt i. |
Tekst (enumeration) |
Obligatorisk |
TilstandsDato |
Dato for sagens aktuelle tilstand. Dato skal sættes ved hvert tilstandsskift. |
Dato |
Obligatorisk |
OprettetTidspunkt |
Tidspunkt for sagens oprettelse. Altid det aktuelle tidspunkt for oprettelse af sagen. |
DateTime |
Obligatorisk |
Relationer
Sag har mange relationer. Af hensyn til overskueligheden er relationer i det følgende grupperet efter, hvilket eksternt objekt de relaterer til.
Relationer til Sag
Sags relationer til andre sager er beskrevet i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Relateret objekt |
Kardinalitet |
---|---|---|---|
Oversag |
Denne sag er knyttet til én og kun én oversag. Sager kan have relation til en oversag, så der på den måde opstår hierarkier. Eksempelvis i form af samlesager. |
Sag |
0..1 |
AndenSag |
Sag kan være relateret til en eller flere andre sager, der har relevans for sagen. Det kan fx være en klagesag, hvor relationen AndenSag anvendes til relationen til sagen, som klagen vedrører. |
Sag |
0..n |
Præcedens |
Sag som anvendes som forlæg i den aktuelle sag. Sager, der relateres med relationen Præcedens, er sager, der har betydning for, hvordan fremtidige sager behandles og kan være opmærket som principielle. |
Sag |
0..1 |
Relationer til Klassifikation
Sags relationer til Klassifikation er beskrevet i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Relateret objekt |
Kardinalitet |
---|---|---|---|
Emneklasse | Klassen i Klassifikation, der anvendes som registreringssystematik. | Klasse | 1..1 |
Handlingsklasse |
Den handling som sagen er underlagt. Angiver om sagen er en rutinesag, en ankesag, politisk sag eller andet, som kan nuancere primærklassen eller opgaveklassen. |
Klasse | 0..1 |
Kontoklasse |
Den konto som sagen konteres efter, fx konto i Klassifikation IM- kontoplan. |
Klasse |
0..1 |
Sikkerhedsklasse |
Den sikkerhedsklasse som sagen tilhører. Det kan eksempelvis være en klassifikation med Klasserne:
|
Klasse |
0..1 |
Følsomhedsklasse |
Den følsomhedsklasser som sagen tilhører. Det kan eksempelvis være en Klassifikation med Klasserne:
|
Klasse |
0..1 |
Relationer til Organisation
Sags relationer til Organisation er beskrevet i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Relateret objekt |
Kardinalitet |
---|---|---|---|
Ejer |
Den Organisation der har det officielle ejerskab til sagen. Der skal altid være en ejer. Det kan fx være den Organisation, som OrgPerson, der er primær behandler, er tilknyttet. |
Organisation |
1..1 |
Ansvarlig |
Den Organisation eller Organisatoriske Enhed, der er ansvarlig for sagens behandling, fx jf. organisationens ansvars- og opgavefordeling. Denne aktør vil typisk være en Org-Enhed, der er tilknyttet den Organisation, der ejer sagen. |
OrgEnhed Organisation |
0..1 |
Primær Behandler |
Den OrgPerson, der behandler sagen. Det vil typisk være en OrgPerson, som er tilknyttet den OrgEnhed, der er ansvarlig. Den primære behandler kan dog også være et team, der i så fald repræsenteres via en organisatorisk enhed. |
OrgPerson OrgEnhed |
0..1 |
Anden Behandler |
De OrgPersoner, der også behandler sagen. De tilknyttes typisk af den OrgPerson, der er Primær Behandler. |
OrgPerson OrgEnhed |
0..n |
OprettetAf |
OrgPerson eller It-system som har oprettet sagen. |
OrgPerson It-system |
1..1 |
ÆndretAf |
OrgPerson eller It-system som har afstedkommet ændring i sagens tilstand. |
OrgPerson It-system |
0..n |
Sagspart
Sagspart bruges til at beskrive relationen mellem sagen og dens parter. Nogle sagstyper skal have en sagspart, mens andre ikke skal.
En Part er den person (med eller uden CPR-nummer) eller virksomhed (med eller uden CVR-nummer), som sagen omhandler eller påvirker. Klassen Part er en generalisering af forretningsobjekter af typen Person eller Virksomhed. En myndighed kan også være part i en sag men vil så være repræsenteret ved typen virksomhed med et CVR-nummer.
Attributter
Sagspart kan beskrives yderligere ved hjælp af attributten partsrolle, der er defineret i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Datatype |
Regel for udfyldelse |
---|---|---|---|
Partsrolle |
Partsrolle beskriver den rolle, som en part har i forhold til sagen. Parter kan have vidt forskellige roller i forhold til sagen. De kan fx være ægtefæller, kontaktpersoner eller ejendomsejere. Ønskes en nærmere angivelse af udfaldsrummet for Partsrolle for sagsparter – fx en kontaktperson som sekundærpart - kan relationen yderligere beskrives igennem tilpasning af denne attribut jf. beskrivelsen heraf i afsnittet ’Mulighed for tilpasning af attributters udfaldsrum’. |
Tekst[enumeration] |
Ikke obligatorisk |
Relationer til part
Relationerne fra Sagspart til part anvendes til at angive sagens parter.
Person og Virksomhed er de konkrete forretningsobjekter, der kan angives som part på en sag.
- Person identificeres med CPR.
- Ikke alle personer findes dog i CPR-registeret, fx udlændinge.
- Personer uden CPR-nummer identificeres med et erstatningsnummer.
- Erstatningsnummeret er typisk et lokalt tildelt identifikationsnummer. Af hensyn til identifikation er information om udstedende Organisation vigtig.
- Virksomhed identificeres med CVR.
- Ikke alle virksomheder findes i CVR-registeret, fx udenlandske virksomheder.
- Virksomheder uden CVR identificeres med et erstatningsnummer.
- Erstatningsnummeret er typisk et lokalt tildelt identifikationsnummeret. Af hensyn til identifikation er information om udstedende Organisation vigtig.
Part eksisterer ikke aktuelt som eksternt defineret forretningsobjekt. Part anvendes derfor her som en abstrakt betegnelse for personer og virksomheder. I diagrammet for Sagsmodellen er det vist ved, at Person og Virksomhed er vist i diagrammet i en UML Pakke navngivet Part, og som partsrelationerne fra Sagspart peger på.
Betegnelse |
Beskrivelse |
Objekttype |
Kardinalitet |
---|---|---|---|
Primær part |
Betegner den vigtigste part på sagen. En person kan fx være Primærpart for en sag, hvor parten er ansøger om eller modtager af en ydelse. Det vil typisk være en Primærpart, som afgørelser mv. stiles til. |
Person Virksomhed |
0..1 |
Sekundær part |
Betegner øvrige parter på sagen. |
Person Virksomhed |
0..n |
Sagshjemmel
Beskrivelsen af sagen kan beriges med information om den hjemmel, den behandles efter. En hjemmel kan være givet i en eller flere retskilder. Alle danske retskilder er beskrevet og udstillet via https://www.retsinformation.dk og kan identificeres ved hjælp af den fælleseuropæiske identifikator for lovgivning “European Legal Identifier” (Se [ELI]).
Attributter
Sagshjemmel kan beskrives yderligere ved hjælp af attributten ParagrafHenvisning, der er defineret i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Datatype |
Regel for udfyldelse |
---|---|---|---|
ParagrafHenvisning |
Præcisering af det konkrete stykke i en retskilde, hvor hjemlen er givet. Kan anvendes til at supplere relationen til en retskilde med angivelse af det præcise stykke i retskilden, som hjemlen er givet i, fx Lov om Social Service, § 42. Den pågældende retskilde er beskrevet med relationen Hjemmel til Retskilde og beskrivelsen her kan suppleres med: [Kapitel] [Paragraf] [Stk.] [Pkt.] [Litra] Kapitelhenvisning anvendes, hvis der henvises til et helt kapitel, ellers henvises til den/de specifikke paragraffer. Paragrafhenvisning skrives med §. Henvises der til flere paragraffer skrives §§ (fx §§ 2 – 4). |
Tekst |
Ikke obligatorisk |
Relationer
Relationer fra Sagshjemmel er beskrevet i tabellen nedenfor:
Betegnelse |
Beskrivelse |
Objekttype |
Kardinalitet |
---|---|---|---|
Sagshjemmel |
Henvisning til retskilde som sagens hjemmel er givet i. Relation til Retskilde skal ske ved angivelse af retskildens HTTP URI baseret på ELI (se [ELI]). Et eksempel på ELI: Retskilde: Bekendtgørelse af Lov om Social Service, LBK nr. 988, 2017 ELI: /eli/lta/2017/988 “/eli” angiver, at det er en ELI, “/lta” angiver at retskilden er publiceret i Lovtidende A, “/2017” er publiceringsår 2017 og “988” er løbenummeret 988 for den pågældende retskilde. Den konkrete HTTP URI konstrueres ved kobling med domænet for danske retskilder retsinformation.dk og bliver dermed: |
Retskilde |
0..n |
OffentlighedUndtagetHjemmel |
Henvisning til retskilde, der anvendes som grundlag for beslutning om undtagelse fra offentligheden. Relation til Retskilde skal ske ved angivelse af retskildens HTTP URI baseret på ELI (se [ELI]). Et eksempel på ELI: Retskilde: Bekendtgørelse af Lov om Social Service, LBK nr. 988, 2017 ELI: /eli/lta/2017/988 “/eli” angiver, at det er en ELI, “/lta” angiver at retskilden er publiceret i Lovtidende A, “/2017” er publiceringsår 2017 og “988” er løbenummeret 988 for den pågældende retskilde. Den konkrete HTTP URI konstrueres ved kobling med domænet for danske retskilder retsinformation.dk og bliver dermed: |
Retskilde |
0..n |
Journalpost
JournalPost anvendes til at berige tilknytninger mellem sagen og dokumenter med yderligere information. På denne måde kan dokumenter indeholdes i flere sager og hver gang på nye betingelser.
Eksempelvis kan et dokument vedlægges én sag, men tilakteres en anden sag. Eller et dokument kan vedlægges én dagsordenssag med én dokumenttitel og en byggesag med en anden dokumenttitel.
JournalNotat er en løbende log over de sagsbehandlingsskridt, der foretages i en sag.
Attributter
Relationen Journalpost har følgende attributListe
Betegnelse |
Beskrivelse |
Datatype |
Regel for udfyldelse |
---|---|---|---|
JournalpostTitel |
Angiver en titel på journalposten (fx ved behov for alternativ titel på dokumentet i forbindelse med den konkrete sag). |
Tekst |
Ikke obligatorisk. Hvis attributten ikke er udfyldt gælder titlen på dokumentet. |
JournalpostTid |
Tidsstempel for journalpostens tilknytning til sagen. Bruges til at kunne danne en kronologisk ordnet rækkefølge på sagens journalposter. |
DateTime |
Obligatorisk |
OffentlighedUndtagetAlternativTitel |
Alternativ titel for dokumentet. Denne titel angives kun, hvis sagen er undtaget fra offentligheden. I denne attribut skrives den dokumenttitel, som offentligheden ikke må se, hvorimod den titel, som offentligheden godt må se skrives i attributten ’Dokumenttitel’. |
Tekst |
Hvis relationen ’OffentlighedUndtagetHjemmel’ er udfyldt, er denne attribut obligatorisk – ellers må den ikke udfyldes. |
Relationer
En Journalpost kan have én af nedenstående to relationer til et dokument eller en relation til et JournalNotat. En Journalpost indeholder dermed et dokument eller et journalnotat. Da sager indeholder flere journalposter, indeholder sager igennem journalposter også flere dokumenter og/eller journalnotater.
Betegnelse |
Beskrivelse |
Objekttype |
Kardinalitet |
---|---|---|---|
Vedlagt |
Tilknytning til sagen med mulighed for at fjerne tilknytningen. Relation som anvendes ved tilknytning af dokumenter, hvor der skal være mulighed for at fjerne tilknytningen til sagen. Det kan fx være skabeloner eller tjeklister, som anvendes i forbindelse med sagsbehandlingen. |
Dokument |
0..1 |
Tilakteret |
Tilknytning til sagen uden mulighed for at fjerne tilknytning til sagen. Dokumenter som tilknyttes sagen, og ikke skal have mulighed for at fjerne tilknytning igen, tilknyttes med relationen Tilakteret. |
Dokument |
0..1 |
Tilknyttet- JournalNotat |
JournalNotat tilknyttet sagen. JournalNotat udgør, sammen med sagens øvrige tilakterede dokumenter i Journalpost, sagens journal. |
JournalNotat |
0..1 |
JournalNotat
JournalNotat anvendes til den løbende log over de sagsbehandlingsskridt, der foretages i en sag, og som ikke fremgår af sagens øvrige dokumenter eller oplysninger.
Attributter
Hjælpeobjektet JournalNotat har følgende attributter:
Betegnelse |
Beskrivelse |
Datatype |
Regel for udfyldelse |
---|---|---|---|
JournalNotatTitel |
Angiver en titel på journalnotatet. |
Tekst |
Ikke obligatorisk |
JournalNotatTekst |
Angiver det tekstmæssige indhold i journalnotatet. |
Tekst |
Obligatorisk hvis JournalNotatTitel er udfyldt |
Referencer i sagsmodellen
Nedenfor er angivet, hvilke referencer, der er anvendt i Sagsmodellen:
Reference |
Titel |
Link til reference |
---|---|---|
[SAGANV] |
”Anvendelse af Sagsobjektet i Sags- og Dokumentindekset”, KOMBIT 20.12.2016 |
https://digitaliseringskataloget.dk/l%C3%B8sninger/sags_og_dokumentindeks |
[ORG] | Specifikation af model for Organisation (Organisationsmodellen) | [indsættes når model er klar] |
[DOK] | Specifikation af model for Dokument (Dokumentmodellen) | [indsættes når model er klar] |
[GODPRAKSIS] |
”God praksis for informationsmodellering, OIO-datastandardisering i sektorerne”, It- og Telestyrelsen 2007 |
https://bibliotek.dk/linkme.php?rec.id=870970-basis%3A26939844 |
[GRUNDDATA] |
Modelregel 6.1 ”ALLE MODELENTITETER SKAL MODELLERES MED PERSISTENT, UNIK IDENTIFIKATION”, Grunddatabestyrelsen 3.02.2014 |
http://arkitekturguiden.digitaliser.dk/node/828 (senest tilgået 17.12.2017) |
[KLAS] | Specifikation af model for Klassifikation (Klassifikationsmodellen) | [indsættes når model er klar] |
[HTTPURI] |
”Udkast til Retningslinjer for stabile http URIer”, Styregruppen for Data og Arkitektur |
https://arkitektur.digst.dk/node/588 (senest tilgået 18.01.2018) |
[ELI] |
“Easier access to European legislation with ELI” |
https://www.retsinformation.dk/eli (senest tilgået 16.12.2017) |
[OLDSAG] |
“Specifikation af serviceinterface for Sag, version 1.2”, Styregruppen for OIO Sag og Dokument, 2013 |
https://www.digitaliser.dk/resource/1567587 (senest tilgået 15.01.2018) |
[RFC4122] |
"A Universally Unique IDentifier (UUID) URN Namespace" |
https://tools.ietf.org/html/rfc4122 (senest tilgået 17.12.2017) |
[XSD] |
“W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes” |
https://www.w3.org/TR/xmlschema11-2/ (senest tilgået 16.12.2017) |
Bilag 2: Retteblad til version 2.0
Afsnit i Sag 1.2 |
Nye/ændrede afsnit i Sagsmodellen |
Ændring |
Beskrivelse af ændringer |
---|---|---|---|
Forord |
|
Udgået |
Afsnittet er erstattet af nyt afsnit om formål og indledning, som afspejler ændringen fra specifikation af serviceinterface til specifikation af en informationsmodel |
Formål med forretningsservice for Sag |
|
Udgået |
Afsnittet er erstattet af nyt afsnit om formål |
Formål med Serviceinterface Sag |
|
Udgået |
Afsnittet er erstattet af nyt afsnit om formål |
|
Indledning |
Nyt |
Afsnittet afspejler ændringen fra specifikation af serviceinterface til specifikation af en informationsmodel |
|
Formål med Sagsmodellen |
Nyt |
Afsnittet afspejler ændringen fra specifikation af serviceinterface til specifikation af en informationsmodel |
|
Ændringer siden version 1.2 |
Nyt |
Afsnittet beskriver de overordnede ændringer |
|
Egenskaber for Sagsmodellen |
Nyt |
Afsnittet beskriver de modelmæssige egenskaber ved Sagsmodellen. |
|
Diagrammer |
Nyt |
Afsnittet beskriver, hvordan diagrammer er anvendt i beskrivelsen af Sagsmodellen |
|
Forretningsobjekter |
Nyt |
Afsnittet beskriver, hvordan forretningsobjekter er beskrevet i modellen. |
|
Universelt unik, persistent identifikation af forretningsobjekter |
Nyt |
Afsnittet anviser retningslinjerne for unik identifikation af forretningsobjekterne i modellen. |
|
Attributter |
Nyt |
Afsnittet beskriver, hvordan attributter er beskrevet i modellen |
|
Datatyper |
Nyt |
Afsnittet præciserer, hvilke datatyper der er anvendt i modellen |
|
Mulighed for tilpasning af udfaldsrum |
Nyt |
Afsnittet præciserer, hvordan udfaldsrum i modellen kan tilpasses |
|
Relationer |
Nyt |
Afsnittet beskriver, hvordan relationer er beskrevet i modellen |
Begreber |
|
Udgået |
Udgået som selvstændigt afsnit. De enkelte begreber er alle defineret som en del af modellen. |
Beskrivelse af opbygning og struktur |
|
Udgået |
Erstattet af nyt afsnit om diagram for Sagsmodellen. |
Versionering |
|
Udgået |
afsnittet er udgået - det henviste til at sag styres bitemporalt. I stedet er indsat forretningsnære attributter med tidsangivelse |
|
Sagsmodellen |
Nyt |
Nyt afsnit som afspejler ændringen fra specifikation af serviceinterface til specifikation af en informationsmodel. |
|
Sagsbegrebet |
Nyt |
Afsnittet beskriver forståelsen af begrebet Sag i Sagsmodellen. |
Diagram for Sagsmodellen | Nyt |
Afsnittet illustrerer og beskriver et diagram for Sagsmodellen. I forhold til diagrammet, som er vist i figur 1 på side 12 i version 1.2, er det nye diagram mere detaljeret og viser modellens relationer og kardinalitet. |
|
Forretningsobjekter i Sagsmodellen |
Nyt |
Afsnittet forklarer, hvordan forskellige objekttyper er repræsenteret i modellen. |
|
Centrale forretningsobjekter |
Nyt |
Afsnittet beskriver, hvordan centrale forretningsobjekter indgår i Sagsmodellen. |
|
Eksternt definerede forretningsobjekter |
Nyt |
Afsnittet beskriver, hvordan eksternt definerede forretningsobjekter indgår i Sagsmodellen. |
|
Hjælpeobjekter | Nyt |
Afsnittet beskriver, hvordan hjælpeobjekter indgår i Sagsmodellen. |
|
Sag | Nyt |
Afsnittet beskriver Sagsobjektet |
|
Attributter |
Revideret |
Definitioner og beskrivelser for de enkelte attributter er revideret. I tabellen er titlen på kolonnen "værdisæt" ændret til "Datatype. De anvendte datatyper referer til beskrivelsen af disse i afsnittet om anvendte datatyper. I tabellen er titlen på kolonnen "obligatorisk" ændret til "Regel for udfyldelse", som giver mulighed for en mere detaljeret angivelse af reglerne for attributtens udfyldelse end den hidtidige ja/nej for obligatorisk. I forhold til attributlisten i tabel 3, side 13 i version 1.2 er der følgende ændringer:
Følgende attributter er tilføjet Sagsmodellen:
|
|
Relationer |
Metoden fra version 1.2 i forhold til relationer med objekttype og relationsrolle er i Sagsmodellen fravalgt som fremgangsmåde, da den er for implementeringsnær. I stedet er kun medtaget de konkrete relationer.De konkrete ændringer i relationer i Sagsmodellen er beskrevet i de afsnit, hvor de af hensyn til overskuelighed er grupperet efter, hvilken ekstern model relationen peger på. |
||
Relationer til Sag |
Nyt |
I forhold til tabel 10, side 22 i afsnit om Sagsrelation i version 1.2 er der følgende ændringer i Sagsmodellen:
|
|
Relationer til Klassifikation |
Nyt |
I forhold til tabel 7, side 18 i afsnit om Sagsklasse i version 1.2 er der følgende ændringer i Sagsmodellen: Primærklasse: ændret til "Emneklasse", beskrivelse ændret Opgaveklasse: udgået Handlingsklasse: Ingen ændring Kontoklasse: Ingen ændring Sikkerhedsklasse: beskrivelse ændret Følsomhedsklasse: beskrivelse ændret Indsatsklasse: udgået Ydelsesklasse: udgået |
|
Relationer til Organisation |
Nyt |
I forhold til tabel 8, side 20 i afsnit om Sagsaktør i version 1.2 er der følgende ændringer i Sagsmodellen:
Følgende relationer til Organisation er tilføjet i Sagsmodellen:
|
|
Sagsarkiv |
Udgået |
udgået da specifikationen for arkivstruktur er udgået. |
|
Sagsklasse |
Udgået |
udgået som abstrakt klasse - i stedet er de konkrete relation til Klasse i Klassifikationsmodellen diagrammeret og uddybet i afsnittet om "relationer til Klasse". |
|
Sagsaktør |
Udgået |
udgået som abstrakt klasse - i stedet er de konkrete relation til de tilladte objekter i Organisationsmodellen diagrammeret og uddybet i afsnittet om "Relationer til Organisation". |
|
sagspart |
Revideret |
indskærpet at parter er personer eller virksomheder - organisationer som part er i rolle som virksomhed
|
|
Attributter |
Nyt |
Tilføjet attributten "Partsrolle" |
|
Relationer til Part |
Nyt |
I forhold til relationer til Sagspart, tabel 9, side 21 i version 1.2 er der følgende ændringer i Sagsmodellen:
|
|
Sagshjemmel |
Nyt |
Afsnit som beskriver sagens relation til hjemmel i form af en eller flere retskilder. |
|
Attributter |
Nyt |
Attributten "ParagrafHenvisning" tilføjet. |
|
Relationer |
Nyt |
Relationen "Sagshjemmel" tilføjet. |
|
sagsrelation |
Udgået |
sagsrelation er udgået som abstrakt klasse - i stedet er beskrevet de tilladte relationer til andre sager i afsnittet om "Relationer til aSag". |
|
Sagsgenstand |
Udgået |
Sagsgenstand kan ikke defineres for den generelle beskrivelse af Sagsobjektet, da det potentielt dækker nærmest alle entiteter en Sag kan omhandle. Derfor skal sagsgenstanden modelleres i specialiseringen af sagen. Fx for en Ejendomssag specialiseres sag og tilføjes relation til Ejendom. |
|
Journalpost |
Revideret |
Revideret |
|
Attributter |
Nyt |
I forhold til attributlisten i tabel 12, side 24 i version 1.2 er der følgende ændringer:
Tilføjet attribut:
|
|
Relationer |
Nyt |
Relationen "TilknyttetJournalNotat" tilføjet - peger på hjælpeobjektet JournalNotat |
|
JournalNotat |
Nyt |
Nyt hjælpeobjekt til beskrivelse af journalnotat |
|
Attributter |
Nyt |
JournalNotat har følgende attributter:
|
|
Operationer |
Udgået |
||
Referencer |
Nyt |
Nyt afsnit med referencer. Anvendes fx hvor der i modellerne er inddraget modelelementer fra andre modeller, fx retskilde hvor der henvises til retsinfo's ELIidentifikator - men også referencer mellem specifikationerne |
|
Bilag 1 eksempler |
Udgået |
||
Bilag 2 retteblad |
Udgået |
Erstattet af nyt retteblad. |
|
Bilag 1 Retteblad for Sagsmodellen |
Nyt |
Retteblad for den aktuelle version af Sagsmodellen. |