Fællesoffentlig beskedmodel version 1.0
|
|
- Inger Ingelise Søndergaard
- 8 år siden
- Visninger:
Transkript
1 Side: 1 Fællesoffentlig beskedmodel version 1.0 Dokumentet indeholder dels en informationsmodel for hændelsesbeskeden og dens miljø, dels en generisk datamodel for hændelsesbeskeden, som kan danne en fælles basis for specifikke implementeringer af beskedfordeling. Besked - Informationsmodel Informationsmodellen viser det overordnede samspil mellem hændelsesbeskeden og dens miljø, som består af objektregistrering i registersystemer og abonnementsevaluering i beskedfordeleren
2 Side: 2 Besked - Datamodel Her beskrives den generiske/generelle besked, uden den omsluttende arkitektur af abonnement og dataprocesser. Diagrammet har eksempler på lokaludvidelser - alle klasser kan principielt udvides i domænespecifikke profiler af formatet
3 Side: 3 Forretningsobjekt Forretningsobjekter er de "ting" vi arbejder med i den offentlige sektor Forretningsobjekterne er det, processerne arbejder med og dem, der bærer de informationer vi har om disse forretningsobjekter (Personer, Virksomheder, Sager, Dokumenter etc.) er (0..*) Forretningsobjekt Objekttype (1) Klasse Typen af det informationsobjekt, som processen har behandlet. Objekttyperne kan være standardiserede i klassifikation Person, Virksomhed, Sag etc. (1) Forretningsobjekt Objektrelation (0..*) Forretningsobjekt (0..*) Forretningsobjekt Objektansvarlig (1) Aktør (1) Forretningsobjekt Objektrelation (0..*) Forretningsobjekt (1..*) Registrering Objektændring (1) Forretningsobjekt Relation til andre forretningsobjekter, som det objekt, beskeden omhandler, er relateret til. En reference til den aktør, som har overordnet dataansvar for dataobjektet - for eksempel et grunddataregister (person, adresse) eller en kommune (byggesag, institutionsplads) Relation til andre forretningsobjekter, som det objekt, beskeden omhandler, er relateret til. Et objekt kan være ændret ved en eller flere objektregistreringer Registrering
4 Side: 4 Én registrering på et forretningsobjekt. Et forretningsobjekt kan oprettes og derefter ændres mange gange. For hver gang opstår en "registrering", som beskriver en række forhold omkring denne ændring. Eksempelvis hvem der har ændret på det, hvornår det er sket, i hvilken sammenhæng det er sket etc. er (0..*) Registrering Objekthandling (1) Klasse En reference til et objekt af typen Klasse der holder betegnelsen på den objektnære handling, der er udført. Objekthandlingen defineres som en handling i en forretningsmæssig proces på det forretningsobjekt som beskeden drejer sig om. Den objektansvarlige (myndighed, domænekomite el. lign.) bør entydigt definere dette navn. (0..*) Registrering Opgaveemne (1) Klasse Reference til et objekt af typen klasse der indeholder emner. Eksempler på emneklassifikationer er KLE og FORM. (0..*) Registrering Registreringsansvarlig (1) Aktør (1..*) Registrering Objektændring (1) Forretningsobjekt (0..*) Hændelsesbesked Omhandler (0..*) Registrering En reference til den aktør (organisation eller organisatorisk enhed), som er ansvarlig for informationen i den pågældende registrering. Et objekt kan være ændret ved en eller flere objektregistreringer En besked omhandler ændring i eller oprettelse af et (eller flere) forretningsobjekt(er) (Registrering(er)).
5 Side: 5 Aktør Den medarbejder, organisatorisk enhed eller det it-system, der udfører en given aktivitet eller den person, som har ansvaret for sagen. Aktørerne i en organisation er dem, organisationen er sammensat af. Aktørerne kan være af typerne: Organisation, Organisatorisk enhed, Organisatorisk funktion, it-system, Bruger, Interessefællesskab er (1) Aktør Er abonnent på (0..*) Abonnement (0..*) Leverancerute Fordelingssystem (1) Aktør (0..*) Registrering Registreringsansvarlig (1) Aktør (0..*) Forretningsobjekt Objektansvarlig (1) Aktør (0..*) Leveranceinformation Kildesystem (1) Aktør Det er en aktør i en Organisation, som har oprettet et abonnement. Denne aktør er således abonnent. Hvilket it system (aktør af typen it-system), har distribueret beskeden? (Beskedfordeler) En reference til den aktør (organisation eller organisatorisk enhed), som er ansvarlig for informationen i den pågældende registrering. En reference til den aktør, som har overordnet dataansvar for dataobjektet - for eksempel et grunddataregister (person, adresse) eller en kommune (byggesag, institutionsplads) Hvilket it system (aktør af typen it-system), kommer en besked fra. Klasse Klasse indeholder de konkrete klasser (entries), som udgør et klassifikationssystem. Disse klasser kan evt. være ordnet hierarkisk og altså have over- og underemner. Klasser kan endvidere også have sideordnede klasser (henvisninger), også kaldet relaterede klasser.
6 Side: 6 er (0..*) Forretningsobjekt Objekttype (1) Klasse Typen af det informationsobjekt, som processen har behandlet. Objekttyperne kan være standardiserede i klassifikation Person, Virksomhed, Sag etc. (0..*) Hændelsesbesked Sikkerhedsklassificering (1) Klasse (0..*) Registrering Objekthandling (1) Klasse En besked har en sikkerhedsklassificiering, som anvendes til at afgøre om abonnenten må modtage beskeden. En reference til et objekt af typen Klasse der holder betegnelsen på den objektnære handling, der er udført. Objekthandlingen defineres som en handling i en forretningsmæssig proces på det forretningsobjekt som beskeden drejer sig om. Den objektansvarlige (myndighed, domænekomite el. lign.) bør entydigt definere dette navn. (0..*) Registrering Opgaveemne (1) Klasse Reference til et objekt af typen klasse der indeholder emner. Eksempler på emneklassifikationer er KLE og FORM. Abonnement Abonnement på modtagelse af beskeder om ændringer i forretningsobjekter. Abonnenterne anvendes af beskedfordeleren til at afgøre om abonnenten skal have en besked eller ej. Abonnementet består dels af et abonnementsudtryk, dels af en specifikation af leveringsmåden for beskeder (push/pull)
7 Side: 7 er (1..*) Abonnement Har abonnementsudtryk (1) Abonnementsudtryk (1) Aktør Er abonnent på (0..*) Abonnement (1) Leverancerute Leveret i henhold til (0..*) Abonnement Et abonnement indeholder et eller flere abonnementsudtryk. Det er en aktør i en Organisation, som har oprettet et abonnement. Denne aktør er således abonnent. Specifikation af, hvilket abonnement der har gjort at netop denne hændelsesbesked er leveret. Hver instans af Leverancerute indeholder reference til det abonnement, der foranledigede, at hændelsesbeskeden blev sendt videre Abonnementsudtryk Abonnementsudtrykket anvendes til at udtrykke de hændelsesbeskeder, man er interesseret i at modtage. Abonnementet kan sammenlignes med et filter eller en query på de beskeder, der er afsendt. Abonnementsudtrykket afprøves mod hændelsesbeskedens filtreringsdata. De abonnementer, der matcher filteringsdata, får beskeden. Abonnementsudtrykket skal indeholde de samme informationer som beskedkuverten, hvorved de direkte kan sammenlignes med indholdet af den konkrete besked og dermed optræde som filter. er (1..*) Abonnement Har abonnementsudtryk (1) Abonnementsudtryk Et abonnement indeholder et eller flere abonnementsudtryk.
8 Side: 8 Hændelsesbesked Besked om en forretningshændelse. er (0..*) Hændelsesbesked Sikkerhedsklassificering (1) Klasse (0..*) Hændelsesbesked Omhandler (0..*) Registrering (0..*) Beskeddata (1) Hændelsesbesked (1) Beskedkuvert (1) Hændelsesbesked En besked har en sikkerhedsklassificiering, som anvendes til at afgøre om abonnenten må modtage beskeden. En besked omhandler ændring i eller oprettelse af et (eller flere) forretningsobjekt(er) (Registrering(er)). Beskeddata kan indgå i Hændelsesbeskeden med det formål at transportere data sammen med beskeden Beskedkuverten indgår i Hændelsesbesked med det formål, at opbevare eksternt rettet filtreringsinformation, som beskedfordeleren kan anvende til abonnementsfiltrering Attribut Type beskedid GUID Beskedens unikke identifikation Tilføjes af Beskedfordeler, hvis den ikke allerede er sat af afsendersystemet beskedversion literal Versionsnummer for beskedmodellen - Modellen kan eventuelt sub-versioneres; så får hvert element sit eget versions-id Beskedkuvert Beskedkuverten indeholder informationer til udvælgelse og levering af beskeder. Beskedfordelere kan udelukkende læse indholdet af beskedkuverten og anvender dette indhold til at
9 Side: 9 udvælge de beskeder, som matcher de opsatte abonnementer. er (1) Beskedkuvert (1) Hændelsesbesked Beskedkuverten indgår i Hændelsesbesked med det formål, at opbevare eksternt rettet filtreringsinformation, som beskedfordeleren kan anvende til abonnementsfiltrering (0..1) Modtagerhandling (1) Beskedkuvert (1) Leveranceinformation (1) Beskedkuvert (1) Filtreringsdata (1) Beskedkuvert Beskedens Leveranceinformationer indgår i beskedkuverten - disse danner baggrund for håndtering og logning Filtreringsdata indgår i Beskedkuvert for at kunne anvendes til abonnementsfiltrering og til beskedevaluering Attribut Type gyldigfra datetime Starttidspunkt for beskedens gyldighed - fortolkning og handling kan være domænespecifik gyldigtil datetime Sluttidspunkt for beskedens gyldighed - fortolkning og handling kan være domænespecifik Modtagerhandling Modtagerhandling samler beskedafsenderens angivelser af, hvilke procestrin, der skal initieres hos beskedmodtageren er (0..1) Modtagerhandling
10 Side: 10 (1) Beskedkuvert Attribut Type handling Klassifikation Afsenderens krav til modtagerens handling, når indhodlet i bekeden er behandlet. Eksemple: "Kvittering", der betyder, at modtageren skal udsende en kvittering, når beskeden er færdigbehandlet responsmodtager Aktør Angivelse af den aktør, som sal modtage resultatet (fx en kvittering) af "handling" Beskeddata "Payload", som forsendes indlejret i beskeden. Ikke synligt for beskedfordeleren. Kan altså ikke bruges til abonnementsfiltrering. 0 til mange "bilag" kan medsendes pr besked (beskedfordelere kan sætte begrænsninger for beskedstørrelse). Hvert bilagsobjekt har en reference til et dataskema, som gør modtageren i stand til at håndtere bilaget. Mulig beholder for konfidentielle data Leveres af kildesystemet. er (0..*) Beskeddata (1) Hændelsesbesked Beskeddata kan indgå i Hændelsesbeskeden med det formål at transportere data sammen med beskeden Attribut Type dataskema Klassifikation Reference til information om bilaget, som skal gøre det muligt for modtageren at anvende dette - kan opbevares i Klassifikation objekt datasæt Bilaget som sådan - som indlejrede data Kan kun være udfyldt hvis objektreference er tom
11 Side: 11 objektreference objektid Reference til eksternt dataobjekt Kan kun være udfyldt hvis objekt er tom Rammer for objekters id fastsættes i de domæner, hvor objekterne hidrører Eksempel: objektid kan fx også være CPR/CVR dvs urn:dk:cpr:person: eller fx urn:dk:cvr:virksomhed: eller urn:uuid:6e8bc430-9c3a-11d c9a66 eller eller c9a66 Leveranceinformation Information vedrørende beskedens rute fra afsender til seneste handler. er (1) Leveranceinformation (1) Beskedkuvert (0..*) Leveranceinformation Kildesystem (1) Aktør (0..*) Leverancerute (1) Leveranceinformation (0..1) Lokaludvidelse kan have (1) Leveranceinformation Beskedens Leveranceinformationer indgår i beskedkuverten - disse danner baggrund for håndtering og logning Hvilket it system (aktør af typen it-system), kommer en besked fra. Ruteinformationen kan indgå i Leveranceinformation - med en instans for hver "handler" Beskedkuverten kan udvides med domænespecifikke egenskaber
12 Side: 12 Attribut Type transaktionsid GUID dannelsestidspunkt datetime Tidspunkt for beskedens dannelse (= afsendelsestidspunkt fra kildesystem). kildesystem Aktør Identifikation af kildesystemet, det system, som udsendte beskeden kildesystemipadresse ip-adresse IP-adressen på kildesystemet kildesystemakkreditiver CharacterStrin g Akkreditiver - for eksempel certifikat - som sikrer kildesystemets identitet NOTE: Type afklares sikkerhedsklassificering Klassifikation Feltet beskriver beskedens sikkerhedsklassificering. Beskedfordelerhandling kan være domænespecifik Leverancerute Metadata om hvert trin i beskedens rute. Multiplicitet er 0..* idet elementet er fraværende i den besked, som sendes fra kildesystemet til første beskedfordeler. Leveres af den aktuelt håndterende komponent er (0..*) Leverancerute (1) Leveranceinformation (0..*) Leverancerute Fordelingssystem (1) Aktør (1) Leverancerute Leveret i henhold til (0..*) Abonnement Ruteinformationen kan indgå i Leveranceinformation - med en instans for hver "handler" Hvilket it system (aktør af typen it-system), har distribueret beskeden? (Beskedfordeler) Specifikation af, hvilket abonnement der har gjort at netop denne hændelsesbesked er leveret. Hver instans af Leverancerute indeholder reference til det abonnement, der foranledigede, at hændelsesbeskeden blev sendt videre
13 Side: 13 (0..1) Lokaludvidelse kan have (1) Leverancerute Attribut Type fordelingssystem Organisation Identifikation af 'denne komponent' modtagelsestidspunkt datetime Tidspunkt for denne komponents modtagelse af beskeden leverancetidspunkt datetime Det tidspunkt hvor denne komponent har videreformidlet beskeden modtagetfrasystem Aktør Det system, som beskeden er modtaget fra. Det kan være kildesystemet eller en anden beskedfordeler erleveretihenholdtil AbonnementID Specifikation af det abonnement, som har specificeret denne videresendelse. Filtreringsdata Filtreringsdata indeholder de data som er nødvendige for at kunne dels evaluere beskeden i forhold til et abonnementsudtryk (i Beskedfordeleren), dels evaluere beskedens relevans hos Beskedmodtageren for derefter eventuelt at initiere en forretningsproces Data leveres af kildesystemet er (1) Filtreringsdata (1) Beskedkuvert (0..*) Relateret objekt indgår i (1) Filtreringsdata Filtreringsdata indgår i Beskedkuvert for at kunne anvendes til abonnementsfiltrering og til beskedevaluering Beskeden kan indeholde referencer til andre forretningsobjekter, som ikke er ændrede i forbindelse med beskedudsendelsen, men som kan have relevans for filtrering og fortolkning BEMÆRK - denne releation fremgår ikke af
14 Side: 14 informationsmodellen (0..*) Objektregistrering (1) Filtreringsdata Nul til mange Objektregistreringer kan indgå i Filtreringsdata for at kunne bruges til abonnementsfiltrering Attribut Type beskedtype Klassifikation Deskriptiv klassificering af beskeden - beskedtyper publiceres i en klassifikationskomponent og er tilgængelige for abonnementsopsætningen Beskedtypen kan eventuelt være en sammenstilling af værdierne for objekttype, objekthandling og opgaveemne beskedansvarligaktør Aktør Specifikation af den aktør som har ansvaret for forretningsobjektet, dvs ansvar for udsendelse af beskeden. For den fælleskommunale beskedfordeler er det altid en myndighed. Bruges til at understøtte persondataloven. Anvendelse ved fx udbetaling fra UDK. tilladtmodtager Aktør Angivelse af de aktører,som må modtage beskeden, idet den omhandler begivenheder inden for deres myndighedsområde. Skal være en organisationsaktør for den fælleskommunale beskedfordeler er det altid en myndighed. Bruges til at understøtte persondataloven. Anvendelse ved fx udbetaling fra UDK Blank svarer til alle tværgåendeproces Klassifikation Angivelse af den tværgåede proces - en arbejdsgang, som involverer en række aktører - der startede den interne proces, som forårsagede hændelsesbeskeden. Feltet er optionelt
15 Side: 15 Objektregistrering Objekter som er relevante for beskeden Der er behov for, at en besked kan omhandle mere end et objekt Ved at sætte multiplicitet til 0..* muliggøres, at beskeden kan udsendes uden at der er reference til et specifikt objekt (hvis det er besked om en forretningshændelse, som ikke afføder objektregistrering), samt at beskeden kan omhandle ethvert antal af objekter større end nul. Data udfyldes af kildesystemet er (0..*) Objektregistrering (1) Filtreringsdata Nul til mange Objektregistreringer kan indgå i Filtreringsdata for at kunne bruges til abonnementsfiltrering (0..1) Lokaludvidelse kan have (1) Objektregistrering Attribut Type objektregistrering GUID Reference til den relevante objektregistrering registreringsaktør Aktør Den aktør, om har foretaget registreringen registreringstidspunkt datetime Det tidspunkt hvor dataobjektet senest er blevet ændret/dannet. Hvis beskeden omhandler mere end et objekt er ikke alle nødvendigvis opdateret på beskedtidspunktet - dette er interessant filterinformation - giv mig besked hvis den nytilflyttede borger har ændret navn inden for seneste 17 måneder objektansvarligmyndighed Aktør Den myndighed, som har overordnet dataansvar for dataobjektet - for eksempel et grunddataregister (person, adresse) eller en kommune (byggesag, institutionsplads)
16 Side: 16 NOTE: Kunne det være objektansvarlig aktør? det gør modellen mere rummelig - fx en bank som kontoansvarlig objektid GUID Specifikation af det dataobjekt, som regeistreringen vedrører Rammer for objekters id fastsættes i de domæner, hvor objekterne hidrører Eksempel: objektid kan fx også være CPR/CVR dvs urn:dk:cpr:person: eller fx urn:dk:cvr:virksomhed: eller urn:uuid:6e8bc430-9c3a-11d c9a66 eller eller c9a66 objekttype Klassifikation Objektets art, svarende til Sag, Dokument, Part fra S&D samt ethvert klassenavn i Grunddatamodellen Værdien må referere til en Klassifikation eller en anden type modelserver objekthandling Klassifikation En forretningsmæssig handling foretaget på objektet i forbindelse med den proces/registrering, som affødte hændelsesbeskeden. Handlingen er typisk en intern proces - en arbejdsgang, som kun involverer beskedafsederen, og som kan være en del af en eller flere tværgående processer Eksempel: Ejerskifte, fx som del af en overordnet udstykningsproces opgaveemne CharacterStrin g Det forretningsemne/opgave i forbindelse med hvilken, objektet blev registreret. Værdien af feltet skal specificere klassifikationssystemet. Foreløbig skal strengen indeholde den
17 Side: 17 brugervendte nøgle (fx ) så den ikan indgå i tekstbaseret filtrering af opgaveemnerne Typen kan tilpasses til mere intelligent filtrering når implementeringerne er på plads, uden at xml-skemaet skal ændres. Eksempler: urn:dk:klassifikation:kle:brugervendtnøgle: ndtnøgle# Med tiden måske: urn:uuid:6e8bc430-9c3a-11d c9a c9a66 Relateret objekt Dataobjekter, som er relevante som filtreringsgrundlag i forhold til objektregistreringen er (0..*) Relateret objekt indgår i (1) Filtreringsdata Beskeden kan indeholde referencer til andre forretningsobjekter, som ikke er ændrede i forbindelse med beskedudsendelsen, men som kan have relevans for filtrering og fortolkning BEMÆRK - denne releation fremgår ikke af informationsmodellen Attribut Type objektid GUID Specifikation af det konkrete dataobjekt objekttype Klassifikation Objektets art, svarende til Sag, Dokument, Part fra S&D samt ethvert klassenavn i
18 Side: 18 Grunddatamodellen Værdien må referere til en Klassifikation eller en anden type modelserver Lokaludvidelse Her placeres profilers eventuelle udvidelser til formatet er (0..1) Lokaludvidelse kan have (1) Leveranceinformation Beskedkuverten kan udvides med domænespecifikke egenskaber Attribut Type beskedfordelersignatur XML Signature Attributten er ikke obligatorisk at udfylde. Attributten indeholder hvis udfyldt Beskedfordelers signatur af følgende attributter: Leveranceinformation.transaktionsID Leveranceinformation.kildesystem Leveranceinformation.kildesystemIPAdresse Leveranceinformation.kildesystemAkkrediti ver Signaturen overholder XML Signature forskrifterne Lokaludvidelse Her placeres profilers eventuelle udvidelser til formatet
19 Side: 19 er (0..1) Lokaludvidelse kan have (1) Leverancerute Attribut Type antalleveranceforsøg int Angiver antallet af gange, Beskedfordeler har forsøgt at levere beskeden til modtageren. Eksempel: Første gang, Beskedfordeler forsøger på at levere beskeden, har denne attribut værdien 1. Hvis Beskedfordeler ved forsøg på at levere beskeden første gang får en fejl fra modtagersystemet, vil Beskedfordeler den efterfølgende gang levere beskeden med værdien 2 for denne attribut. Hvis det andet forsøg fejler, leveres beskeden med værdien 3 i denne attribut (og så fremdeles). Lokaludvidelse Her placeres profilers eventuelle udvidelser til formatet er (0..1) Lokaludvidelse kan have (1) Objektregistrering Attribut Type
20 Side: 20 CRUD Klassifikation Den logiske operation (skabelse, læsning, opdatering eller passivering) som registreringen påførte dataobjektet Den skal dø afsendersystemsignatur XML Signature Attributten er ikke obligatorisk at udfylde. Attributten indeholder hvis udfyldt Afsendersystemets signatur af følgende: Leveranceinformation.sikkerhedsklassificeri ng Filtreringsdata.* Objektregistrering.* Relateret objekt.* Signaturen overholder XML Signature forskrifterne. status Klassifikation Angivelse af den status - se som registreringen har påført dataobjektet stedbestemmelse Geoobjekt Angivelse af et geografisk område, som objektregistreringen vedrører Besked - Datamodel Besked - Datamodel
21 Side: 21 Besked - Datamodel Besked - Informationsmodel Besked - Informationsmodel
Grunddatabeskedmodel version 1.0
Grunddatabesked Side: 1 Grunddatabeskedmodel version 1.0 Grunddata-besked version 1.0 Beskedformatet er det samme for både beskeder, som genereres af datafordeleren på basis af data-opdateringer fra registrene,
Læs mereUnderbilag 2O Beskedkuvert Version 2.0
Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...
Læs mere1 Objekt informationsmodel - Byggeblok
1 Objekt informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Objekt Modellen beskriver og viser hvordan Forretningsobjekt "Objekt" kan forstås. Modellen er generisk, og kan derfor bruges
Læs mereTeknikken bag Datafordeleren Distribution af data. Fællesoffentlig datadistribution
Teknikken bag Datafordeleren Distribution af data Fællesoffentlig datadistribution Styrelsen for Dataforsyning og Effektivisering 21. november 2017 Side 1 Indhold Datas vej fra register til anvendere Hændelser
Læs mere<navn på proces eller use case>
-- AKT 444548 -- BILAG 1 -- [ Bilag B1_Skabelon Integrationstabel ] -- Bilag B1 Integrationstabel Formålet med integrationstabellerne er at danne et samlet overblik over de tekniske integrationer, der
Læs mereIndeværende dokument er et bilag til rapporten MOX et forretningsmønster for fagsystemers udveksling af hændelser Version 0.76
MOX bilag Indeværende dokument er et bilag til rapporten MOX et forretningsmønster for fagsystemers udveksling af hændelser Version 0.76 Rapporten og bilaget udgør et foreløbigt udkast til rapportering
Læs mereUnderbilag 2Q Vilkår for integration til støttesystemet Klassifikation
Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan Anvendersystemer afsender og/eller modtager objekter til/fra
Læs mere0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.
Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012
Læs mere1 Klassifikation-version2.0
1 Klassifikation-version2.0 Formål med Klassifikationsmodellen Her specificeres Klassifikationsmodellen, som en informationsmodel for Klassifikationer. Klassifikationer (eller klassifikationssystemer)
Læs mereSNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser
SNITFLADER TIL INDEKSER Præsentation af de fælleskommunale støttesystemernes snitflader til indekser Introduktion Fokus At give et overblik over: Integration til indekserne Forudsætninger for integration
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.2.2
SF1460_C Aflever besked - version 2.2.2 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mere1 Tilstand informationsmodel - Byggeblok
1 Tilstand informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Tilstand : Overordnet model til at beskrive "tilstande". Modellen er generisk og kan bruges som skabelon på tværs af forretningsområder
Læs mereHændelser på dåtåfordeleren
Hændelser på dåtåfordeleren En kort introduktion til begreber og anvendelsesmuligheder SDFE version 1.0 24. oktober 2016 Indhold Indledning... 2 Overordnet arkitektur... 2 Hændelsesbegrebet... 3 Forretningsmæssige
Læs mereKlik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks
23. maj 2013 HHK/KMJ NOTAT Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk
Læs mereIntegration Generelle vilkår og forudsætninger Integrationsbeskrivelse - version 0.1
Integration Integrationsbeskrivelse - version 0.1 rnes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 201n-nn-nn xxx 0.1 Første version Referencer Ref Titel Kommentarer
Læs mereVilkår for brug af Støttesystemet Sags- og Dokumentindeks
Version 1.0 Vilkår for brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og
Læs mere1 ST Klassifikation Informationsmodel
..27 ST Klassifikation Informationsmodel. Facet En facet angiver en bestemt synsvinkel på klassificering af de objekter, som klassifikationssystemet udgør taxonomien for. Facetten grupper klasser i klassifikationssystemet.
Læs mereVilkår vedrørende brug af Støttesystemet Beskedfordeler
Vilkår vedrørende brug af Støttesystemet Beskedfordeler 1 Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer afsender og/eller modtager beskeder fra Støttesystemet Beskedfordeler,
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.4.0
SF1460_C Aflever besked - version 2.4.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereAnvendelse af dobbelthistorik i GD2
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:
Læs mere1 KlassifikationStruktur
..27 KlassifikationStruktur. KlassifikationStruktur Klassifikation er det abstrakte objekt som samler et klassifikationssystem. Klassifikation holder klassifikationssystemets metadata. Klassifikationssystemet
Læs mere1 Klassifikation Informationsmodel
23..27 Klassifikation Informationsmodel. Facet En facet angiver en bestemt synsvinkel på klassificering af de objekter, som klassifikationssystemet udgør taxonomien for. Facetten grupper klasser i klassifikationssystemet.
Læs mereIntroduktion til Klassifikation
Introduktion til Klassifikation 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Klassifikation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af
Læs mereSag og Dokument: Eksempel på brug af generelle egenskaber
Sag og Dokument: Eksempel på brug af generelle egenskaber Der er knyttet en række generelle egenskaber til de enkelte objekter som beskrevet i dokumentet Generelle egenskaber for serviceinterfaces på sags-
Læs mereIntroduktion til Støttesystem Organisation
Introduktion til Støttesystem Organisation 1. Om dokumentet Dette dokument formidler et overblik over Støttesystemet Organisation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse
Læs mereKrav til beskedfordeler, dannelse og abonnement
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Bilag 4 - Fælles arkitekturramme for GD1-GD2-GD7 Krav til beskedfordeler, dannelse og abonnement Version: 0.4 Status: udkast Oprettet: 2. juni 2014
Læs mereNotat om metadata om grunddata
Bilag 16 - Fælles arkitekturramme for GD1-GD2-GD7 Notat om metadata om grunddata 6. december 2013 SAR & PLACE Indledning Metadata data om data betegner ikke en entydig klasse af data. Anvendelsen af betegnelsen
Læs mereBaggrundsinformation
1. Begreber Baggrundsinformation Sags- og Dokumentindekset skal indeholde sags- og dokumentmetadata, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres
Læs mereTil kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer
UdbudsVejledning Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog,
Læs mere1. Services, egne (udgående)
1. Services, egne (udgående) Navn: navn på egen service, eksempelvis: BrugsenhedAjourfoer Formålet med servicen beskrives kort, eksempelvis: Formålet med servicen er at oprette en den Brugsenhed som beskriver
Læs mereBESKEDFORDELER -ET AF DE OTTE STØTTESYSTEMER. Version 2.0
BESKEDFORDELER -ET AF DE OTTE STØTTESYSTEMER Version 2.0 Støttesystemer er selvstændige it-løsninger, der sikrer, at kommunens fagløsninger kan fungere sammen og få adgang til relevante data. Et støttesystem
Læs mereFordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014
Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,
Læs mereKlik her for at angive tekst.
30. april 2013 Klik her for at angive tekst. NOTAT Klik her for at angive tekst. Bilag 16: Anvenderkrav til Støttesystemet Ydelsesindeks version 1.0 (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav
Læs mereSF1460_A Modtag besked Integrationsbeskrivelse - version 2.3.0
SF1460_A Modtag besked - version 2.3.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereDen fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering
Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Fundament Vision & Strategi Logik Rammearkitektur Fysik Udvikling/Implementering 2 10.6.2014 De 5 digitaliseringsmål
Læs mereScope dokument for Advisservice
18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.
Læs mereStøttesystemerne. Det er tid til
1 Det er tid til Støttesystemerne 2 Kombit Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, hvor bedre borgerservice med færre ressourcer er i centrum. Kommunernes mål er at bevare
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 NOTAT Anvenderkrav til Støttesystemet Klassifikation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk
Læs mere1 Begrebsmodel for Ydelsesindeks
1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående
Læs mere1 Indsats informationsmodel - Byggeblok
1 Indsats informationsmodel - Byggeblok Logisk Informationsmodel af Byggeblokken Indsats Modellen beskriver den helt overordnede model for enhver type af "Indsats" Modellen kan bruges som skabelon til
Læs mereVilkår vedrørende anvendelsen af Støttesystemet Organisation
Vilkår vedrørende anvendelsen af Støttesystemet Organisation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer afsender og/eller modtager beskeder fra Støttesystemet Organisation,
Læs mereBrugerdokumentation, Beskedfordeler Støttesystemer
Brugerdokumentation, Beskedfordeler Støttesystemer Side 1 af 52 Indholdsfortegnelse Historik... 5 1 Indledning... 6 1.1 Målgruppe for brugermanualen... 6 1.2 Hvad er beskedfordeleren?... 6 1.3 Forudsætninger
Læs mereKlik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks
30. april 2013 NOTAT Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks Indhold: 1. Indledning og vejledning... 3 2. Krav vedr. Systemets anvendelse af Støttesystemet
Læs mereIntroduktion til Støttesystemet Beskedfordeler
Introduktion til Støttesystemet 1. Om dokumentet Dette dokument formidler et overblik over brugen af den fælleskommunale. Formålet er at give læseren en forståelse af, de væsentligste begreber, forudsætninger
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
8..27 SortimentOverfør Kort beskrivelse: Denne service distribuerer ØiR Sortimenter til It-systeminstanser, der abonner på sortimentet på vegne af en myndighed. Servicen udstilles som integrationen SF_72
Læs mereIntegration SF1320_A - CPR - Hændelser Integrationsbeskrivelse - version 2.0.2
Integration Integrationsbeskrivelse - version 2.0.2 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-01-10 PBO 0.1 Første version kopieret fra gammel skabelon
Læs mereUnderbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Version 2.0
Underbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Version 20 Begrebsmodellen for Ydelsesindeks Begrebsmodellen med de centrale forretningsobjekter er illustreret i Figur Begrebsmodel og definition
Læs mereINTEGRATION TIL DEN FÆLLESKOMMUNALE ARKITEKTUR
INTEGRATION TIL DEN FÆLLESKOMMUNALE ARKITEKTUR Integrationsform (Serviceplatform [SP]) Gennemstilling Omstilling/redirect Orkestrering Replica/cache Transformation SFTP simpel SFTP med service kvittering
Læs mereST Sortiment Informationsmodel
.5.27 ST Sortiment Informationsmodel .5.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereBESKEDFORDELER OG FORDELINGSKOMPONENT. 26. februar 2019
BESKEDFORDELER OG FORDELINGSKOMPONENT 26. februar 2019 KOMBITs løsninger og fælleskommunal infrastruktur Kommunale fagområder Arbejdsmarked og erhverv Social og sundhed Børn og læring Mit sygefravær Miljø,
Læs mereBESKEDFORDELER OG BESKEDER. Den fælleskommunale Beskedfordeler
BESKEDFORDELER OG BESKEDER Den fælleskommunale Beskedfordeler KOMBITS MISSION ER AT SAMLE KOMMUNERNE OM FÆLLES IT- LØSNINGER, DER FREMMER EFFEKTIVITET OG KVALITET Dagens tekst Monopolbrud og Rammarkitektur
Læs mereBilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler
Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7 Etablering af datadistribution på den Fællesoffentlige Datafordeler Version: 0.8 Status: udkast Oprettet: 10.3.2014 Dato: 16. juni 2014 Dokument historie
Læs mereOm projektet afprøvning af MOX-konceptet
NOTAT Om projektet afprøvning af MOX-konceptet MOX konceptet skal afprøves i flere forskellige kommuner med flere forskellige leverandører. Afprøvningen skal gennemføres i løbet af efteråret 2012. Der
Læs mereSortiment Informationsmodel
2.9.27 Sortiment Informationsmodel 2.9.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
8.2.27 SortimentStruktur. SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis i en given
Læs mere1 Organisation-version2.0
1 Organisation-version2.0 Denne pakke indeholder en specifikation af en model for Organisation (Organisationsmodellen). Formålet med Organisationsmodellen er at tilbyde et fælles sprog for beskrivelse
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
2.9.27 SortimentStruktur. SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis i en given
Læs mereSortiment Informationsmodel
8.2.27 Sortiment Informationsmodel 8.2.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereReferencearkitektur for håndtering af hændelser - "Event-Driven Architecture"
Bilag 3 - Fælles arkitekturramme for GD1-GD2-GD7 Referencearkitektur for håndtering af hændelser - "Event-Driven Architecture" Denne version af referencearkitekturen er målrettet Grunddataprogrammet Version:
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
30. april 2013 NOTAT Bilag 12: Anvenderkrav til Støttesystemet Beskedfordeler (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334
Læs mereSag og dokument standarderne - Hvad og hvorfor
Sag og dokument standarderne - Hvad og hvorfor > Sag og dokument standarderne Hvad og hvorfor Dette dokument kan frit anvendes af alle. Citeres der fra dokumentet i andre publikationer til offentligheden,
Læs mere1 Indledning. 2 Den fællesoffentlige datafordeler. 1.1 Hvad er grunddata
1 Indledning Det er et mål i den fællesoffentlige digitaliseringsstrategi, at grunddata skal være et fælles forvaltningsgrundlag for den offentlige sektor, der vedligeholdes ét sted (i de respektive kilderegistre)
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
22.3.27 SortimentStruktur. DataStructure: SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis
Læs mereVejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer
Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder kommunerne i det
Læs mereBilag til vejledning i anvendelse af attentionformatet i Digital Post-løsningen. December 2017, version 0.9
Bilag til vejledning i anvendelse af attentionformatet i Digital Post-løsningen December 2017, version 0.9 Hvad kan du læse om? I denne vejledning kan du læse om hvilke retningslinjer, der gælder for den
Læs mere1 Begrebsmodel for Ydelsesindeks
1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående
Læs mere/marius hartmann Integrationskrav 2. Logningskrav 3. Konsekvenser for kommunen
/marius hartmann maha31@frederiksberg.dk 20141002 Ang./ Vilkår for integration til støttesystemet Sags- og Dokumentindeks version 1.3 Denne fælleshenvendelse, som dækker it-arkitekterne fra Ballerup, Odense,
Læs mereStøttesystemet Beskedfordeler. Beskedfordeler Et af de otte Støttesystemer
Støttesystemet 1 Et af de otte Støttesystemer 2 Kombit Støttesystemet Hvad er Støttesystemet Beskedefordeler? Abonnér på beskeder om forretningsmæssige hændelser Støttesystemet er det centrale beskedsystem,
Læs mereBitemporalitet på Datafordeleren
Bitemporalitet på Datafordeleren Denne side indeholder en anvenderrettet beskrivelse og dokumentation af grunddataprogrammets historikmodel ved anvendelse og implementering af bitemporalitet. Dokumentet
Læs mereFælles arkitekturramme for GD1-GD2-GD7
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Cover til Fælles arkitekturramme for GD1-GD2-GD7 Fælles arkitekturramme for GD1-GD2-GD7 - kravbilag til brug for GD1-GD2 s kravspecificering Version:
Læs merePå vej mod internationalt orienterede datastandarder
FDA2018 På vej mod internationalt orienterede datastandarder Dan Bjørneboe, KL Peter Bruhn Andersen, Digitaliseringsstyrelsen 1 OPDATERING OIO OIO-OPDATERING FDA 23. april 2018 DAGSORDEN/EMNER OIO OPDATERING
Læs mereModelafleveringsproces
Appendix - Informationsmodel og Datamodel Side: 1 Modelafleveringsproces Modelafleveringsproces Modelafleveringsproces Diagrammet beskriver de processer, der knytter sig til indlevering af en datamodel
Læs mereEjendomsdataprogrammet - Matriklen Løsningsarkitektur - Bilag A Servicebeskrivelser og integrationer
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen Løsningsarkitektur
Læs mere1 Dokument-version2.0
1 Dokument-version2.0 Formål med Dokumentmodellen Formålet med Dokumentmodellen er at gøre det lettere at udveksle oplysninger om dokumenter mellem to eller flere it-systemer, ved at skabe en fælles forståelse
Læs mereKOMBITS TILGANG TIL ARKITEKTUR ER ENKEL
KOMBITS TILGANG TIL ARKITEKTUR ER ENKEL KOMBIT s EA rammeværk KL Fundament Digitaliseringsstrategi Arkitekturmål Arkitekturprincipper Brug Måling, evaluering og opfølgning Undervisning og gå-hjem møder
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 Klik her for at angive tekst. NOTAT Bilag 14: Anvenderkrav til Støttesystemet Organisation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) kombit@kombit.dk CVR
Læs mereVersion 1.0. Vejledning til brug af Støttesystemet Organisation
Version 1.0 Vejledning til brug af Støttesystemet Organisation kombit@kombit.dk CVR 19 43 50 75 Side 1/6 1. Indledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT indkøb af
Læs mereOBJECT IDENTIFICERES OID PHMR
OBJECT IDENTIFICERES OID PHMR MedCom. Odense d. 27. feb. 2014 Thor Schliemann OID OG INTEROPERABILITET OID er et omdrejningspunktet for interoperabilitet I både teknisk og semantisk interoperabilitet er
Læs mereTypografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem
Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem 1 Indholdsfortegnelse A3.1 INTRODUKTION 3 A3.1.1 HENVISNINGER 3 A3.1.2 LÆSEVEJLEDNING 4 A3.1.2.1 SÅDAN
Læs mereStyregruppen for data og arkitektur. Reviewrapport for: Referencearkitektur for deling af data og dokumenter (RAD)
Styregruppen for data og arkitektur Reviewrapport for: data og dokumenter (RAD) Indhold Arkitekturreview (scopereview) af referencearkitektur for deling af data og dokumenter 2 Reviewgrundlag 2 Projektresume
Læs mereSTØTTESYSTEMET KLASSIFIKATION
STØTTESYSTEMET KLASSIFIKATION v/ Martin Bo Jensen 26. februar 2019 KOMBITs løsninger og fælleskommunal infrastruktur 2 Kommunale fagområder Arbejdsmarked og erhverv Social og sundhed Børn og læring Mit
Læs mereModelregler for grunddata Version 1.0.0
Grunddataprogrammet Modelregler for grunddata Version 1.0.0 1 Modelregler for Grunddata Version: 1.0.0 Status: Gældende Godkendt af Grunddatabestyrelsen d.3. februar 2014 2 Forord Modelreglerne er udarbejdet
Læs mereDEN FÆLLESKOMMUNALE RAMMEARKITEKTUR
DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR FDA2017 DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR - FRA VISION TIL PRAKSIS FDA 2017 Agenda Digitaliseringsstrategien og kommunernes udfordringer Rammearkitekturen som et fælles
Læs mereIntroduktion til Støttesystem Sags- og Dokumentindeks
Introduktion til Støttesystem Sags- og Dokumentindeks 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Sags- og Dokumentindeks i den fælleskommunale infrastruktur. Formålet er
Læs mereSAPA Kommunenetværk Øst & Vest. KMJ 28. august 2013, Værløse 29. August 2013, Middelfart
SAPA Kommunenetværk Øst & Vest KMJ 28. august 2013, Værløse 29. August 2013, Middelfart P R O J E K T S T A T U S 1. Kravspecifikation A. Kommuner B. Leverandører 2. Faglige afklaringer i workshops 3.
Læs mereUnderbilag 2M Begrebs- og informationsmodel for Ydelsesindeks
Underbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Revisionshistorik Dato Kommentar Ansvarlig 206-09-29 Oprettet revisionshistorik MSG 206-09-29 Rollen til Bevillingsaktør er ændret fra Ansvarlig
Læs mereMøde med leverandører om vejledning til anvendelse af kommende fælleskommunale støttesystemer. KL-huset, tirsdag d. 4. juni 2013
Møde med leverandører om vejledning til anvendelse af kommende fælleskommunale støttesystemer KL-huset, tirsdag d. 4. juni 2013 Agenda 1.Mødets formål 2.Der er forskel på leverandører 3.Fælleskommunale
Læs mereSpecifikation af Model for Klassifikation Version 2.0
1 Specifikation af Model for Klassifikation Version 2.0 > Specifikation af Model for Klassifikation Version 2.0 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer
Læs mereBilag 1: Arkitekturrapport, EDS Hjælpemidler
Bilag 1: Arkitekturrapport, EDS Hjælpemidler (Bilag til dagsordenspunkt 2, Arkitekturrapporter fra Effektiv Digital Selvbetjening) Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug
Læs mereIntroduktion til Støttesystem Ydelsesindeks
Introduktion til Støttesystem 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af hvilke komponenter,
Læs mereIndholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase
Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...
Læs mereVilkår for Dialogintegration
Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer
Læs mere6. Status på arbejdet med fælles infrastruktur (fast punkt)
6. Status på arbejdet med fælles infrastruktur (fast punkt) Status på RA STS projektet (Michael Strand) Operationelle erfaringer (Peter Thrane / Michael Strand) Serviceplatformen og datafordeleren (Michael
Læs mereSPOR 5: BESKEDFORDELER OG FORDELINGSKOMPONENT
SPOR 5: BESKEDFORDELER OG FORDELINGSKOMPONENT v. Jens Jørn Nielsen Data- og infrastrukturdage 16. og 19. september 2019 Serviceejer for dataområder Beskedfordeler Fordelingskomponent Personskat eindkomst
Læs mereHøringsnotat - specifikation af serviceinterface for SAG version 1 2
N OTAT Høringsnotat - specifikation af serviceinterface for SAG version 1 2 Specifikation af serviceinterface for SAG Version 1.2 (Sag-standard) Den fællesoffentlige styregruppe for Sag og Dokument sendte
Læs mereVejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer
3. september 2013 Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder
Læs mereSAPA KRAVSPECIFIKATION v. 0.8. Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL
SAPA KRAVSPECIFIKATION v. 0.8 Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL Sags- og partsoverblikket Vise adresser der har adressebeskyttelse Adressen
Læs mereDKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME
DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.
Læs mereSTS ORGANISATION. 26. februar 2019
STS ORGANISATION 26. februar 2019 Indhold Baggrund og ophæng til rammearkitekturen Hvordan fungerer Organisation? Anvisninger til anvendelse af Organisation Guide til udlæsning af Organisation Dokumentation
Læs mereSpecifikation af serviceinterface for organisation. Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13.
Specifikation af serviceinterface for organisation Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13. november 2009 Specifikation af forretningsservice for Organisation Denne
Læs mere