Fællesoffentlig referencearkitektur for deling af data og dokumenter
Version 1.0, maj 2018
2
Fællesoffentlig referencearkitektur for deling af data og dokumenter
Fælles, udvalgte mønstre for videregivelse af data
Version 1.0, maj 2018. Godkendt af Styregruppe for Data og Arkitektur.
3
Forord 4
Resume 5
Executive summary 6
1 Introduktion 7
1.1 Formål, anvendelse og målgruppe 7
1.2 Scope 7
1.3 Centrale begreber 8
1.4 Tilblivelse og governance 9
1.5 Anvendt metode, notation og signaturforklaring 9
1.6 Relation til rammearkitektur og andre referencearkitekturer 10
1.7 Læsevejledning 10
2 Strategi 11
2.1 Temaer 11
2.2 Strategiske principper 12
2.3 Vision 13
2.4 Værdiskabelse 13
2.5 Juridiske rammer 14
2.6 Sikkerhed 15
2.7 Fællesoffentlige arkitekturprincipper og -regler 16
3 Forretningsarkitektur 18
3.1 Forretningsmæssig kontekst for videregivelse af data 18
3.2 Om data og dokumenter 19
3.3 Forretningsfunktionen videregivelse 20
3.4 Forretningsroller og aktører 21
3.5 Tværgående processer 21
3.6 Forretningsobjekter og begreber 27
4 Teknisk arkitektur 29
4.1 Nødvendige applikationsservices 30
4.2 Implementering af videregivelse på forespørgsel 32
4.3 Implementering af videregivelse ved meddelelse 37
4.4 Understøttende applikationsservices 40
4.5 Områder for standardisering 41
5 Perspektivering 45
6 Bilag 47
6.1 Bilag A: Tjekliste for anvendelse af referencearkitekturen 47
6.2 Bilag B: Ord- og begrebsliste 49
6.3 Bilag C: Eksempel: Anvendelse af referencearkitekturen i et projekt 54
6.4 Bilag D: Eksempler på løsninger pr. implementeringsmønster 57
6.5 Bilag E: Om specifikationer, standarder og profiler 58
6.6 Bilag F: Mapning til European Interoperability Reference Architecture v2 59
6.7 Bilag G: Oversigt over kilder og baggrundsmateriale 62
4
Forord
Hverdagen er digital, og data om borgere, virksomheder, myndigheder, ejendomme, steder, køretøjer
m.m. vedligeholdes på en lang række områder af den offentlige administration. Der ligger et stort po-
tentiale i at gøre sådanne data tilgængelige for genbrug, så de kan skabe værdi i flere sammenhænge.
Deling af data er et fundament for bedre understøttelse af tværgående, offentlige services, og åbner for
anvendelse af data i nye og innovative sammenhænge.
Deling af data kan være teknisk kompliceret og i mange tilfælde omkostningstungt. Herudover er deling
af data altid underlagt en række lovmæssige og organisatoriske krav, der synligt og til fulde skal opfyldes
for at bevare borgeres og virksomheders tillid til datadeling i det offentlige Danmark. Dette øger kom-
pleksiteten i it-løsningerne og er dermed blandt årsagerne til, at potentialet i deling og genbrug af data
endnu ikke er indfriet i det omfang, det er muligt.
Denne referencearkitekturs formål er at hjælpe med at indfri dette potentiale. Dette gøres ved at intro-
ducere en fælles beskrivelse af de begreber og sammenhænge, der er væsentlige for at forstå og arbejde
med design og implementering af løsninger, der involverer deling af data og dokumenter. Dette sker
både på det strategiske plan, hvor vision, mål og arkitektoniske principper fastlægges; på det forretnings-
mæssige plan, hvor de typiske brugsscenarier beskrives; og på det tekniske plan, hvor en række imple-
menterings- og integrationsmønstre angiver, hvordan man i og mellem applikationer kan dele og for-
sende data. Endelig peger referencearkitekturen på en række konkrete specifikationer, der anvendes ved
deling af data og dokumenter i dag i den offentlige sektor.
Referencearkitekturen er udarbejdet under Den fællesoffentlige digitaliseringsstrategi 2016-2020 og skal
som sådan anvendes i alle projekter, der sorterer under digitaliseringsstrategien. Referencearkitekturen
er dermed relevant for såvel offentlige myndigheder, deres leverandører samt for virksomheder, der
ønsker at gøre brug af offentlige data.
5
Resume
Denne referencearkitektur anvender generelt begrebet videregivelse frem for deling af data. Videregivelse fo-
kuserer på den faktiske delingshandling – der, hvor data konkret gives videre. Deling har en bredere
betydning, der fx dækker at udstille data for at gøre dem potentielt tilgængelige for genbrug, uanset at
dette måske aldrig sker.
Vi introducerer ikke en specifik og isoleret definition af data – vi regner med, at læseren har en god
fornemmelse for, hvad data er, og det er i denne sammenhæng tilstrækkeligt. I forhold til dokumenter
introducerer vi en modellering, der fremhæver, at et dokument i bund og grund blot er en form for data.
Som afledt konsekvens taler vi i denne referencearkitektur ikke om deling af "data og dokumenter", men
blot om "data".
Et af hovedformålene med denne referencearkitektur er at vejlede i valget mellem de to grundlæggende
forretningsmønstre for videregivelse af data:
— Videregivelse på forespørgsel – typisk via et API i system til system-integrationer
— Videregivelse ved meddelelse indeholdende data (herunder dokumenter) – typisk brugt ved beskeder til
borgere/virksomheder, der skal have retsvirkning, men også et klassisk mønster brugt i system til
system-integrationer.
Den fundamentale forskel på disse to scenarier er, om det er den aktør, der videregiver data eller den aktør,
der modtager data, der er ansvarlig for den konkrete sagsgang eller det konkrete procesforløb, som vide-
regivelsen af data indgår i.
Ved videregivelse på forespørgsel er den dataansvarlige som udgangspunkt ikke bekendt med modtage-
rens anvendelse men er naturligvis forpligtet til at håndhæve relevant hjemmel. Et eksempel på dette er
en myndigheds forespørgsel på personoplysninger i CPR-registeret.
Ved videregivelse ved meddelelse er det afsenderen, der i en given kontekst afsender en meddelelse med
et givent formål – typisk som led i afviklingen af en arbejdsgang, der enten kan være manuel eller auto-
matiseret. Et eksempel på dette er politiets fremsendelse af en fartbøde til en borger.
Figur 1 opsummerer denne referencearkitekturs væsentligste elementer. Afsnit 3 Forretningsarkitektur
beskriver de to forretningsmønstre i yderligere detaljer. For hvert forretningsmønster er der tre mulige
implementeringsmønstre. Disse foldes ud i afsnit 4 Teknisk arkitektur, der også udpeger de gennemgå-
ende integrationssnitflader, der er kandidater til standardisering.
Figur 1: Oversigt over de væsentligste mønstre i referencearkitektur for deling af data og dokumenter – to generiske forretningsprocesmønstre med hver tre forskellige tekniske implementeringsmønstre.
6
Executive summary
This reference architecture revolves around describing disclosure of data by transmission (Danish: vide-
regivelse af data). Disclosure by transmission focuses on the actual action of passing on data whereas sharing
(Danish: deling) of data has a broader interpretation that includes making data available for potential
reuse, even if the data may never be accessed.
We do not introduce a specific, isolated definition of data. We assume that the reader already has an
intuitive notion of what data is which is sufficient in this context. Regarding documents, a modelling is
introduced to point out how a document is, basically, just data. Consequently, we will not speak of sharing
“data and documents” but only speak of “data”.
A main purpose of this reference architecture is to guide and assist in the choice between two funda-
mental business patterns for disclosure of data by transmission:
— Transmission on request – typically, system-to-system integrations using an API
— Transmission by message – typically used in legally binding communication of data (possibly in the
form of documents) from public authorities to citizens and businesses, but also a classical pattern
used in system to system integrations.
The fundamental difference between these two scenarios is whether it is the actor transmitting data or the
actor receiving data who is responsible for the concrete process flow or the management of the concrete
case in context of which data is transmitted.
For transmission on request, the data controller does not necessarily know the specific purpose for
which the requesting party plans to use the data. The data controller must, however, enforce access to
data by requesting that the requester has a proper legal basis that justifies the transmission of data. One
example of this is when a public authority seeks information on a citizen in the CPR register.
When transmitting data by a message it is the sender who transmits data for a well-known and specific
purpose, typically as part of a manual or automated workflow. An example of this pattern would be the
police sending a speeding ticket to a citizen.
Figure 2 shows the central elements of this reference architecture. Section 3 Forretningsarkitektur de-
scribes the two business patterns in further detail. Each business pattern may be implemented using one
of three implementation patterns. These patterns are described in Section 4 Teknisk arkitektur which
also points to the recurring integration interfaces that are candidates for standardization work.
Figure 2: Overview of the patterns described in this reference architecture – two generic business pat-terns, each with three distinct technical implementation patterns.
7
1 Introduktion
1.1 Formål, anvendelse og målgruppe Det overordnede formål med denne referencearkitektur er at understøtte offentlig digitalisering i regi af
Den fællesoffentlige digitaliseringsstrategi 2016-2020. Derudover kan referencearkitekturen anvendes
generelt i projekter i både offentlige og private digitaliseringsinitiativer.
Specifikt i sammenhæng med udmøntningen af den aktuelle strategi skal referencearkitekturen anvendes:
- som vejledning og reference i udarbejdelse af løsningsdesign, der involverer deling af data, særligt
med henblik på valg af implementeringsmønstre, ud fra et ’følg eller forklar’-princip
- ved review af løsningsbeskrivelser
- som udgangspunkt for udarbejdelse af domænespecifikke referencearkitekturer for deling af data
og dokumenter
- til at danne et fælles sprog til at formulere en fælles handlingsplan blandt digitaliserings-strategiens
parter
Værdien på overordnet plan af denne referencearkitektur er, at den bidrager til at skabe sammenhæn-
gende, sikre og effektive digitale services for borgere og virksomheder ved at skabe rammer for større
genbrug af data, hvilket bl.a. vil understøtte øget automatisering.
Dokumentet er primært målrettet it-arkitekter tilknyttet offentlige digitaliseringsprojekter, fx enterprise-
arkitekter, forretningsarkitekter og løsningsarkitekter, der har til opgave at kravspecificere og designe
løsninger.
De første dele af dokumentet (Strategi og Forretningsmæssig arkitektur) henvender sig endvidere til
projektledere og beslutningstagere, herunder forretningsansvarlige, digitaliseringschefer, it-chefer, afde-
lings- og kontorchefer og andre med rollen som systemejer.
Dokumentet i sin helhed er også relevant for nuværende og potentielle leverandører af offentlige it-
løsninger.
1.2 Scope Referencearkitektur for deling af data og dokumenter understøtter design, udvikling/indkøb og anven-
delse af offentlige it-systemer, der videregiver eller modtager registrerede oplysninger i elektronisk form
til/fra andre myndigheder, virksomheder og borgere.
Referencearkitekturen skrives på baggrund af Den fællesoffentlige digitaliseringsstrategi 2016-2020 un-
der initiativ 8.1 med tilslutning fra FM, UFM, EVM, SIM, JM, EFKM, MBUL, SÆM, SKM, MFVM,
BM, KL og Danske Regioner. Heri beskrives referencearkitekturen således:
For at operationalisere, hvilke krav hvidbogen konkret stiller til initiativer og systemer ud-
arbejdes en referencearkitektur for deling af data og dokumenter, der blandt andet beskri-
ver fælles behovsmønstre og mønstre for teknisk understøttelse, herunder de forskellige
roller, der skal afklares i initiativerne. Referencearkitekturen udpeger også eventuelle områ-
der for eksisterende og nye fælles standarder og infrastruktur, som skal lette initiativernes
implementering. Referencearkitekturen bliver således en generel ramme og støtte for alle
initiativernes egen specifikke arkitektur.
I et juridisk perspektiv er dette område reguleret af en lang række forordninger og love. Afsnit 2.5 op-
ridser de relevante love og forordninger, der sætter de juridiske rammer for deling af data og dokumen-
ter.
8
Scope for denne referencearkitektur er, som navnet angiver, selve delingen/videregivelsen af data (her-
under persondata og evt. i form af dokumenter). Vi søger ikke at definere den bredere anvendelse af data,
herunder hvordan data registreres, eller hvordan den aktør (fx en myndighed), der afsender eller mod-
tager data, benytter disse data i en konkret arbejdsgang. Processerne for registrering af data samt afsen-
delse og modtagelse af en meddelelse er dog summarisk beskrevet for at introducere begreber, der er
relevante for at kunne tale om selve delingen/videregivelsen af data.
Specifikt er det uden for scope af denne referencearkitektur at definere:
— Anvendelse af data, herunder:
— Registrering og intern anvendelse af data hos den dataansvarlige myndighed
— Konteksten for en aktørs behov for at forespørge på data, videregive data via en medde-
lelse eller modtage data via en meddelelse
— Sletning og arkivering af data styret af den dataansvarlige myndighed
— Streaming af data (videodata, IoT-data m.m.)
— Partsrepræsentation, hvor én aktør efter samtykke agerer på vegne af en anden
— Grænseoverskridende (cross-border) videregivelse af data
I forhold til streaming af data bemærker vi, at streaming løseligt kan beskrives som en seriel række af
processen videregivelse på forespørgsel, som vi beskriver senere i dette dokument. Eventuelle, yderligere
aspekter ved streaming, der kan være relevante at belyse i en referencearkitektur, er ikke inkluderet i
denne referencearkitekturs nuværende version.
Partsrepræsentation er en generel problemstilling, der ikke er isoleret til deling af data og dokumenter.
Problemstillingen vil derfor bliver behandlet andetsteds, fx i forbindelse med en revision af den fælles-
offentlige referencearkitektur for brugerstyring.
I forhold til grænseoverskridende videregivelse af data er mandatet for denne referencearkitektur be-
grænset til bestemte initiativer forankret hos de myndigheder, der er del af Den fællesoffentlige digitali-
seringsstrategi 2016-2020. Mandatet rækker dermed ikke ud over landets grænser.
1.3 Centrale begreber Vi vil i denne referencearkitektur ikke give en komplet udredning af forskelle og ligheder mellem begre-
berne data, oplysning og information, der bruges meget forskelligt på tværs af faggrupper og praksisser i den
offentlige sektor. I stedet vil vi fokusere på en mere pragmatisk og lokal definition og holde os til data
som generelt begreb.
Figur 3: Figuren beskriver, hvordan data opbevares i datasamlinger og videregives i form af meddelelser, samt at dokumenter er en særlig form for data. Denne referencearkitektur beskæftiger sig generelt med
data som en samlende betegnelse for både data og dokumenter.
Figur 3 viser de centrale begreber i denne referencearkitektur, hvor data ikke overraskende ligger i mid-
ten. I afsnit 3 Forretningsarkitektur foldes begrebsmodelleringen yderligere ud, både i en diskussion af
9
data og dokumenter samt i en overordnet model af forretningsobjekter og begreber, der er nødvendige
for at beskrive videregivelse af data.
1.4 Tilblivelse og governance Første udgave er udarbejdet i Kontor for Data og Arkitektur, Digitaliseringsstyrelsen med konsulentbi-
stand fra Omnium Improvement.
I udarbejdelsen har en arbejdsgruppe af offentlige arkitekter bidraget gennem en række af workshops. I
gruppen har deltaget repræsentanter fra følgende organisationer: Kommunernes Landsforening, Danske
Regioner, Styrelsen for Dataforsyning og Effektivisering, Sundhedsdatastyrelsen, Styrelsen for Arbejds-
marked og Rekruttering, Miljø- og Fødevareministeriet, Styrelsen for It og Læring, Arbejdsmarkedets
Tillægspension (ATP), SKAT, Erhvervsstyrelsen og Digitaliseringsstyrelsen.
Første udgave af referencearkitekturen godkendtes i version 1.0 i Styregruppe for Data og Arkitektur
under Digitaliseringsstrategien i maj 2018. Styregruppen er herefter ejer af dokumentet, med Kontor for
Data og Arkitektur som ansvarlig for vedligehold af referencearkitekturen frem til 2020 som en del af
den Fællesoffentlige, Digitale Arkitektur.
1.5 Anvendt metode, notation og signaturforklaring Metodemæssigt er referencearkitekturen udarbejdet inden for rammerne af Den fællesoffentlige digitale
arkitektur og følger så vidt muligt den fælles skabelon for referencearkitekturer som udarbejdet i Sekre-
tariatet for Styregruppen for Data og Arkitektur under digitaliseringsstrategien. Metoderammen bygger
blandt andet på erfaringer fra OIO referencearkitektur, og indarbejder også elementer fra European
Interoperability Reference Architecture (EIRA), The Open Group Architecture Framework (TOGAF),
ArchiMate m.m.
I forhold til ejerskab af de elementer, der indgår i dokumentets figurer og definitioner, markerer:
— Fed tekst (i rød): At et element eller en relation ejes og defineres i denne referencearkitekturs
begrebsmodel
— Almindelig tekst (i blå): At et element eller en relation er kendt, men ejes og defineres et andet,
nærmere angivet sted, fx i andre referencearkitektur eller i lovgivning.
— Kursiv (i grå): At et element eller en relation er identificeret, men ikke nærmere defineret i denne
referencearkitektur.
I dokumentets tekst markerer:
— Sans serif: At et ord har en særlig betydning i denne referencearkitektur – jf. de tre markeringer af
ejerskab ovenfor
— Kursiv anvendes for betegnelser, der er hentet fra ArchiMate-begrebsapparatet.
Prefixet 'data-' kan være udeladt på begreber og elementer i tekst og figurer fx af formaterings- eller
læsbarhedshensyn uden, at der ligger en indholdsmæssig skelnen bag (fx dataanvender/anvender, datasam-
ling/samling o.a.)
I elementerne i dokumentets figurer angiver (med mindre anden betydning er angivet i figurteksten):
— runde hjørner: et Procestrin (Business Functions)
— skarpe hjørner: en Applikationsservice (Application Services)
— pil med stiplet linje (fra Applikationsservice mod Procestrin): at en Applikationsservice helt eller
delvist realiserer et Procestrin (Realization Relation)
— "slikkepind": en Snitflade (Application Interface)
10
1.6 Relation til rammearkitektur og andre referencearkitekturer Denne grundlæggende referencearkitektur er del af rammearkitekturen i den samlede, fællesoffentlige
digitale arkitektur (FDA). FDA-rammearkitekturen udfoldes i en række referencearkitekturer, som hver
dækker et emnefelt og gensidigt supplerer hinanden. For en introduktion til og overblik over den sam-
lede rammearkitektur samt relateret information henvises til arkitektur.digst.dk/rammearkitektur.
Denne referencearkitektur relaterer sig til en række andre referencearkitekturer, både eksisterende og
planlagte. Specifikt gør referencearkitektur for deling af data og dokumenter brug af:
— Fællesoffentlig referencearkitektur for brugerstyring (del af FDA-rammearkitektur, version 1.0)
Den skal kunne anvendes af:
— Fællesoffentlig referencearkitektur for selvbetjening (del af FDA-rammearkitektur, godkendt i ver-
sion 1.0 i regi af Initiativ 1.2 af Den fællesoffentlige digitaliseringsstrategi 2016-2020)
— Fællesoffentlig referencearkitektur for overblik over egne sager og ydelser (del af FDA-rammear-
kitektur, primo 2018 under udarbejdelse i regi af Initiativ 1.3 af Den fællesoffentlige digitaliserings-
strategi 2016-2020)
... og indgår i kontekst sammen med:
— Referencearkitektur for sags- og dokumentområdet (OIO, 2008)
— Referencearkitektur for deling af dokumenter og billeder (National sundheds-it, 2012)
— Referencearkitektur for informationssikkerhed (National sundheds-it, 2013)
— Indberetning til registre på sundhedsområdet (under godkendelse pr. november 2017)
1.7 Læsevejledning Dette dokument følger generelt skabelonen for referencearkitekturer under FDA-rammearkitekturen i
Den fællesoffentlige digitaliseringsstrategi 2016-2020. Dokumentets afsnit 1 udgør en generel introduk-
tion til referencearkitekturens formål, scope, de centrale begreber omkring deling af data og dokumenter,
og beskriver konteksten for dokumentets anvendelse og tilblivelse.
Afsnit 2 i dokumentet beskriver på det strategiske plan hvilke temaer, principper, love m.m., der sætter
rammer og retning for denne referencearkitektur. Afsnittet beskriver visionen for deling af data og do-
kumenter og afdækker den værdi, som brug af referencearkitekturen forventes at skabe.
I afsnit 3 beskrives forretningen i form af de grundlæggende use cases, roller og ansvar omkring videre-
givelse af data. Begrebsmodellen, der fanger de termer, der introduceres i denne referencearkitektur,
præsenteres også her.
Afsnit 4 beskriver den tekniske arkitektur i form af en række implementeringsmønstre for, hvordan
deling af data kan implementeres. Ud fra mønstrene identificeres en række gennemgående integrations-
snitflader, der leder op til en analyse af, hvor der er behov for standardisering.
Det er tilstræbt at bygge dokumentet op omkring enkle og relativt stramt definerede termer, der beskri-
ver de centrale begreber omkring videregivelse af data og de mulige forretnings- og implementerings-
mønstre. Definitionerne introduceres løbende gennem dokumentet og er endvidere opsamlet i Bilag B:
Ord- og begrebsliste.
Videregivelse af data er en grundlæggende kapabilitet og kan dermed relateres til en lang række af kon-
krete anvendelser, teknologier og arkitekturstile. I dette dokument søger vi at holde beskrivelserne til
den generiske begrebs- og funktionsmæssige kerne omkring videregivelse af data. Hvor det er relevant,
indeholder dokumentet dog en række kortfattede ”kroge” for at fange relationer og referencer, der går
ud over kernebeskrivelserne, uden dog at søge at give udtømmende detaljer eller definitioner.
11
2 Strategi
Dette afsnit introducerer visionen for deling af data og dokumenter med baggrund i identificerede te-
maer, principper, arkitekturregler og den forventede værdiskabelse.
2.1 Temaer Referencearkitekturen udmønter og understøtter beslutninger i Den fællesoffentlige digitaliseringsstra-
tegi 2016-2020. Strategien har tre, overordnede målsætninger:
— Det digitale skal være let, hurtigt og sikre god kvalitet
— Offentlig digitalisering skal give gode vilkår for vækst
— Tryghed og tillid skal i centrum
De tre målsætninger er understøttet af en række, specifikke initiativer, hvoraf Initiativ 8.1: Gode data og
effektiv datadeling er det konkrete ophæng for denne referencearkitektur.
Ved at kigge på tværs af initiativerne samt inddrage trends fra den digitale udvikling i samfundet i øvrigt
kan man opridse en række forretningsmæssige og teknologiske temaer, der er relevante i forhold til at
sætte retningen for den ønskelige arkitektur for datadeling:
— Sammenhængende offentlige services er et meget tydeligt, gennemgående tema. Den offentlige
forvaltning ønsker at tilbyde borgere og virksomheder services, der ikke er tæt knyttet til enkelte
myndigheder, men opleves som sammenhængende for dem, der anvender servicen. Mest tydeligt
er det udtrykt i European Interoperability Frameworks koncept om integrated service delivery
— Offentlige data skal deles og genbruges: En øget deling af data giver mulighed for nye gene-
rationer af digitale løsninger, som i højere grad kan trække de nødvendige data automatisk. Det
sparer tid for borgere og virksomheder, når de slipper for unødige indberetninger. Og det kan lette
de administrative processer og sagsbehandling, når manuelle arbejdsgange og i nogle tilfælde af-
gørelser kan automatiseres.
— Grænseoverskridende services: I takt med, at de enkelte nationer udvider deres ambitioner for
offentlig, digital service til borgere og virksomheder, stiger også behovet for at koordinere arkitek-
tur og it-løsninger på tværs af landegrænser for dels at understøtte services, der i deres natur kryd-
ser grænser (fx arbejde eller ejerskab af fast ejendom i et andet land), men også for at standardisere
og dermed undgå opbygning af nationale "siloer". EU er en aktiv spiller i at drive denne standar-
disering gennem initiativer som ISA2 (EIF/EIRA m.m.), CEF Digital (eDelivery m.m.) samt for-
ordninger som GDPR, eIDAS m.fl.
— Øget skalerbarhed: Der har de sidste 5-10 år været fokus på at få løsninger til at skalere forudsi-
geligt til web scale, ved hjælpe af teknologier som clustering og cloud. Der har medført et voldsomt
løft af de ressourcer, der globalt set er blevet brugt på large-scale implementeringer. Nu er området
så modent, at teknologierne også er tilgængelige for projekter på national skala og endda i enkelt-
projekter.
— Microservices: En måde at håndtere den stigende kompleksitet i forvaltningen af it-landskaber
er en udbredt strategi om at levere it-løsninger i mindre enheder, der kan idriftsættes og afvikles
uafhængigt og/eller parallelt. Microservices er en sådan strategi.
— Dataaktualitet: Med henblik på automatisering og sammenhængende services er der fokus på at
have kortest mulig tid mellem registrering og anvendelse af data. En ambitiøst mål er at digitale
12
selvbetjening kan gennemføres i inden for 5-10 minutter, selvom de involverer ændringer i grund-
læggende oplysninger hos flere myndigheder.
— Suverænitet og beskyttelse mod cyberangreb er et tema, som har været på dagsordenen længe,
men har med regeringens cybersecurity-strategi fået en vægt og et fokus, der ikke er set tidligere.
Tendensen udgør et større, strategisk skifte, som mindsker noget af den tillid, som tidligere har
været vist store it-leverandører, og peger i retning af hjemtagning af centrale/kritiske/vitale funk-
tioner som fx fysiske netværksforbindelser.
— Øget opmærksomhed om behandling af personlige oplysninger: Den europæiske forordning
om beskyttelse af personoplysninger (GPDR) og tilhørende dansk implementering udvider den
dataansvarliges risiko i forhold til tidligere. Det har ført til et fornyet fokus på overblik over be-
handling af persondata og tilsynet hermed.
Mange af disse temaer kan genfindes i en række aktuelle offentlige og politiske strategiarbejder, herunder
sammenhængsreformen, den nationale cybersikkerhedsstrategi, kommunernes digitaliseringsstrategi
"Lokal og Digital", Strategi for digital Sundhed 2018-2020 samt det europæiske rammeværk for inter-
operabilitet (New European Interoperability Framework for European Public Services).
2.2 Strategiske principper De strategiske principper, der ligger til grund for denne referencearkitektur, udspænder sig i et spæn-
dingsfelt. På den ene side åbner visionen om det datadrevne samfund, hvor data ses som et råstof for
samfundsudviklingen, for en lang række muligheder og ønsker. På den anden side er deling og data også
underlagt begrænsninger og indskrænkninger i lovgivning. Dette afsnit opridser de væsentligste princip-
per i dette spændingsfelt.
På mulighedssiden er det en fundamental målsætning, at:
Det digitale skal være let, hurtigt og sikre god kvalitet (kilde: Digitaliseringsstrategien)
Mere generisk kan man, med inspiration fra the European Interoperability Framework (EIF), fremhæve
fire overordnede principper:
— interoperabilitet princip om sammenhængende services og smidige brugerrejser på tværs af myn-
dighedsskel
— once-only princip om, at borger og virksomhed kun skal afgive den samme information til det
offentlige én gang.
— gennemsigtighed princip om, at borgere skal sikres indsigt i, hvilke personoplysninger der be-
handles af offentlige myndigheder og med hvilke formål.
— genbrug princip om genbrug af it med henblik på lavere omkostninger
På begrænsningssiden er der også en række principper, der skal tages i agt. Nedenstående principper er
hentet fra EUs databeskyttelsesforordning (GDPR) og er i vores sammenhæng dækkende uden behov
for yderligere definition:
— lovlighed, rimelighed og gennemsigtighed
— formålsbegrænsning (undtaget er arkiver, forskning og statistiske formål)
— data-minimering
— rigtighed (urigtige data skal straks slettes eller berigtiges)
— opbevaringsbegrænsning (data må ikke opbevares "for evigt")
— integritet og fortrolighed
— ansvarlighed (man skal kunne påvise, at ovenstående overholdes)
13
2.3 Vision Visionen i denne referencearkitektur er at stræbe efter en situation, hvor:
Data er en fælles, værdifuld og velbeskyttet ressource, som er nem at
dele og bruge, men svær at misbruge
Fælles betyder, at data i videst muligt omfang (og ud fra once only-princippet) betragtes som et fælles
gode på tværs af myndigheder ud fra en betragtning om, at data, der registreres ét sted til ét formål, kan
have stor værdi for andre myndigheder og virksomheder, der udbyder private tjenester. Værdifuld be-
tyder, at data, der er registeret i det offentlige, betragtes som et økonomisk og kvalitetsmæssigt aktiv på
lige fod med kontantbeholdninger og fysiske ejendom. Velbeskyttet betyder, at der er taget tilstrække-
lige og effektive sikkerhedsmæssige tiltag til at beskytte borgere og virksomheders data og dermed deres
tillid til, at opbevaring, anvendelse og videregivelse sker under gennemskuelige og retmæssige forhold.
Nem at dele betyder, at udgifterne ved at anvende data i en ny sammenhæng ikke alene løftes af den
dataansvarlige myndighed, samt at der er tydelig vejledning i udarbejdelse af nødvendige aftaler. Nem
at bruge betyder, at der er fastlagte processer, best practices og generiske infrastrukturelementer, der kan
genbruges. Svær at misbruge betyder, at enkeltpersoner, organisationer og fremmede magter, der måtte
have til hensigt at bruge data uretmæssigt, begrænses mest muligt gennem en indsats, der står i forhold
til truslerne og de mulige konsekvenser af misbrug.
Denne vision kræver, at en række forretningsevner i det offentlige forstærkes væsentligt, herunder:
— Koordination af lovgivning - handler om at der er enighed om centrale definitioner på tværs af
flere ressortområder. Samt, at der er adgang til effektiv vejledning ved tvivl.
— Aftaleindgåelse kan tage lang tid og kræver meget arbejde. Bør kunne ske ved brug af generelle
og eksisterende aftaler, så der ikke startes forfra, hver gang nye videregivelser skal etableres.
— Identifikation og dokumentation af data - sker allerede i ISO 27000-sammenhæng for den
interne brug, men også behov for at dække, at data udstilles til andre.
— Genbrug af løsninger - sikrer, at vi kan lave hyppige udvidelser både af funktionalitet og anven-
delsesområde.
2.4 Værdiskabelse Værdien ved at følge denne referencearkitektur kan deles op i den direkte og indirekte værdiskabelse.
Den direkte værdiskabelse opnås ved, at referencearkitekturen:
— muliggør effektiv systemudvikling relateret til videregivelse af data, da den indskrænker udfalds-
rummet for løsninger samt opsamler best practice
— skaber juridisk værdi gennem designmæssig indlejring af compliance-understøttelse for GDPR,
eIDAS m.m.
Med effektiv systemudvikling og compliance på plads er vejen banet for, at data i langt højere grad kan
deles ensartet, effektivt og sikkert. Dette åbner for en lang række fordele, der kan betragtes som indirekte
værdiskabelse fra referencearkitekturen, i form af:
— enklere og mere effektive digitale services for borgere og virksomheder
— simplere arbejdsgange og øget potentiale for automatisering hos organisationer (myndigheder og
virksomheder)
— borgere oplever hurtigere arbejdsgange med færre fejl, når genindtastning af data undgås
14
— højere kvalitet i organisationers data og dermed også i de informationer og den viden, der kan
udledes af data gennem analyser
— vækst i samfundet gennem nye typer af services baseret på eksisterende data
— øget transparens og bevarelse af tillid til registre
2.5 Juridiske rammer De mest relevante love og forordninger (med særligt fokus på videregivelse af persondata) er:
— EU-databeskyttelsesforordningen (GDPR) beskriver pligter og rettigheder ved behandling af
persondata. I sammenhæng med denne referencearkitektur er GDPR central, da en stor del af de
data, der er registreret af offentlige myndigheder, er personhenførbare. Da persondata er en af de
datatyper, der er strengest reguleret (sammenlignet med fx virksomhedsdata, geodata, registrering
af objekter m.m.), har vi valgt at genbruge mange termer og begreber fra GDPR i denne referen-
cearkitektur. Herudover er en række aspekter, der dækkes af GDPR, relevante - fx definitionen af
gyldige grunde til videregivelse af persondata, den nødvendige hjemmel i form af borgerens (den
registreredes) samtykke, m.v.
— Persondataloven beskriver pligter og rettigheder ved behandling af persondata. Relevansen for
denne referencearkitektur er i høj grad den samme som for GDPR. Det bemærkes, at Personda-
taloven forventes helt eller delvist erstattet af en kommende Databeskyttelseslov, der på tidspunk-
tet for dette dokuments udarbejdelse behandles i folketinget, og som sammen med GDPR frem-
over vil definere den registreredes rettigheder.
Med hensyn til digitalisering generelt er følgende love særligt relevante:
— EU-forordningen eIDAS (electronic IDentification, Authentication and trust Services) definerer
registrerede tillidstjenester. Forordningen specificerer bl.a., at elektroniske transaktioner, der op-
fylder kravene i eIDAS, altid har samme juridiske gyldighed som klassiske, papirbårne transaktio-
ner. Forordningen fjerner dermed en klassisk barriere for digitalisering. I forhold til denne refe-
rencearkitektur bemærker vi, at eIDAS har et udpræget grænseoverskridende (cross border) fokus.
Det grænseoverskridende aspekt af videregivelse af data behandles ikke i dette dokument.
— Lov om Digital Post fra offentlige afsendere gør det obligatorisk for virksomheder og borgere
at modtage digitale meddelelser fra offentlige afsendere. Digital Post er således en central kanal,
når myndigheder ønsker at dele data og dokumenter med borgere og virksomheder gennem med-
delelser.
Derudover er der en række mere specifikke love, der sætter rammer for videregivelse af data i den of-
fentlige forvaltning, fx inden for særlige sektorer eller domæner. Listen nedenfor inkluderer de væsent-
ligste, men er ikke udtømmende.
— Sundhedsloven regulerer hvem der har ansvar for behandling, forebyggelse og sundhedsfremme
i det danske sundhedsvæsen. Sundhedsdata om borgere udgør en særlig følsom kategori af data,
og Sundhedsloven regulerer derfor i detaljer, hvordan og til hvilke formål data kan behandles.
Hvem, der har adgang til data, og hvordan adgang kan begrænses (herunder 'negativt samtykke’,
der i nogen grad svarer til GDPR-begrebet 'begrænsning af behandling'), er reguleret i detajler.
Derudover beskrives også ’indhentning af oplysninger’, som adskiller sig væsentligt fra den vide-
regivelse, der beskrives i dette dokument. Endelig begrænser Sundhedsloven også den registrere-
des ret til indsigt i oplysninger, der er registreret i forbindelse med behandling.
15
— Serviceloven udstikker rammerne for rådgivning og støtte for at forebygge sociale problemer
samt for at tilbyde ydelser til borgere med nedsat fysisk eller psykisk funktionsevne eller særlige
sociale problemer. Loven danner baggrund for sagsbehandlingsforløb, der typisk kan involvere en
række forskellige myndigheder. Dermed er loven et godt eksempel på, hvordan der juridisk kan
gives hjemmel til deling/videregivelse af data i en række, konkrete scenarier.
— Forvaltningsloven indeholder regler om borgernes retsstilling over for den offentlige forvaltning.
I forbindelse med sagsbehandling i offentlige forvaltninger regulerer loven bl.a. aktindsigt fx i be-
grundelse for afgørelser. I forhold til denne referencearkitektur spiller Forvaltningsloven bl.a. ind
i diskussionen om forholdet mellem data og dokumenter.
— Arkivloven sikrer bevaringsværdige data. Ved design af løsninger, der indebærer etablering af nye
datasamlinger eller ændringer til eksisterende, skal myndigheder tage højde for, at bevaringsvær-
dige data skal kunne eksporteres til offentligt arkiv.
— Lov om krav til sikkerhed for net og informationssystemer inden for sundhedssektoren (i
skrivende stund under behandling) skal implementere dele af EU’s NIS-direktiv (direktiv
2016/1148/EU af 6. juli 2016). Lovforslaget har til formål at sikre et højt sikkerhedsniveau inden
for sundhedssektoren for så vidt muligt at undgå hændelser, der forstyrrer behandling, pleje og
patientsikkerhed, og forventes at få stor betydning for videregivelse af data på sundhedsområdet.
I den konkrete situation, hvor videregivelse af data med henblik på genbrug af data overvejes, kan der
være yderligere juridiske rammer, der vil påvirke løsningsarkitekturen. Dette må analyseres og afsøges i
det enkelte tilfælde.
2.6 Sikkerhed Sikkerheden ved videregivelse af data beror altid på forholdet mellem en konkret risikovurdering og de
tiltag, der gøres for at imødegå de identificerede risici. I denne referencearkitektur er det forsøgt at be-
skrive sikkerhedsovervejelser i forbindelse med de relevante arkitekturelementer, fremfor at samle dem
i et særskilt afsnit. Dette ud fra en betragtning om, at sikkerhed ikke er et særskilt emne, men bør være
gennemgående for alle betragtninger i emnet videregivelse af data.
Mere generelt kan informationssikkerhed betragtes som evnen til at kontrollere fortrolighed, integritet
og tilgængelighed af de behandlede data. For videregivelse af data betyder dette mere specifikt at den
dataansvarlige skal sikre sig:
- at tilliden til identifikationen af modtageren af data er passende i forhold til den følsomhedsklas-
sifikation, data har (fortrolighed)
- at protokoller til overførsel af data sikrer, at disse ikke kan læses eller ændres af uvedkommende
(fortrolighed, integritet)
- at data opbevares og udstilles på en måde, så de ikke slettes eller gøres utilgængelige ved uheld eller
direkte misbrug (tilgængelighed)
I øvrigt er de generelle forhold ved informationssikkerhed, der er beskrevet i blandt andet referencear-
kitektur for brugerstyring samt vejledning om informationssikkerhed, også gældende for området vide-
regivelse af data.
Endelig kan der omkring videregivelse af konkrete typer data gælde mere specifik lovgivning, der regu-
lerer niveauet af sikkerhed og tekniske tiltag for at opnå denne. Det er altid den dataansvarliges ansvar
at sikre sig, at den specifikke lovgivning overholdes.
16
2.7 Fællesoffentlige arkitekturprincipper og -regler Den Fællesoffentlige Digitale Arkitektur (FDA) udpeger en række principper til rammesætning og sty-
ring af den offentlige digitalisering. Under hvert princip angiver FDA fra 1 til 5 konkrete arkitekturregler.
Tabellen nedenfor gengiver FDA's arkitekturprincipper (kilde: https://arkitektur.digst.dk/).
Nr. Område Princip
1 Styring Arkitektur styres på rette niveau efter fælles rammer
2 Strategi Arkitektur fremmer sammenhæng, innovation og effektivitet
3 Jura Arkitektur og regulering understøtter hinanden
4 Sikkerhed Sikkerhed, privatliv og tillid sikres
5 Opgaver Processer optimeres på tværs
6 Information Gode data deles og genbruges
7 Applikation It-løsninger samarbejder effektivt
8 Infrastruktur Data og services leveres driftssikkert
I denne referencearkitektur er fokus at understøtte arkitekturprincip 6 om, at Gode data deles og genbruges
og i særlig grad den underliggende regel: 6.1 Del og genbrug data. Referencearkitekturen for deling af data
og dokumenter tilbyder to måder, hvorpå data kan videregives til genbrug, og seks forskellige, tekniske
implementeringsmønstre, som videregivelse/deling af data kan realiseres gennem.
Derudover kan en række af de øvrige arkitekturregler udfoldes og konkretiseres i forhold til denne refe-
rencearkitektur:
AR 1.2 Optimer arkitektur efter projektets og de fælles mål
— Som eksempel på et arkitekturmæssigt dilemma i forhold til at indfri det fælles mål om at dele data
kan nævnes den udgift, der er forbundet med at holde systemer kørende for at udstille data. Ud-
giften falder typisk til den dataansvarlige, der ikke har en isoleret gevinst ud af, at data genbruges.
Det bør i designet af it-systemer fremadrettet overvejes, om man kan designe mønstre, styrings-
strukturer og aftaler, der afløfter byrden ved videregivelse af data fra den dataansvarlige for at
understøtte genanvendelse.
AR2.2 Anvend åbne og internationale standarder
— Beskrevne applikationsservices bør kunne genfindes i eksisterende standarder.
AR2.5 Stil data og løsninger til rådighed for private
— Ensartede forretningsprocesser, implementeringsmønstre og tekniske specifikationer vil under-
støtte sammenstilling af data og tværgående brug blandt myndigheder og virksomheder
AR3.1 Tag højde for juridiske bindinger i forhold til deling og genbrug af data og it-systemer
— Modeller funderes (med eksplicitte referencer) i relevant lovgivning nationalt og internationalt
— Dataudveksling mellem organisationer skal understøtte behovene omkring journalisering, forvalt-
ningsret, tvistafgørelse, indsigter m.m., der er funderet i den klassiske "dokument-tankegang"
AR4.1 Opfyld krav til informationssikkerhed og privatlivsbeskyttelse
— Understøtte borgeres og virksomheders indsigt i opbevaring og anvendelse af personoplysninger
— Beskrivelse af data, adgang til data og anvendelse af data sker under klar governance og håndhæves
ud fra tydelig hjemmel
17
— Peger mod at begrænse eksistens og anvendelse af kopiregistre
AR4.2 Anvend fælles arkitektur for informationssikkerhed
— Ansvar for begrænsning af adgang ligger hos dataansvarlig
— Vedligehold af fuldmagter og samtykker sker løst koblet fra deres anvendelse til adgangskontrol
AR5.1 Optimér tværgående processer efter fælles mål
— Data beskrives, fordeles, forbedres og beskyttes i fællesskab
AR6.2 Anvende fælles regler for dokumentation af data
— Anvend fælles referenceinformationsmodel, grund- og referencedata
AR7.1 Design og udstil snitflader efter fælles integrationsmønstre og tekniske standarder
— Anvend et eller flere af de tekniske implementeringsmønstre i denne referencearkitektur ved deling
af data og dokumenter
— Overvej genbrug af tekniske standarder og specifikationer nævnt i denne referencearkitektur
AR8.1 Levér data og services i henhold til aftalte servicemål
— Ved tilslutning til dataservices aftales servicemål og mål for datakvalitet
18
3 Forretningsarkitektur
Dette afsnit beskriver på forretningsniveau de centrale forretningsfunktioner, der er dækket i denne
referencearkitektur, i form af use cases og tværgående processer. De medvirkende aktører og deres roller
beskrives. Sluttelig gives en oversigt over forretningsobjekter omkring deling af data og dokumenter.
3.1 Forretningsmæssig kontekst for videregivelse af data Emnet for denne referencearkitektur er "deling af data og dokumenter". Det er ikke urimeligt at sige, at
denne funktion er så generisk, at den indgår i snart sagt alle processer, der går ud over den enkelte
myndighed, hvad enten det er i forbindelse med sagsbehandling, selvbetjening eller noget tredje. Over-
ordnet set finder referencearkitekturen dermed anvendelse i løsningen af alle offentlige opgaver.
Som beskrevet i afsnit 1 har vi præciseret scope for dette dokument til at dreje sig om selve videregivelsen
af data - og ikke de mulige anvendelser, der muliggøres gennem videregivelsen. Vi gør dette ud fra en
betragtning om, at typen af denne referencearkitektur er en grundlæggende referencearkitektur. Når det
er sagt, er det alligevel meningsfuldt kort at overveje de typiske anvendelser for derigennem at forstå
konteksten for videregivelse af data bedre.
Figur 4: Anvendelse af data falder i to kategorier: Behandling af data i forbindelse med sagsbehandling, der typisk udgør den primære årsag til registrering af persondata, og anden, sekundær behandling. Sags-behandling skal her forstås bredt og inkluderer fx patientforløb i sundhedssektoren. Den særlige marke-ring af offentlig selvbetjening indikerer, at dette emne er specifikt håndteret inden for Den fællesoffentlige digitaliseringsstrategi 2016-2020 i og med, at det har sin egen referencearkitektur for selvbetjeningsløs-ninger, der indgår i den fællesoffentlige rammearkitektur.
Figuren ovenfor illustrerer, at anvendelsen af delte data kan deles ind i to kategorier: Den primære an-
vendelse, som består af behandling af data i forbindelse med en sagsgang, som oftest vil være det formål,
data er indsamlet til. Primære anvendelser er typisk knyttet til sagsbehandling, borgerens/virksomhedens
selvbetjening eller til forskellige, private tjenester, der gør brug af delte data.
Herudover findes der sekundære anvendelser, som indbefatter brug af data til styringsformål, økonomi-
opfølgning og økonomisk afregning, statistik, forskningsformål og meget mere.
Som eksempler på anvendelser, der vil have gavn af effektiv datadeling, kan nævnes nedenstående sæt
af generiske procesmønstre:
— Myndigheders sagsbehandling (forstået i bred forstand, inkluderer fx patientforløb i sundhedssek-
toren)
— Selvbetjening, vendt mod borgere og virksomheder
— Indsigt i oplysninger og deres anvendelse
— Brug af Digital Post (herunder påmindelser)
— Brug af abonnementsfunktionalitet (herunder tilmelding)
19
— Medbringelse af et dokument til en anden, offentlig/privat serviceudbyder, der ikke har adgang til
registre - herunder bekræftelse af dokumentets ægthed og validering af dets indhold
— Tværgående analyse, tilsyn og kontrol
3.2 Om data og dokumenter Figur 5 viser de centrale begreber i denne referencearkitektur, hvor data ikke overraskende ligger i mid-
ten. Vi vil ikke introducere en specifik og isoleret definition af data - vi regner med, at læseren har en
god fornemmelse for, hvad data er, og det er i denne sammenhæng tilstrækkeligt.
Figur 5: Begrebet data er noget, der enten har form af et dokument (og evt. kan opbevares i et reposi-tory), eller har form af en registrering, der indgår i et register. Begrebsmæssigt indgår data i samlinger og
kan - evt. i form af et dokument - videregives i en meddelelse.
Vi vil i stedet tale om data ud fra de relationer, der er afbildet i figuren. Har man fx mange, ens struktu-
rerede data samlet samme sted, indgår data i en samling. En datasamling vil typisk have en standardiseret
måde, hvorpå man kan hente data på forespørgsel.
Data kan også indgå i en meddelelse i forbindelse med, at de videregives fra en afsender til en modtager.
En meddelelse og et dokument kan være både struktureret og ustruktureret.
Data har to specialiseringer. Den første er en registrering, der betegner, at en myndighed har registreret
oplysninger på standardiseret og struktureret vis, typisk ud fra specifik, lovmæssig hjemmel. Registrerin-
gerne udgør tilsammen et register, der dermed er en specialiseret datasamling. Registeret understøtter op-
slag af data i form af den oprindelige registrering, fx i kontekst af myndigheders sagsbehandling eller for
at understøtte selvbetjeningsprocesser. Registeret kan også understøtte mere finkornede opslag. Et ek-
sempel på dette kunne være en anvendelsesorienteret dataservice, der baserer sig på finkornede opslag i
flere registre for at kombinere udvalgte data til brug i en given, specifik sammenhæng.
Den anden specialisering af data er i form af et dokument. Med denne modellering viser vi, at et dokument
i bund og grund blot består af data. Dokumenter behøver således ikke at være ustrukturerede, men kan
have indlejret fuldt strukturerede data. Som afledt konsekvens vælger vi som generelt princip i denne
referencearkitektur ikke tale om deling af "data og dokumenter", men i stedet indskrænke til at tale om
"data".
Med det sagt, er der alligevel nogle kvaliteter ved et dokument, der skal fremhæves. For det første er et
dokument typisk karakteriseret ved, at det er optimeret mod at være tilgængeligt for menneskeøjne, da
det binder data i en grafisk, læsbar opsætning (i tilgift til, at mange dokumenttyper også tilbyder indlejring
af data i fuldt struktureret, maskinlæsbar form). For det andet har et dokument nogle iboende egenskaber,
der er hensigtsmæssige i forvaltningsmæssige sammenhænge: Et dokument kan samle en række data, der
i praksis håndteres som en samlet enhed, eller som er nødvendige på et givet tidspunkt i et sagsbehand-
lingsforløb, for eksempel som beslutningsgrundlag eller ved videregivelse af data fra én myndighed til en
anden. Et dokument kan være tidsstemplet og signeret, og er dermed et klart grundlag for aktindsigt,
retslige afgørelser og i det hele taget den historiske dokumentation af en sagsgang. Til sammenligning
vil det ofte være vanskeligere at afgøre, nøjagtigt hvordan en specifik registrering så ud i et register på et
20
givet tidspunkt. Dette vil typisk kræve, at registeret på forespørgselstidspunktet teknisk gendanner, hvor-
dan registreringen så ud på det givne tidspunkt - hvorimod de historiske data, hvis de var gemt i dokument-
form, ville være direkte tilgængelige.
Endelig findes der også en specialisering af datasamling for dokumenter, nemlig en dokumentsamling eller
et repository, som er det fysiske sted, hvor dokumenter lagres efter oprettelse, og hvorfra de hentes ved
efterfølgende anvendelse. Vi anvender den engelske term repository med reference til Referencearkitektur
for deling af dokumenter og billeder, 2012, hvor dokumentbegrebet foldes yderligere ud for sundheds-
området.
Endvidere vil vi undlade at bruge ordet metadata. Ordet anvendes historisk set meget forskelligt, typisk
med en betydning der er tæt knyttet til en konkret anvendelsessituation. Fra denne referencearkitekturs
synspunkt er metadata imidlertid blot en særlig form af data.
To virkelige eksempler kan gøre begreberne omkring data mere konkrete:
— CPR-registeret: data om borgere indgår i den datasamling, der kaldes CPR-registeret og i praksis
benævnes netop som et register. Data om en enkelt borger udgør én specifik registrering i CPR-
registeret, der kan hentes via en standardiseret forespørgsel.
— Røntgenbilleder: data relateret til et røntgenbillede består dels af billeddata, dels af yderligere
informationer som fx tidsstempel, patient-ID, datakilde m.m. I praksis håndteres data for et rønt-
genbillede i et samlet, standardiseret objekt, som vi kan referere til som et dokument. Røntgenbil-
leder er gemt i flere repositories decentralt i røntgensystemer hos de enkelte regioner/hospitaler.
3.3 Forretningsfunktionen videregivelse Den centrale delte use case i denne referencearkitektur er:
videregivelse forretningsfunktion hvorved data overføres ud af organisation
samt yderligere to use cases, der ikke er beskrevet uddybende i denne referencearkitektur; registrering
samt sletning og arkivering. En særlig variant af videregivelse omhandler den registreredes ret til indsigt i
behandling af persondata. Den betragtes her som et særtilfælde af videregivelse og vil i praksis realiseres
som en digital selvbetjening og følge retningslinjer beskrevet i den fælles offentlige referencearkitektur
for selvbetjening.
Figur 6: Den delte use case videregivelse, de relaterede use cases registrering og sletning og arkivering samt de funktioner, der er knyttet til de involverede roller, modelleret med relevante juridiske roller og forret-ningsmæssige funktioner.
21
3.4 Forretningsroller og aktører I denne referencearkitektur defineres en forretningsrolle:
dataanvender en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, der med specifik hjemmel behandler data fra en datasamling til eget formål.
Rollen skal ikke forveksles med GDPR-rollen databehandler, der betegner en fysisk eller juridisk person,
en offentlig myndighed, en institution eller et andet organ, der behandler personoplysninger på den
dataansvarliges vegne
Derudover indgår nedenstående roller, som er defineret i Databeskyttelsesforordningen:
den registrerede den person (datasubjekt), som oplysningerne vedrører (rolle fra GDPR)
dataansvarlig en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, der alene eller sammen med andre afgør, til hvilke formål og med hvilke hjælpemidler der må foretages behandling af personoplysninger (rolle fra GDPR)
Endelig berøres en rolle, som i øvrigt ikke er beskrevet i detaljer i denne referencearkitektur:
registrator rolle som bringer oplysninger på digital form
Det skal bemærkes, at begrebet registrator ikke har en udbredt anvendelse og ikke kan genfindes i lov-
givning. Begrebet er alene medtaget for at beskrive videregivelse i en bredere kontekst af en datasamlings
livscyklus.
Ovenstående tager udgangspunkt i, at det er persondata, der behandles. Der findes imidlertid mange
typer af data, der ikke er personhenførbare. I et sådant tilfælde falder den registrerede væk fra ovenstående
billede, sammen med de GDPR-relaterede handlinger ret, begræns anvendelse og få indsigt.
Aktørerne ved deling af data og dokumenter er:
— Offentlige myndigheder (herunder virksomheder, der handler på vegne af offentlige myndighe-
der). Kan typisk være dataansvarlig eller dataanvender, men også ofte agere som registrator.
— Borgere – oftest i rollen som den registrerede, men også som registrator.
— Virksomheder som dataanvendere, særligt i forbindelse med private tjenester, der anvender oplys-
ninger registreret i offentligt regi i forbindelse med at levere ydelser til den registrerede., men også,
når anvendelsen er for virksomhedens egen skyld. Og som databehandlere, når de leverer løsninger
og services til offentlige myndigheder.
3.5 Tværgående processer I ovenstående diagram over centrale use cases er videregivelse den væsentligste, da den rummer selve
delingen af data. Dykker man ned i den, findes den i to grundvarianter, hhv. videregivelse på forespørgsel
og videregivelse ved meddelelse. Figuren nedenfor beskriver disse to varianter på procesform og knytter
dem tillige sammen med en kort beskrivelse af processen registrering af data.
22
Figur 7: Overblik over de centrale processer for videregivelse af data og deres aktiviteter fordelt på roller
Nedenfor er de to grundvarianter for videregivelse af data, videregivelse på forespørgsel og videregivelse ved
meddelelse, beskrevet i detaljer. Registrering af data er ligeledes beskrevet, dog mere summarisk, da den i
kontekst af denne referencearkitektur kun er med af referencehensyn.
3.5.1 Videregivelse på forespørgsel
Denne proces dækker, at en dataanvender - typisk en myndighed, men kan også være en virksomhed -
søger adgang til data, der på forhånd er til stede og kan gøres tilgængelige af en dataansvarlig.
videregivelse på forespørgsel integrationsmønster hvor data videregives af dataansvarlig på forespørgsel på anvenders initiativ
De indgående procestrin er:
behov opstår
Processen starter hos dataanvender, der identificerer et behov for at indhente data. Dette behov
opstår typisk i kontekst af andre processer, som vi ikke specificerer nærmere her, men som indbe-
fatter sagsbehandling, selvbetjeningsløsninger, analyser og meget mere.
forespørg om data
Dataanvender sender en forespørgsel på data, der beskriver, hvilke data der ønskes. Ved adgang til
andet end åbne data skal den nødvendige hjemmel foreligge, fx fremgå af forespørgslen, så dataan-
svarlig kan håndhæve den nødvendige adgangskontrol. Forespørgslen kan i praksis ske ved anven-
delse af flere meddelelser, eksempelvis ved kriteriebaseret søgning forud for, at data hentes, eller ved
at starte med en forespørgsel til et indeks, der udpeger relevante dataservices, hvorfra data kan hentes.
vurder adgang
Dataansvarlig myndighed vurderer i dette trin forespørgslen med henblik på at håndhæve adgangs-
kontrol. Kun, hvis den foreliggende hjemmel giver lovmæssig adgang til de forespurgte data, kan
dataansvarlig fortsætte til videregivelsen. Hjemlen kan være eksplicit angivet eller ligge implicit i bru-
gerstyringen. Hjemlen kan enten give generel adgang til en given datasamling eller til specifikke data i
samlingen, hvorfor der i mange situationer vil være behov for at se på hjemlen og de efterspurgte
data i sammenhæng for at håndhæve adgangskontrollen. Et særligt aspekt i at vurdere adgang er
håndhævelsen af 'negativt samtykke', hvor adgang til bestemte data er fjernet, fx fordi datas korrekt-
hed er bragt i tvivl og skal undersøges. Dette procestrin kan i øvrigt benyttes af dataansvarlig til at
håndhæve adgangskontrol også på andre planer som håndhævelse af en Service Level Agreement,
beskyttelse mod misbrug, mistænkelig adfærd m.m. Det bemærkes endvidere, at dataansvarlig kan
have overladt distributionsopgave og de praktiske opgaver for håndhævelse af adgangskontrollen til
en datadistributør, hvilket i øvrigt ikke ændrer ved beskrivelsen af dette trin.
23
videregiv data
Dataansvarlig håndterer forespørgslen ved at slå data op i datasamlingen, evt. ved at sammenstille data
fra flere datasamlinger, og sender et svar tilbage til anvender. Delingen af data bliver logget af dataan-
svarlig, indbefattende hvilke data, der blev delt; til hvilken anvender; og med hvilken hjemmel. Det
bemærkes, at dataansvarlig ikke nødvendigvis er klar over, hvilket databehov forespørgslen har tjent
til at tilfredsstille - så længe, adgangen er legitim og foretaget på baggrund af gyldig hjemmel, har
dataansvarlig ikke behov for at kende til dataanvenders brug af data i den konkrete forespørgsel.
modtag svar
Dataanvender modtager svaret, der indeholder det efterspurgte data, fra dataansvarlig.
transformer data
Efter modtagelsen kan der være brug for at transformere de modtagne data til en model tilpasset
modtagerens processer og systemer. Transformeringen kan handle alene om tekniske formater og
navngivning af felter, involvere oversættelse mellem forskellige referencedata som fx klassifikationer
og endda oversættelser mellem forskellige identiteter af parter og aktører. Den Dataansvarlige leverer
ikke denne mapning, men bidrager til den ved at gøre egne modeller og referencedata tilgængelige
for anvenderen.
I forhold til trinnet ’vurder adgang’ bemærkes det, at hjemlen for en specifik forespørgsel fx fra én
myndighed til en anden kan være givet i love, forordninger, bekendtgørelser m.v. Det kan i sådanne
tilfælde være muligt at ”indbygge” hjemlen i integrationsdesignet, således at den anvendende myndighed
generelt gives adgang til data uden behov for at dokumentere hjemlen run-time. Dette fritager imidlertid
ikke dataansvarlig fra at sikre sig, at hjemlen til enhver tid vedbliver at være gyldig. En måde at sikre sig
dette på er ved at abonnere på ændringer i de relevante retskilder og på baggrund af sådanne ændringer
eventuelt opdatere sin adgangspolitik og integrationsdesign.
Når man skal vurdere processen videregivelse på forespørgsel, er følgende kvaliteter og kriterier de mest
væsentlige at forholde sig til:
- Identifikation: Det skal være muligt for både dataansvarlig og dataanvender at identificere hinanden
entydigt og sikkert.
- Adgangskontrol: Der skal være en effektiv adgangskontrol, der opfylder kravet til at kunne do-
kumentere en tydelig og nødvendig hjemmel
- Søgning: Dataansvarlig bør tilbyde en søgefunktionalitet, der tillader dataanvender at fremsøge data
effektivt, særligt hvor der samtidigt kan søges i ensartede datasamlinger hos flere dataansvarlige.
- Sammenstilling: Dataansvarlig kan, hvor det måtte være hensigtsmæssigt ift. specifikke behov,
vælge at sammenstille data fra flere datasamlinger og udstille en service, der tilbyder de sammenstil-
lede data. Sammenstilling af data forudsætter, at dataanvender har gyldig hjemmel til alle data, der
indgår i sammenstillingen.
- Indsigt: Processen skal understøtte effektiv indsigt i anvendelse, hvilket bl.a. kræver logning af
konkrete videregivelser af data
- Opbevaring: Dataanvender bør benytte den autoritative datasamling direkte hvis muligt. Herved
undgås, at der opbygges 'skyggekopier' af datasamlinger, der introducerer kompleksitet i forbindelse
med synkronisering, aktualitetsudfordringer m.m.
3.5.2 Videregivelse ved meddelelse
Denne proces dækker, at en afsender - typisk en myndighed eller en virksomhed - har behov for at sende
data (evt. i form af et dokument) til en modtager.
24
videregivelse ved meddelelse integrationsmønster hvor data videregives ved meddelelse af dataansvarlig på dennes initi-ativ
Generelt betragtet dækker videregivelse ved meddelelse både menneske til menneske-kommunikation
(kommunikation til borgere/virksomheder, kommunikation mellem sagsbehandlere som led i en sags-
gang m.v.), system til system-kommunikation (hvor meddelelse-mønsteret benyttes som ren teknisk in-
tegration), samt varianter, hvor enten afsendelsen eller modtagelsen af meddelelsen er automatiseret.
Til forskel fra videregivelse på forespørgsel starter denne proces hos afsenderen (der tillige kan være data-
ansvarlig). Afsender har udvalgt og pakketeret data i en meddelelse (evt. helt eller delvist i form af et
dokument), adresserer meddelelsen (fx ved brug af et kontaktregister) og sender den herefter til modta-
ger.
afsender person eller organisation der sender en elektronisk meddelelse
modtager person eller organisation der modtager en elektronisk meddelelse
Modtager kan være alle typer af aktører; for myndigheder og virksomheder bemærkes, at det i forbindelse
med modtagelsen kan være relevant at fordele/route meddelelsen internt ud fra dens adresseringsoplys-
ninger. I sammenligning med videregivelse på forespørgsel er det nu afsender, der som den part, der deler
data, 'ejer' den fulde forretningskontekst - hvor den dataansvarlige ovenfor ikke var bekendt med formålet
med at dele data.
Det skal bemærkes, at en særlig form for videregivelse ved meddelelse medfører fuld overdragelse af data-
ansvaret. Dette er fx tilfældet, når en registrator (afsender) har opsamlet nye data og ønsker at registrere
dem i et register (modtager). Dette aspekt er dog ikke udfoldet yderligere i denne referencearkitektur, som
fokuserer på afsenders behov for at dele data ud fra et genbrugsperspektiv – ikke fra et overdragelses-
perspektiv.
De trin, der indgår i processen for videregivelse ved meddelelse, er:
behov opstår
Processen starter hos afsender, der - typisk i kontekst af en anden, overliggende proces - har behov
for at dele data ved at sende en meddelelse til en modtager.
dan indhold af meddelelse
Første trin er, at afsender danner indholdet af meddelelsen. Indholdet kan være data under kontrol
af afsender selv, men kan også indhentes fra andre via processen videregivelse på forespørgsel (der der-
med bliver en underproces til videregivelse ved meddelelse, der i sig selv typisk også er en underproces).
adressér meddelelse
Dette trin giver mulighed for at angive en slutmodtager for meddelelsen, der kan være mere specifik
end blot modtager. Som eksempel kan modtager i nogle tilfælde være en organisation, og der kan være
behov for at specificere en bestemt ansat som modtager En del af dette procestrin kan være at søge
oplysninger i et kontaktregister for entydigt at identificere modtager, undersøge modtagers evne til at
håndtere forskellige meddelelsesformater, identificere modtagers præference mht. sprog m.m.
afsend meddelelse
Afsendelse af meddelelsen sker i dette trin. Afsender er ansvarlig for at logge hvilke data, der er sendt,
til hvem, de er sendt, og med hvilket formål/hjemmel. Implicit i trinet ligger, at videregivelsen af
data er lovmedholdelig, hvilket er ensbetydende med at sige, at modtager har et legitimt formål med
at modtage data. Ansvaret for dette påhviler afsender.
modtag meddelelse
25
Meddelelsen ankommer hos modtager. Der kan afsendes kvittering for modtagelse, hvorved afsender
er garanteret, at meddelelsen er nået frem. (Det kan i nogle tilfælde være fordelagtigt at sende endnu
en kvittering, der bekræfter, at meddelelsen også kunne parses og indholdet kan accepteres. Dette
betragtes i denne sammenhæng som en del af fejlhåndteringen omkring integrationer i tværgående
processer og er ikke beskrevet yderligere i denne referencearkitektur.)
fordel meddelelse
Modtager har mulighed for at benytte oplysningerne i meddelelsen til at fordele meddelelsen internt.
Meddelelsen kan være et svar på en tidligere fremsendt forespørgsel. Er dette tilfældet, har modtager
behov for at sammenknytte meddelelsen med den kontekst, fra hvilken den oprindelige forespørgsel
blev sendt.
transformer data
Efter modtagelsen vil der typisk være brug for at transformere de modtagne meddelelser og data
til en model tilpasset modtagerens processer og systemer. Transformeringen kan handle alene om
tekniske formater og navngivning af felter, involver oversættelse mellem forskellige referencedata
som fx klassifikationer og endda oversættelser mellem forskellige identiteter af parter og aktører.
Den Dataansvarlige leverer ikke den oversættelse, men bidrager til den ved at gøre egne modeller og
referencedata tilgængelige for anvenderen.
Når man skal vurdere processen videregivelse ved meddelelse, er følgende kvaliteter og kriterier de mest
væsentlige at forholde sig til:
- Identifikation: Der bør være fuld sikkerhed for identifikation af afsender og modtager, understøt-
tet gennem brugerstyring, kontaktregister eller lignende.
- Integritet: Indholdet i en meddelelse skal være beskyttet mod ændringer foretaget, mens meddelel-
sen er på vej fra afsender til modtager.
- Leverancesikkerhed: Der skal være en tydeligt specificeret leverancesikkerhed, særligt relevant i
situationer, hvor meddelelser skal kunne afleveres uafviseligt fx i forbindelse med retslig forkyn-
delse.
- Sporbarhed: Der skal være et klart revisionsspor i logs for meddelelsers vej gennem systemet, bl.a.
for at understøtte klarhed over, hvornår meddelelser er overført og ansvaret for eventuel videre
behandling dermed overgået til modtager. Evt. kan loggen understøtte en 'track and trace'-funkti-
onalitet.
- Automatisering: Meddelelser bør være velstrukturerede og understøtte automatisering på modta-
gers side, fx ved at gøre data til fordeling/håndtering af meddelelser tilgængelig i en meddelelses-
header.
3.5.3 Registrering af data
Denne proces dækker de overordnede trin i at registrere data. Procestrinene er ikke foldet så meget ud
som for de øvrige use cases, da registrering af data ikke falder i scope for denne referencearkitektur. Dog
er en kort beskrivelse medtaget for reference på grund af den tætte sammenhæng mellem registrering og
udstilling af data. Procestrinene er:
registrer data
En registrator er i besiddelse af data, der skal registreres hos en dataansvarlig. I denne sammenhæng
skelnes ikke mellem, om registreringen angår ny data eller ajourføring i form af ændringer til data (i
sidstnævnte tilfælde kan det være den registrerede, der agerer som registrator.)
modtag data
26
Den dataansvarlige myndighed modtager data fra registratoren. I denne forbindelse skelnes ikke mel-
lem, om data modtages automatisk eller manuelt. I begge tilfælde er den dataansvarlige ansvarlig for
at håndhæve adgangspolitik og herunder sikre, at registratoren har gyldig hjemmel til at fremsende
registreringen.
valider data
Den dataansvarlige myndighed validerer de modtagne data. Den dataansvarlige kan have varierende
krav til datas kvalitet og komplethed, afhængig af formålet med datasamlingen. Fejlscenarier, hvor
data ikke kan valideres, dækkes ikke af denne referencearkitektur.
udstil data
Når data er korrekt registreret, skal de udstilles (under antagelse af, at den pågældende datasamling
er udstillet). Her kan der være forskel på, om data gøres tilgængelige øjeblikkeligt eller først på et
senere tidspunkt (fx ved registrering af fremtidigt skift af adresse). Begge muligheder kan være rele-
vante, og vil i mange tilfælde afhænge af dataanvenderens typiske behov. Udstillede data skal i øvrigt
være forberedt til transformation og sammenstilling med andre data. Dette gøres ved at udstille an-
vendte datamodeller og referencedata for anvendere.
Når man skal vurdere processen registrering af data, er følgende kvaliteter og kriterier de mest væsentlige
at forholde sig til:
- Identifikation: Sikker identifikation af registrator (så dataansvarlig kan håndhæve adgangskontrol)
og dataansvarlig (så registrator kan have tillid til, at de potentiel følsomme data ender hos rette mod-
tager).
- Sikkerhed: Tillid til, at data når ukompromitteret frem, herunder tjek af registreringens integritet,
mulighed for kryptering af følsomme data, transaktionssikkerhed m.m.
- Kontekst: I hvilken kontekst er data skabt/opsamlet - hvor og af hvem?
- Kvalitet: Hvilke krav er der til datas komplethed, hvordan valideres i forhold til datatyper, og er
registreringens granularitet passende?
- Øvrig anvendelse: Baseret på datas følsomhed, fortrolighedsniveau m.m. kan der være mulighe-
der for anvendelse af data ud over den primære anvendelse. Er data lagret og udstillet på den mest
hensigtsmæssige måde, der ikke begrænser genbrug unødigt? Er den datasamling, hvori registrerin-
gen indgår, velbeskrevet i et katalog?
3.5.4 Hybrid-varianter
I dette dokument betragter vi de ovenstående to processer for videregivelse af data hhv. på forespørgsel
og ved meddelelse som de atomare grundelementer, der er nødvendige for at kunne beskrive og tale om
videregivelse af data.
Det er dog værd at bemærke, at der i praksis kan skabes 'hybrid-varianter' af de to processer, der kan
være velegnede i særlige situationer. Som eksempler kan nævnes:
- Forespørgsel via meddelelse: Processen videregivelse på forespørgsel kan i simpel form imple-
menteres gennem to anvendelser af processen videregivelse ved meddelelse, i det den første medde-
lelse udgør forespørgslen og den anden meddelelse udgør svaret. Dette procesmønster kan være re-
levant for ad hoc-forespørgsler, der ikke er fuldt it-understøttede, eller i scenarier, hvor processen
med at forberede svaret er tidskrævende, og det derfor er hensigtsmæssigt at lave en fuld, asynkron
afkobling af forespørgslen og svaret. Procestrinet fordel meddelelse bliver i denne sammenhæng en
opgave om at sammenkæde svaret med den oprindelige, tilhørende forespørgsel.
27
- Videregivelse via link til data: Denne proces er en variant af videregivelse ved meddelelse, hvor
der imidlertid ikke sendes data direkte i meddelelsen, men i stedet et link til, hvor data kan hentes.
Linket kan enten være til en særligt forberede 'pakke' af data, fx i form af et dokument, eller til
specifikke data, der er relevante for modtageren i den givne sammenhæng. Modtageren vil herefter
kunne hente data gennem processen videregivelse på forespørgsel. Dette procesmønster kan fx være
relevant, hvis man ønsker et ekstra lag af sikkerhed ved at undgå, at data kopieres fra datasamlingen
til en meddelelse, hvilket giver en ekstra, sikkerhedsmæssig angrebsvektor (jf. GDPR-princippet
privacy by design).
3.6 Forretningsobjekter og begreber Når processerne omkring videregivelse af data skal implementeres, er der en række begreber, det er
væsentligt at holde styr på gennem god modellering. De fleste af begreberne er defineret, hvor de an-
vendes første gang i denne referencearkitektur. Dette afsnit nævner eksplicit en række elementer, der
beskriver data, der enten overføres eller opbevares i forbindelse med processer (forretningsobjekter).
Figur 8: Model med centrale begreber omkring videregivelse af data
Denne referencearkitektur definerer en række forretningsobjekter, uden at gøre dem til genstand for en
decideret datamodellering. Specifikationen af nogle af disse vil følge af de standarder, tekniske specifi-
kationer og anvendelsesprofiler, der vælges i den konkrete implementering. Andre vil kunne modelleres
inden for et enkelt domæne. Og endelig vil nogle kunne modelleres i et fællesoffentligt domæne. Beslut-
ninger herom overlades til en yderlig konkretisering af visionen for den fællesoffentlige digitale infra-
struktur.
28
datasamling en samling af oplysninger bestående af enkelte dele der forvaltes under et
Beskrivelsen af en datasamling bør understøtte design af løsninger og integrationer, offentlighedens ind-
sigt i data hos myndigheder samt den registreredes indsigt i formålet med registreringen. I regi af Digita-
liseringsstrategien arbejdes der medio 2018 på en datamodel for beskrivelser af datasamlinger.
log datasamling der beskriver de faktiske, historiske behandlinger af data i en given datasamling, herunder med hvilken hjemmel, behandlingen er sket
De enkelte log-linjer bør indeholde oplysninger nok til at understøtte den registreredes ret til indsigt i
videregivelse af persondata. I regi af Digitaliseringsstrategien arbejdes der medio 2018 på en datamodel
for log-linjer.
meddelelse formel besked der sendes elektronisk med veldefineret sikkerhed, tillid, integritet og leve-rance-sikkerhed
Meddelelser bør som minimum have en struktureret indhold, der gør det muligt automatisk at distribuere
den enkelte meddelelse.
påmindelse en besked der får modtager til at tænke på en vigtig begivenhed
adresse angivelse af hvor en person eller organisation ønsker at modtage bestemte typer af medde-lelser
forespørgsel meddelelse der sendes til en dataservice med forventning om svar indeholdende specifikke data
svar meddelelse dannet af dataservice som besvarer en forespørgsel
dataabonnement specifikation der anvendes til at filtrere hvilke beskeder om ændringer til en datasamling der ønskes
Diagrammet rummer en række øvrige elementer, der knytter sig til og grænser op til de ovenfor be-
skrevne. Dels en række begreber taget fra Databeskyttelsesforordningen, dels en række begreber beskre-
vet i Referencearkitektur for brugerstyring (begge markeret med blå skrift).
Endelig er der i arbejdet med denne referencearkitektur blevet identificeret en række yderligere begreber,
der kan gøres til genstand for begrebsmodellering: begrebs- og datamodel, registeroplysning, dokument,
registreringsbegivenhed, forretningshændelse/begivenhed, klassifikation, fuldmagt og generelle samtyk-
ker.
29
4 Teknisk arkitektur
Dette afsnit beskriver, hvordan de forretningsmæssige processer, begreber og objekter beskrevet i det
forrige afsnit kan udmønte sig i konkrete applikationsservices. Dette leder samtidigt til et overblik over
de områder, hvor der er behov for standardisering. Vi supplerer dette overblik med en oversigt over
eksisterende standarder og specifikationer, der allerede er i anvendelse i den offentlige sektor.
I næste afsnit beskrives først det minimale sæt af nødvendige applikationsservices, der kan bruges til at
realisere de tværgående processer, der er beskrevet tidligere. For hver af de to processer for videregivelse
af data beskrives først et basalt implementeringsmønster, og herefter yderligere to, mere avancerede
mønstre. De avancerede mønstre kræver ekstra roller og applikationsservices, som vil blive introduceret
løbende.
Implementeringsmønstrene, der beskrives i denne referencearkitektur, er:
Forretningsmøn-
ster
Implementeringsmøn-
ster Beskrivelse
Videregivelse på fo-
respørgsel
Direkte adgang Data videregives ved, at en dataanvender forespør-
ger direkte mod den dataansvarliges system
Datadistributør
Den dataansvarlige har overdraget videregivelsen af
data til en distributør, der servicerer forespørgsler
fra dataanvendere
Fælles service- og data-
platform
Data opbevares og videregives på forespørgsel fra
en fællesoffentlig, distribueret platform
Videregivelse ved
meddelelse
Direkte forsendelse
Data videregives i en meddelelse fra afsender til
modtager via en sikker, direkte, punkt til punkt-for-
bindelse
Fælles system
Meddelelsen med data holdes i dette mønster af et
fælles system, der tilbyder postkasser til afsender og modtager (fx Digital Post)
Servicefællesskab
En række forsendelsesservices, der er koblet sam-
men i et servicefællesskab (udbudt i et økosystem af
serviceudbydere), og som tilbyder udveksling af
meddelelser indeholdende data. Hver serviceudby-
der kan betjene et antal afsendere/modtagere
Ud over den tekniske beskrivelse angives der for hvert mønster en kort forretningsmæssig diskussion
af fordele og ulemper. I en konkret anvendelsessituation kan denne diskussion benyttes som vejledende
input i forhold til valg af implementeringsmønster.
30
4.1 Nødvendige applikationsservices Applikationsservicen datasamling samt tilhørende log og brugerstyring udgør de nødvendige applikations-
services for at implementere processen videregivelse på forespørgsel i en simpel form. Derudover er appli-
kationsservicen selvbetjening inkluderet som en praktisk nødvendighed for at kunne tilbyde den registre-
rede effektiv indsigt i anvendelsen af data om vedkommende. For at implementere en simpel form for
videregivelse ved meddelelse er også applikationsservicen forsendelse (samt tilhørende log og brugerstyring
hos afsender og modtager) nødvendig.
Derudover kan der indgå andre, understøttende services i en given løsning til videregivelse af data, der
kan være fordelagtige at implementere for at øge tilgængelighed, performance, brugervenlighed m.m.
Figur 9: Oversigt over de fem nødvendige applikationsservices til understøttelse af videregivelse af data, både på forespørgsel og ved meddelelse.
De indgående applikationsservices kan på kort form defineres som:
dataservice applikationsservice der videregiver oplysninger fra datasamling på forespørgsel under hånd-hævelse af nødvendig adgangskontrol
forsendelses(-service) applikationsservice, der gør det muligt at sende og modtage meddelelser samt dokumente-rer behandlingen af disse, herunder leverer bevis for afsendelse og modtagelse af dataene, og som beskytter dem mod tab, tyveri, beskadigelse og uautoriseret ændring
logning applikationsservice, der konsoliderer og formidler data om ændringer, videregivelse og an-vendelser af data fra en given datasamling
brugerstyring forretningsfunktion indeholdende nødvendige applikationsservices til administration og an-vendelse af identiteter og rettigheder (jf. Referencearkitektur for brugerstyring, 2017).
selvbetjening applikationsservice, der implementer en sammenhængende række af aktiviteter
Som nævnt i afsnit 1.2 er partsrepræsentation ikke i scope for denne referencearkitektur, og det vil derfor
ikke blive foldet yderligere ud. Vi bemærker dog, at emnet er relevant i flere af de ovenstående applika-
tionsservices omkring håndhævelse af adgangskontrol, logning af anvendelse, adgang og design af selv-
betjeningsløsninger m.m.
31
4.1.1 Ønskelige egenskaber ved videregivelse (både ved meddelelse og på forespørgsel)
Dette afsnit sætter flere ord på de kvaliteter, der grundlæggende knytter sig til videregivelse af data. De
forskellige kvaliteter er her stillet op i sammenhæng med den relevante applikationsservice.
Datasamling: En datasamling er et helt centralt begreb i denne referencearkitektur og blev introduceret
allerede i afsnit 1.3. Når datasamlingen udgøres af dokumenter, kaldes den et repository. Udgøres den af
registreringer, kaldes den et register.
Datasamlinger er kendetegnet ved følgende, ønskede egenskaber:
— Identificeret og dokumenteret: Datasamlingen bør registreres som et Information Asset (jf. ISO
27000). Registreringen dækker formålet med indsamlingen, og kategorier af personoplysninger
m.m.
— 'Forvaltningsegnede': Data i samlinger bør indeholde oplysninger om den kontekst, de er regi-
streret i, så anvender kan vurdere tilliden til dem. Samlinger kan have temporale og bi-temporale
egenskaber. Dette handler blandt andet om at holde styr på datas gyldighedsperiode og registre-
ringstidspunkt for fx at kunne understøtte dobbelt historik (overblik både over, hvad der var kor-
rekt på en given dato, og hvad registeret på et givent tidspunkt betragtede som korrekt på samme
tidspunkt).
— Beskyttet: Samlinger skal have deres deres data beskyttet på basis af adgangspolitik bestemt af den
dataansvarlige. Adgangskontrol er en funktion af identitet og attributter, herunder rettigheder og
roller. I praksis er der behov for et trade-off mellem et adgangspolitik-design, der udspringer af den
enkelte datasamling, og et design, der i stedet tager udgangspunkt i dataanvenders fx ved at anvende
eksisterende trusted attributes fra andre samlinger hvis muligt. Anvenderperspektivet er relevant ek-
sempelvis, hvor flere datasamlinger skal integreres i samme, tværgående proces. Referencearkitektur
for Brugerstyring under Den fællesoffentlige digitaliseringsstrategi 2016-2020 har bl.a. til formål at
lægge fælles rammer for adgangspolitik, der understøtter fællesoffentlig interoperabilitet.
— Robust og kontrolleret: En god datasamling kan (som applikationsservice betragtet) sikre sig mod
overforbrug. Rimelig brug er beskrevet i aftaler, der kan være generelle eller bilaterale i forhold til
en bestemt anvender. Ud over en passende håndhævning af den juridisk bestemte brug skal en
datasamling også på det tekniske niveau kunne sikre robusthed imod perioder med høj belastning
samt deciderede forsøg på blokeringer af tekniske services.
Forsendelse: Skal generelt kunne distribuere en meddelelse fra en afsender til en modtager. I praksis kan
behovet være at understøtte menneske til menneske-kommunikation, system til system-kommunikation,
eller varianter, hvor enten afsendelsen eller modtagelsen af meddelelsen er automatiseret. Kaldes også en
Messaging Service i den europæiske interoperabilitetsreferencearkitektur EIRA, samt en elektronisk leverings-
tjeneste i eIDAS.
Gode egenskaber omkring forsendelse inkluderer:
— Identifikation af afsender og modtager: Entydig identifikation ved brug af elektronisk signatur
eller id.
— Integritet: Understøttelse af, at meddelelsen som udgangspunkt leveres i sin oprindelige form uden
at være blevet ændret in-flight - sekundært, at ændringer har fuld sporbarhed.
— Sporbarhed: Tidspunkter for afsendelse og modtagelse samt relevante, øvrige punkter/handlin-
ger i distributionskæden logges. Tidsstempler i distributionskæden er kvalificerede (jf. eIDAS).
32
— Kvalificeret tillidstjenesteudbyder: Der bruges kvalificerede (godkendte og underlagt tilsyn) tje-
nester for elektronisk signering, elektronisk segl, leverance m.m. hvor muligt og relevant (jf. eI-
DAS)
— Aftaler: Når der designes forsendelsesmønstre, er det vigtigt at forholde sig til behovet for en
aftale, der regulerer den samlede forsendelse og dermed videregivelsen af data. Det kunne fx være
en aftale om modtagers pligt til at tømme sin postkasse. Lov om Digital Post er et konkret eksempel
på et juridisk instrument, der forpligter modtager til at åbne sin post i og med, at en meddelelse her
er uafviselig og kan have retsvirkning. Aftaler kan være bi- eller multilaterale.
Log: Applikationsservicen log (i EIRA-termer: Logging Service) har følgende gode egenskaber:
— Understøttelse af ret til indsigt: En log skal i denne sammenhæng kunne understøtte den for-
retningsmæssige indsigt i data og deres faktiske anvendelse. Herunder, hvor data (registreringer eller
dokumenter) stammer fra samt konkrete videregivelser og deres hjemmel. Understøttelsen er ekstra
stærk, hvis en log er opbygget brugercentrisk og designet til at være umiddelbar forståelig
— Integritet: At den ikke kan ændres/forfalskes. Dette gør fx loggen anvendelig som juridisk bevis
for, at en meddelelse er overført og at modtageren dermed har overtaget et eventuelt ansvar for
videre behandling.
— En log kan indeholde personhenførbare data og andre følsomme oplysninger og skal derfor være
behørigt beskyttet.
Brugerstyring: Generelt er brugerstyring som forretningsfunktion beskrevet i Referencearkitektur for
Brugerstyring, og gode egenskaber ved brugerstyring vil derfor ikke blive beskrevet nærmere her. I kon-
tekst af deling af data og dokumenter er brugerstyring central for at kunne identificere afsender/dataan-
svarlig samt modtager/dataanvender entydigt. Derudover er det i forbindelse med den registreredes indsigt
i anvendelse af data om sig selv interessant at overveje identitetsstyringen på tværs af de logs, der rummer
information om anvendelsen af data fra forskellige samlinger. Et brugercentrisk design har som forud-
sætning, at brugerens identitet kan anvendes på tværs af logs og kræver dermed, hvis de enkelte logs
opererer med servicespecifikke id'er, at identiteter kan henføres til fysiske personer.
Selvbetjening: En forudsætning for sammenhænge og effektiv betjening af borger og virksomheder –
også i forbindelse med videregivelse af data – er brugervendte selvbetjeningsløsninger. Disse er genstand
for en selvstændig fællesoffentlig referencearkitektur, men er medtaget her for at understøtte den regi-
streredes ret til indsigt i behandling af persondata. Selvbetjening er også en forudsætning for at kunne afgive
og administrere samtykker effektivt og sammenhængende – hvilket i øvrigt er uden for scope af denne
referencearkitektur.
4.2 Implementering af videregivelse på forespørgsel Når en dataanvender (virksomhed eller myndighed) har brug for adgang til data hos en dataansvarlig myn-
dighed, kan det ske via ét af nedenstående tre implementeringsmønstre.
4.2.1 Direkte adgang
Hvis målet for en anvender er at benytte data fra en specifik datasamling hos en bestemt dataansvarlig
myndighed, som måske i forvejen har gjort data tilgængelige via en simpel dataservice med tilhørende log,
og som har et ønske om selv at forestå videregivelsen af data, kan mønsteret direkte adgang være relevant.
33
Figur 10: Implementeringsmønster for direkte adgang til en datasamling
I dette mønster, som er simpelt og måske det mest klassiske, er det dataansvarlig, der selv udstiller sin
datasamling (gennem en simpel dataservice, der for overblikkets skyld er udeladt på Figur 10) for at tilbyde
en anvender at få adgang til data via en service-orienteret snitflade. Dataansvarlig er også ansvarlig for at
betjene den registreredes forespørgsler om indsigt i den dataansvarliges og alle dataanvenderes brug af per-
sonlige data ved at registrere anvendelse af data i en log. (Hvordan, log-informationerne gøres tilgænge-
lige for den registrerede er ikke defineret nærmere her – se diskussion af portal-komponenten i afsnit
4.2.2.)
Fordelen ved dette mønster er først og fremmest, at det er simpelt. Fra dataansvarligs synspunkt tilbyder
mønsteret endvidere en meget tæt kontrol med adgang til data, hvilket måske kan være ønskværdigt.
Udfordringerne ved mønsteret er bl.a., at dataansvarlig kommer til at bære hele udgiften ved at stille data
bredt til rådighed. Dette er specielt relevant, hvis det ikke er den dataansvarliges primære kompetence at
vedligeholde og drifte en applikationsplatform. Endvidere kræver genbrug af data, at dataansvarlig indgår
bilaterale aftaler med nye anvendere, hvilket giver ekstra arbejde til dataansvarlig uden nødvendigvis at
medføre en gevinst. Fra anvenders perspektiv er det en ulempe, at anvender selv skal håndtere en even-
tuel, nødvendig transformation af data, samt at sammenstilling med data fra andre datasamlinger påhviler
anvender. Fra den registreredes perspektiv er det en konsekvens af dette mønster, at det er vanskeligt at
få et samlet overblik over anvendelse af egne data på tværs af datasamlinger.
Næste mønster adresserer en række af udfordringerne ved direkte adgang.
4.2.2 Datadistributør
Hvis man ønsker en situation, hvor anvender kan hente data fra en dedikeret datadistributør, der afløfter
en væsentlig del af byrden ved videregivelse af data fra den dataansvarlige myndighed, og hvor man har
mulighed for at designe anvendelsesorienterede dataservices, der evt. kombinerer data fra flere datasam-
linger i et format, der er tilpasset anvenders behov, er mønsteret datadistributør relevant at overveje.
34
Figur 11: Implementeringsmønster, der introducerer en datadistributør
I dette mønster er dataansvarlig fortsat ansvarlig for at tilbyde en service til registrering af data. Udstillin-
gen af data overfor anvendere varetages derimod af en datadistributør (evt. flere). Dette giver datadistribu-
tøren mulighed for at fokusere netop på distributionen, dvs. at gøre data bredt tilgængelige for dataan-
vendere – dog naturligvis under håndhævelse af adgangskrav specificeret af dataansvarlig. I databeskyttel-
sesforordningstermer er datadistributøren dermed en databehandler.
En typisk fordel ved dette er, at det giver mulighed for at designe en dataservice målrettet anvenders behov
- hvilket evt. kan betyde, at dataservicen aggregerer data på tværs af flere datasamlinger. Sker dette, er
datadistributør naturligvis ansvarlig for, at adgangskrav fra alle de indgående datasamlinger/dataansvarlige
håndhæves for den aggregerede service.
Når nye data registreres, har den dataansvarlige ansvar for at opdatere kopien af datasamlingen hos datadi-
stributøren. Afhængigt af anvenders behov for aktualitet kan det ske i forbindelse med registreringen
(hændelsesbaseret, fx i en EDA-arkitektur) eller på fastlagte tidspunkter (batchbaseret). For batch-møn-
steret skal det overvejes, om der foretages en fuld kopi af den autoritative datasamling i forbindelse med
opdatering, eller om det kun er ændringer siden seneste opdatering, der sendes (delta-kopi).
I det tilfælde, hvor ensartede datasamlinger ligger hos flere, separate dataansvarlige - eksempelvis sund-
hedsdata opbevaret i forskellige regioner - er det fordelagtigt fra anvenders perspektiv at anvende et indeks
for at sikre effektive opslag. Dataansvarlig opdaterer dette indeks, når en registrator opdaterer datasamlingen.
Logningsmæssigt er den enkelte distributørs opgave at logge dataanvenders forespørgsler på data. For at
sikre den registreredes mulighed for at få indsigt i anvendelsen ved henvendelse til den dataansvarlige, må
distributøren også sørge for overføre loggen til den dataansvarlige med henblik på konsolidering, så den
dataansvarlige kan opfylde den registreredes ret til indsigt. Hvis dataansvarlig kun benytter sig af én datadi-
stributør, kan ansvaret for at opfylde den registreredes krav om indsigt dog være aftalemæssigt uddelegeret
fra dataansvarlig til datadistributør.
Portal-komponenten er kun overordnet introduceret og behandlet i denne referencearkitektur. Grund-
læggende er det et interface mellem den registrerede og loggen, der har til formål at gøre anvendelsesin-
formationerne i loggen tilgængelig for den registrerede. Portalen er i dette afsnit vist som en selvstændig
komponent under den dataansvarliges kontrol. Hvis den dataansvarlige kun benytter sig af én datadistribu-
tør, er det – ligesom med loggen – muligt for den dataansvarlige at uddelegere ansvaret for portalen til
datadistributøren, hvorved portal-komponenten ville rykke ind i datadistributør-kassen.
35
Her introduceres:
distributør forretningsrolle der som databehandler giver anvendere adgang til data på vegne af den dataansvarlige
For en dataansvarlig med få, men hyppigt anvendte datasamlinger vil det være en forholdsmæssig stor
opgave at vedligeholde en dataservice. Der kan dermed være betydelige fordele ved at løfte opgaven via
en distributør.
distributionskopi forretningsobjekt som er en kopi af en datasamling, der opbevares hos databehandler med henblik på distribution efter instruks fra dataansvarlig
indeks applikationsservice som er en datasamling, der indeholder oplysninger om, hvilke datasam-linger der indeholder oplysninger om personer, virksomheder og andre forvaltningsobjekter.
Et indeks kan gå på tværs af flere datasamlinger, der kan have forskellige dataansvarlige. Ligeledes har
indekset (som er en datasamling) i sig selv en dataansvarlig, der ikke behøver at være sammenfaldende med
den/de aktører, der er dataansvarlige for de underliggende datasamlinger.
portal applikationsservice og selvbetjeningsløsning, der lader den registrerede have indsigt i dataan-vendelse m.m.
Fordelen ved dette mønster er først og fremmest, at det introducerer en dedikeret infrastrukturkompo-
nent for videregivelse på forespørgsel i form af en datadistributør, der har mulighed for at specialisere sig
fuldt og helt i distributionsopgaven. Hvis flere dataansvarlige vælger samme distributør, deles mange af
omkostningerne. Fra den dataansvarliges perspektiv gælder det endvidere, at en del af aftaleindgåelsen
kan afløftes til datadistributør, der i højere grad vil have mulighed for at anvende standardkontrakter.
De væsentligste udfordringer i dette mønster udspringer af, at man nu har skabt en kopi af en datasamling,
der skal vedligeholdes. Derudover bliver det en vanskeligere at konsolidere en anvendelseslog, når data
ligger fordelt på mere end én platform. Fra den dataansvarliges synspunkt medfører datadistributør-møn-
steret endvidere, at der introduceres et behov for styring/tilsyn med distributøren.
En specifik udfordring i forbindelse med dette mønster er, at det er muligt at lægge dette mønster ’i
forlængelse af sig selv’, hvorved man kan skabe en ny distributionskopi på basis af en eksisterende distri-
butionskopi. Selv om det i særlige tilfælde kan være rimelige eller nødvendige grunde til at benytte et
sådant mønster, kan det generelt ikke anbefales. Kopier af kopier introducerer ekstra kompleksitet i
opdateringer med mulige konsekvenser for datas aktualitet. Derudover bliver det markant vanskeligere
for dataansvarlig at håndhæve sit dataansvar, fx i forbindelse med ’retten til at blive glemt’, hvor GDPR
foreskriver, at dataansvarlig generelt set er ansvarlig for at kunne slette data på den registreredes anmod-
ning. Ligeledes bliver det vanskeligere for den dataansvarlige at understøtte den registreredes ret til indsigt
i anvendelse af data om ham/hende selv – hvilket i sidste ende kræver, at enhver n’te-ordens distributi-
onskopi skal implementere en fuld anvendelseslog, der skal kunne konsolideres bagud mod dataansvarlig,
og hvor ethvert ekstra lag af distributionskopier dermed introducerer yderligere kompleksitet, mulighed
for forsinkelser m.m. i forhold til, at dataansvarlig kan konsolidere anvendelse af data om den registrerede.
Bl.a. af disse årsager må ’kopi af kopi’-mønsteret kun anvendes efter nærmere aftale mellem datadistribu-
tør og dataansvarlig.
Det næste mønster søger at adressere nogle af de udfordringer, der ligger i at arbejde på en kopi af en
datasamling.
36
4.2.3 Fælles service- og dataplatform
Hvis man ønsker at benytte en dedikeret infrastrukturkomponent til distribution af data, men uden at
man ønsker at indføre en distributionskopi med den kompleksitet, det medfører – og hvis man har
mulighed for at lade dataansvarlig og dataanvender operere på samme platform, således at de respektive
datasamlinger ligger fysisk samlet, men logisk adskilt, kan mønsteret Fælles service- og dataplatform være
interessant.
Figur 12: Implementeringsmønster for fælles service- og dataplatform
Figuren viser, hvordan deling i dette mønster er håndteret af en fælles dataplatform. Platformen er distri-
bueret og er i stand til at replikere data på tværs af dataansvarlige og dataanvendere. Dvs., at data, der
registreres via en dataansvarlig myndighed, gøres tilgængelige for andre, dataanvendende myndigheder
via platformen.
Da dataplatformen kan rumme data fra mange forskellige dataansvarlige, muliggøres effektiv sammenstil-
ling af data hos dataanvenderen, der kan kombinere data fra egne samlinger med data fra andre samlinger.
i en anvendelsesorienteret dataservice. Data kan her forstås både som simple opslag i egne eller andres
datasamlinger, og som sammenstillinger, hvor data fra flere samlinger kombineres for at servicere dataan-
venders applikationer.
Platformen er ansvarlig for (på vegne af dataansvarlig) at håndhæve adgangskontrol, herunder at sikre, at
anvendelsesapplikationer har den nødvendige lovhjemmel til at tilgå en given, distribueret samling. Even-
tuelle services hos dataanvender, der gør brug af data, er ansvarlige for at logge deres brug. Platformen
konsoliderer brugs-loggen og gør det muligt for den registrerede at få overblik over brug af personlige
data.
Portalen er her vist som en del af dataplatformen. Der er for så vidt intet i vejen for at lægge portalen uden
for platformen og basere den på læs-interfacet til loggen. Denne variant åbner mulighed for, at portalen
kan konsolidere anvendelse af data på tværs af flere platforme. Dette kunne være interessant ud fra et
borger-orienteret UX-perspektiv, hvor anvendelsen af data måske kunne præsenteres i kontekst af det
selvbetjeningsforløb eller den sagsgang, der ledte til den specifikke videregivelse af data. Sådanne, mere
vidtgående aspekter af portalen er dog ikke foldet yderligere ud i denne referencearkitektur. Det væsent-
ligste er, at den registrerede gennem portalen får et interface til at få indsigt i anvendelse af personhenfør-
bare data.
Her introduceres:
37
platformsudbyder forretningsrolle der forvalter en fælles platform på vegne af flere aktører.
Fordelen ved dette mønster er den umiddelbare og standardiserede tilgængelighed til data, som en data-
platform kan levere. Derudover er det en fordel fra den registreredes synspunkt, at platformen konsoli-
derer loggen, så indsigten i anvendelse af data om en selv centraliseres.
Ulempen ved mønsteret er, at kompleksitet og governance (herunder audit) omkring den enkelte data-
samling øges, da den pludselig gøres tilgængelig meget tæt på andre dataansvarliges datasamlinger. Derud-
over stilles der større krav til dataanvenders modenhed ift. den tekniske adgang til data (da dataanvenders
applikationer i praksis vil skulle afvikles på den fælles service- og dataplatform).
4.3 Implementering af videregivelse ved meddelelse Når en myndighed vil initiere en specifik og målrettet videregivelse - dvs. sende data (herunder doku-
menter) til en anden myndighed, virksomhed eller borger - kan det ske via ét af de tre nedenstående
mønstre.
4.3.1 Direkte forsendelse
Hvis målet er at kunne sende meddelelser fra en afsender til få, kendte modtagere, hvor man har mulighed
for forud at opsætte en sikker og krypteret punkt til punkt-forbindelse fra afsender til modtager, og hvor
der ikke er forventning om den store, dynamiske ændring af modtager-kredsen, kan implementerings-
mønsteret direkte forsendelse være relevant. Dette mønster tilbyder den enkleste måde at videregive data
via en meddelelse på.
Figur 13: Implementeringsmønster for direkte forsendelse
Figuren viser de to procestrin ’afsend meddelelse’ og ’modtag meddelelse’ hos hhv. afsender og modtager.
Begge trin må understøttes af en lokal forsendelse-service, der kan tale direkte med modpartens, så der
skal på forhånd være enighed mellem de to parter om, hvordan distributionen realiseres. Procestrinet
’adresser meddelelse’ er ikke medtaget, da der ikke er nogen fælles understøttelse af dette. Det påhviler
dermed parterne selv at sikre modpartens identitet, hvilket typisk vil kræve en bilateral aftale.
Et eksempel på dette mønster er den type myndighed til myndighed-kommunikation, der kommunikerer
meddelelser fra afsender til modtager gennem brug af sikker e-mail. Her er det nødvendigt, at begge parter
på forhånd opsætter sikkerhed i form af nødvendige certifikater m.m. for at kunne håndhæve kryptering,
identitetskontrol m.m.
Fordelen ved dette mønster er, at det er simpelt og i høj grad har mulighed for at benytte sig af stan-
dardteknologi (fx sikker e-mail eller sikker FTP). Det vil typisk være baseret på bilaterale aftaler, der kan
rumme høj grad af fleksibilitet i forhold til særlige krav hos afsender eller modtager (SLA-krav, særlige
formater, afleveringsmønstre, fejlretningsprocesser osv.)
Udfordringerne ved dette mønster inkluderer, at implementeringen – både hvad angår den tekniske in-
tegration og dataformater – risikerer at blive skræddersyet til den specifikke løsning, hvilket typisk vil
38
være en forhindring for at kunne genbruge data i andre sammenhænge. Derudover er der ingen fælles
sikring af identiteter på afsender/modtager, og i det hele taget ingen fast platform at læne sig op ad hvad
angår leverancesikkerhed, standarder for funktionalitet, der kan muliggøre automatisk routing hos mod-
tagende virksomhed/myndighed i det tilfælde, hvor meddelelsen ikke har én specifik modtager, m.m.
Setup’et med bilaterale aftaler om punkt til punkt-forbindelser mellem afsender og modtager skalerer
heller ikke godt, hvis der pludselig bliver flere aftagere af den givne type data.
Næste mønster adresserer en række af udfordringerne ved Direkte forsendelse.
4.3.2 Fælles system
Hvis man som afsender har en bred og/eller varierende modtager-kreds på de meddelelser, der skal afsen-
des – hvis man fx skal designe standardkommunikation fra myndighed til borgere – og hvis man i øvrigt
ikke kan stille særlige krav til en forsendelsesservice, der på modtagers side kan håndtere modtagelse af
meddelelser, kan det være en fordel at anvende en infrastrukturkomponent i form af et fælles system.
Dette mønster tilbyder, at man kan genbruge en eksisterende infrastrukturløsning, der afkobler afsender
og modtager på det tekniske og i nogen grad også på det aftalemæssige plan, og som giver mulighed for
at benytte nye applikationsservices som fx notifikation og adresse.
Figur 14: Implementeringsmønster for fælles system
Ved brug af Fælles system-mønsteret til forsendelse af en meddelelse benytter afsender og modtager en
fælles forsendelsesservice til at sende meddelelsen, modtage den og eventuelt også læse den. I den analoge
verden svarer dette mønster til, at afsender og modtager benytter et fælles postbokskontor. Digitalt er
dette mønster fx implementeret af Digital Post, hvor såvel myndigheder, virksomheder og borgere kan
placere meddelelser, der efterfølgende kan hentes af modtager. Også messaging-funktionaliteten i mange
af de sociale medieplatforme (fx Facebook) falder i denne kategori.
Til forskel fra direkte forsendelse-mønsteret ovenfor er fælles system-mønsteret mere sikkert og robust, da
der tilbydes opslag/verifikation mod en identitets-baseret adresseservice for at bekræfte afsenders/modta-
gers adresse. Desuden kan infrastrukturen tilbyde, at meddelelsen opbevares, indtil modtager aktivt læser
den.
Forsendelsesservicen har endvidere mulighed for at trække på en notifikation, der kan tilbyde en indholds-
reduceret påmindelse til modtager om den nye meddelelse.
Et Fælles system-mønster kan fungere på mange niveauer, herunder nationalt (fx Digital Post); inden for
et specifikt domæne, fx på sundhedsområdet; eller rent bilateralt, hvor to organisationer enes om dette
mønster og vælger en passende meddelelsesplatform.
I dette mønster introduceres:
adresse (til forsendelse) applikationsservice som er en specialiseret datasamling (fx et kontaktregister), der indehol-der oplysninger til brug ved adressering af meddelelser
39
notifikation applikationsrolle der udsender påmindelser.
Selv om dette mønster har mange fordele – hovedsageligt, at det benytter sig af en forsendelses-infra-
struktur og en adresse-komponent, der kvalificerer afsender og modtager – er det ikke uden udfordringer.
Når man kigger ud over den enkelte afsenders og modtagers behov i forbindelse med at forsende en
enkelt meddelelse og kigger på platformen som helhed, opstår der paradoksalt nok en risiko, hvis plat-
formen vinder popularitet og bliver benyttet af mange myndigheder, virksomheder og borgere. En
”stor” løsning får en vis dominans, der kan føre til, at den i praksis bliver en silo – måske én blandt flere.
Hvis platformene ikke er designet til at være interoperable, har konkurrencen dårlige vilkår, og der er
risiko for at ende i en vendor lock-in-situation.
Det næste mønster sigter mod at adressere nogle af de infrastruktur-relaterede udfordringer i Fælles
system.
4.3.3 Servicefællesskab
Hvis man som afsender/modtager ønsker at etablere videregivelse af data ved meddelelse, og fra starten
ønsker at vælge en infrastruktur, der er designet til at være fleksibel, interoperabel og skalerbar, kan det
være en fordel at følge mønsteret Servicefællesskab.
Figur 15: Implementeringsmønster for servicefællesskab.
I dette mønster deltager både afsender og modtager i et meddelelses-fællesskab ved at vælge hver sin ser-
viceudbyder (eng. service provider) til forsendelse. Alle service providers indgår på forhånd i en infrastruktur i
form af et aftalemæssigt og teknisk servicefællesskab, der bl.a. garanterer fuld interoperabilitet i distributi-
onen. Mønsteret er bl.a. kendt i kontekst af den europæiske eDelivery-standard som en four corner model.
En fælles adresseservice udgør en central komponent i mønsteret, der gør det muligt for alle parter at slå
den relevante adresseringsinformation op. En afsender kan via adresseservicen se/verificere mulige mod-
tagere, samt evt. afgøre hvilken konkrete meddelelsesformater/kanaler, modtager kan håndtere. Forsen-
delsesservicen, der på infrastruktursiden håndterer distribution af meddelelsen, kan benytte adresseservicen
til at finde modtagers konkrete serviceudbyder og bliver dermed i stand til at levere meddelelsen.
Mønsteret vil typisk være symmetrisk, således at en afsender også kan indgå som modtager og vice versa.
Mønsteret kan i øvrigt enten være generisk eller specifikt for et domæne, der fx kan stille ekstra krav til
meddelelsens format. For eksempel benytter NemHandel sig af PEPPOLs eDelivery-netværk for at
kunne udveksle elektroniske fakturaer, kreditnotaer m.m. med internationale modtagere.
Fordelene ved servicefællesskab-mønsteret er, at det er en robust og fleksibel måde at levere asynkrone
meddelelser på, og at det skalerer godt, da det løbende kan udvides med nye serviceudbydere. Derudover
stilles der umiddelbart ingen krav til formatet af integrationen mellem en serviceudbyder og en afsen-
der/modtager – hvilket åbner for, at forskellige serviceudbydere kan tilbyde løsninger skræddersyet til for-
skellige behov, hvor nogle modtagere fx vil have et ønske om fuld automatisering, mens andre vil have
et ønske om et manuelt betjent interface.
Der er også udfordringer ved servicefællesskab-mønsteret. Der stilles fx store krav til servicefællesskabets
centrale adresseservice, hvilket kan medføre en kompliceret governance. Man er ligeledes afhængig af, at
40
der er en kritisk masse af brugere tilstede (og dermed tilgængelige) på platformen. Man skal også være
opmærksom på, at det generiske og robuste design, der typisk vil være i et servicefællesskab, måske ikke
altid vil være det rigtige valg, fx hvis man i en bestemt anvendelsessituation har helt særlige krav til
performance.
Samtidig er det for eDelivery-standarden en specifik udfordring, at etableringen primo 2018 fortsat er i
sin indledende fase, og at der dermed endnu ikke findes bredt anvendte standardteknologier, der dækker
mønsteret.
serviceudbyder forretningsrolle der stiller der stiller applikationsservices til rådighed
servicefællesskab forretningsrolle der regulerer services udbudt af en række serviceudbydere
4.4 Understøttende applikationsservices I de ovenstående mønstre er der introduceret en række yderligere services, der bidrager med forskellige,
ønskelige egenskaber ved implementeringsmønstrene (dataservices, distributionskopi, dataindeks, og notifi-
kationsservice). Fælles for disse er, at de oftest anvendes run-time i videregivelsen af data. Derudover vil
en række services, der ikke er medtaget i ovenstående mønstre, også kunne understøtte etablering og
vedligeholdelse af integrationer (referencedata, modelkatalog og datakatalog).
Figur 16: Det minimale sæt af applikationsservices, der er nødvendige for at kunne videregive data, samt øvrige, understøttende applikationsservices, der kan være fordelagtige at implementere i en given løsning
Figur 16 giver en samlet oversigt over de applikationsservices, der skal overvejes i forbindelse med vi-
deregivelse af data, fordelt på de nødvendige hhv. understøttende applikationsservices. For hver appli-
kationsservice er den generiske snitflade angivet. Da applikationsservices typisk indgår i flere implemen-
teringsmønstre, er det hensigtsmæssigt at kigge på standardisering af operationerne i snitfladerne. Der-
ved opnås en afkobling, der giver større fleksibilitet i forhold til senere re-design af en given løsning,
specifikt i forhold til, at et skift til et andet implementeringsmønster vil blive lettere, hvis snitfladen kan
opretholdes.
Udover de services der er beskrevet i kontekst af de enkelte mønstre, kan videregivelse af data med
fordel understøttes af en række andre applikationsservices.
referencedata datasamling der anvendes til at organisere eller kategorisere andre data, eller til at relatere udvekslede data med interne data.
Anvendelse af forudspecificerede udfaldsrum for de enkelte felter i udvekslede meddelelser bidrager til
at sikre den semantiske interoperabilitet gennem en fælles entydig forståelse af koder, begreber og lig-
nende. De indgår typisk ikke direkte ved udveksling af beskeder, men kan anvendes i forskellige former
for valideringer. Også i forbindelse registrering er referencedata og deres mapninger til interne data re-
levante. Referencedata kan videregives som alle andre datasæt.
41
datakatalog datasamling der beskriver datasamlinger og deres anvendelser af referencedata og datamo-deller.
Organisationer bliver i stigende grad afkrævet overblik over deres opbevaring af data gennem forskellige
former for regulering. Når data skal registreres, vedligeholdes og anvendes effektivt kræver det indsigt i
andre organisationers data. Datakatalog er datasamlinger der understøtter dette overblik.
modelkatalog applikationsservice der udstiller datamodeller og referencedata der anvendes i datasæt og i meddelelse.
Udvekslede data skal struktureres, og et modelkatalog kan udstille de anvendte datamodeller og deres
anvendelse af referencedata. Datamodeller bør overholde fælles modelleringsregler for at sikre den ind-
holdsmæssige kompatibilitet og dermed muligheden for sammenstilling af data og automatisk transfor-
mation.
hjemmel applikationsservice der understøtter håndhævelse af, at videregivelse af data sker ud fra korrekt hjemmel, samt den registreredes indsigt i anvendelse af persondata
Data må alene videregives på baggrund af gyldig hjemmel. Videregivelse skal logges med henvisning til
aktuel hjemmel, således at den registrerede efterfølgende kan få indsigt i, hvorfor data om vedkommende
er blevet videregivet (med hvilken hjemmel og til hvilken anvendelse).
Denne applikationsservice håndterer endvidere samtykker og fuldmagter, der i mange tilfælde kan ud-
gøre den nødvendige hjemmel til videregivelse. Den nærmere modellering og håndtering af samtykker
og fuldmagter sker i spændingsfeltet mellem brugerstyring og videregivelse af data og er ikke uddybet i
denne referencearkitektur.
4.5 Områder for standardisering Et af referencearkitekturens formål er at udpege områder, hvor standardisering i form af fælles anven-
delsesprofiler vil være særligt værdifuld. Både for videregivelse på forespørgsel og videregivelse ved medde-
lelse er der — set fra ‘forretningens’ synspunkt — en række snitflader, der går igen. Standardisering af
disse vil tillade anvender at anvende samme snitflader uanset hvilket implementeringsmønster, der rea-
liseres.
I udarbejdelsen af referencearkitekturen er der foretaget en delvis afdækning af de standarder, anvendel-
sesprofiler m.m., der pr. 2017 anvendes i den offentlige sektor. Lister over disse standarder er medtaget
for at beskrive og belyse de enkelte integrationstyper og kan benyttes til inspiration. De nævnte standar-
der skal dermed ikke ses som en hverken udtømmende eller autoritativ liste. For en nærmere beskrivelse
af begreberne omkring standardisering, se Bilag E: Om specifikationer, standarder og profiler.
4.5.1 Tekniske specifikationer
I forbindelse med udarbejdelsen af referencearkitekturen har arbejdsgruppen identificeret en række re-
levante, tekniske specifikationer, der som nævnt indledningsvist ikke skal ses som en autoritativ liste i
forhold til fremtidige anvendelser, men blot er inkluderet til inspiration og til at belyse området.
Adgang til dataservices
Særligt adgangen til dataservices, herunder til den særlige dataservice, der indeholder log, er værdifuld at
standardisere. En Dataanvender forholder sig typisk til data fra mange forskellige kilder, og det vil være
omkostningsfyldt at skulle anvende mange forskelligartede tekniske specifikationer.
42
— IHE XDS er en sundhedsspecifik profilering af ebXML Messaging Service Specifications med
anvendelse af HL7 CDA som dokumentmodel. IHE XDS er identificeret til anvendelse i offent-
lige udbud af EU. Specifikationer er profileret til dansk brug af Sundhedsdatastyrelsen og er i
anvendelse i 2018.
— OGC Webservice Standards er en geodataspecifik profilering af ebXML. INSPIRE direktivet
EU 2010/1089 forpligter medlemslandene til at udstille geodata i en fælles datamodel. Styrelsen
for dataforsyning og effektivisering implementerer specifikationerne for danske data.
— DK-REST er en profilering af en række webstandarder, herunder W3C’s HTTP-specifikation og
JSON (ECMA-404). Profilen udarbejdes af Digitaliseringsstyrelsen og afprøves i foråret 2018 i et
eller flere projekter under Digitaliseringsstrategien.
— HL7 FHIR er en international, sundhedsspecifik profilering af en række webstandarder, herunder
W3C’s HTTP-specifikation.
— Linked Data Platform 1.0 er en samling af W3C-specifikationer relateret til anvendelse af Re-
source Description Framework (RDF) over HTTP. De fællesoffentlige regler for begrebs- og da-
tamodellering indeholder en profilering af bl.a. RDF.
— OIO IDWS er en samling af profiler af SOAP og WS-Trust specifikationerne og er udviklet i
fællesoffentligt regi
Log over videregivelse
Ved videregivelse af persondata er dataansvarlig forpligtiget til at logge dette. Med henblik på muligheden
for at lade den registreredes ret til indsigt implementere som en selvbetjeningsløsning er det nødvendigt
at specificere indholdet af loggen.
— Vejledning om logning er en specifikation af minimumsindhold i logning ved videregivelse af
persondata udformet af Digitaliseringsstyrelsen i forbindelse med DK-REST.
— IHE ATNA er en sundhedsspecifik teknisk specifikation af snitflader til og indhold af logning.
Indeks over dokumenter
Ved registrering af dokumenter i indeks er det nødvendigt at have en fælles specifikation for data om
dokumenter.
— IHE XDS Metadata er en sundhedsspecifik profilering af ebXML Registry Information Model.
Sundhedsdatastyrelsen har yderligere profileret denne til dansk brug.
Meddelelse om ændring i datasamling
Hvis en dataservice tilbyder en dataabonnementsservice:
— IHE D-SUB er en international sundhedsspecifik profil af OASIS Web Services Notification.
— OIO hændelsesbesked er en teknisk specifikation af meddelelser om ændringer i datasamlinger.
Specifikationen er profileret af både KOMBIT og Styrelsen for dataforsyning og effektivisering.
Beskrivelse af datasamling
Datasamlinger kan beskrives i kataloger og oplysninger om samlinger og deres indhold kan udveksles
ved brug af tekniske specifikationer.
— ADMS er en anvendelsesprofil af DCAT til brug for beskrivelse af blandt andet datasæt. Digitali-
seringsstyrelsen har udarbejdet en DCAT profil til anvendelse i Det fællesoffentlige datasætkata-
log. ADMS anvendes tillige i EU, se https://joinup.ec.europa.eu.
43
— XMI er en XML-profil til beskrivelse af modeller. De fællesoffentlige regler for begrebs- og data-
modellering indeholder en profilering til brug ved udveksling af modeller.
Distribution af meddelelser
Ved distribution af meddelelser er det nødvendigt at specificere, hvordan de nødvendige egenskaber
opfyldes ved brug af tekniske specifikationer.
— AS4 er en profilering af ebMS til anvendelse ved elektronisk forsendelse af meddelelser. Profilen
er udviklet af PEPPOL og vedligeholdes i dag af OASIS.
Meddelelsesheader
Ved distribution af meddelelser anvendes ofte et standardiseret minimumsindhold eller ’elektronisk ku-
vert.’
— SBDH er en teknisk specifikation af indholdet en meddelelsesheader. Den er profileret til anven-
delse i dansk e-handel af Digitaliseringsstyrelsen. Specifikationen forventes erstattet af en kom-
mende fælles specifikation mellem OASIS og UN/CEFACT.
— Digital Post Meddelelsesmodel er en begrebsmodel til anvendelse i næste generation Digital
Post, der pr. 2018 er under anskaffelse af Digitaliseringsstyrelsen.
Adresser
Ved anvendelse af flere forsendelsesservices er det ønskeligt at have en standard for at finde hvilke
serviceudbydere, der kan modtage hvilke typer meddelelser på vegne af en modtager.
— Service Metadata Publisher (SMP) er en teknisk specifikation udgivet af OASIS og anvendes til
udstilling af oplysninger om modtagers services og deres ønskede anvendelser (Metadata Manage-
ment Services i EIRA). SMP er identificeret til anvendelse i offentlige udbud i EU. Specifikationen
er profileret i eDelivery og anvende blandt andet af PEPPOL.
— BDX Location er en teknisk specifikation udgivet af OASIS og beskriver i EIRA Service Disco-
very Services, der anvendes til at lokalisere Metadata Management Services (SMP’er). BDX Loca-
tion er identificeret til anvendelse i offentlige udbud i EU. Specifikationen er profileret i eDelivery
og anvendes blandt andet af PEPPOL.
— CorePartyID er den tekniske specifikation for angivelse af identifikation af modtager ved hjælp
af en URI og er profileret af PEPPOL til anvendelse ved forsendelse af elektroniske fakturaer i
EU.
Digitaliseringsstyrelsen har i efteråret 2017 gennemført en dokumentation af den danske offentlige sek-
tors datainfrastruktur, hvor flere datadistributørers løsninger beskrives.
Digitaliseringsstyrelsen har i 2017 gennemført en foranalyse om eDelivery-anvendelse i Danmark. Med
udgangspunkt i foranalysen er det besluttet at igangsætte analysefasen af et eDelivery-implementerings-
projekt. Analysefasen gennemføres i 2018 med fokus på strategiske gevinster samt fastlæggelse af tekni-
ske, organisatoriske og økonomiske rammer for en efterfølgende implementering og udrulning.
44
4.5.2 Øvrige standarder
Organisatoriske standarder og aftaler
Standardisering af Deling af data og dokumenter på det organisatoriske plan indbefatter bl.a. nedenstå-
ende elementer. Der har dog i udarbejdelsen af denne referencearkitektur ikke været muligt at gå i detaljer
med hverken afdækning eller specifikation af disse elementer.
— Aftale om systemtilslutning samt databehandleraftaler
— Samtykke til videregivelse af personoplysninger
— Specifikation af dataleverance
Semantiske standarder og begrebsmodeller
Standardisering på det semantiske niveau er nødvendig for at sikre, at systemer kan ’tale sammen’. Her
er det særligt vigtigt at fremhæve forskellige aspekter af informationssikkerhed som emner, der er vær-
difulde at adressere i et standardiseringsarbejde:
— Metadata for opslag/søgning/anvendelse samt kontekst
— Hjemmel (samtykke, lov)
— Kontekst (klassifikation af anvendelse)
— Klassifikation af følsomhed
45
5 Perspektivering
I dette afsnit fremhæves en række punkter, hvor arbejdet i denne referencearkitektur peger frem mod
yderligere initiativer, eller hvor indholdet i referencearkitekturen (fx set i kontekst af teknologitrends)
giver interessante fremtidsperspektiver.
— Anvendelse og genbrug af data i tværgående processer: Dette dokument centrerer sig om at
beskrive begreber og mønstre for den konkrete videregivelse af data. Imidlertid vil genbrug af data
typisk understøtte et konkret anvendelsesscenarie og dermed finde sted i kontekst af en proces,
der kan gå på tværs af myndigheder, virksomheder og borgere. En sådan proces vil, specielt hvis
den afvikles over tid, have sine egne udfordringer i forhold til indhentning, sammenstilling og
opbevaring af de data, der genbruges fra eksisterende datasamlinger. Disse udfordringer inklude-
rer:
– Klassifikation af samt konteksten for processen skal beskrives (er det en sag? et selvbe-
tjeningsforløb? en udbetaling af en ydelse?)
– Der er behov for principper omkring sikring af dataaktualitet (hvordan og hvornår tjek-
kes, om data indhentet tidligere i et procesforløb fortsat er aktuelle?)
– I hvilke situationer overdrages dataansvaret i forbindelse med en konkret videregivelse af
data?
– Der er behov for et designmønster til at sikre, at en svar-meddelelse i en dobbelt-anven-
delse af mønsteret Videregivelse via meddelelse til at implementere et asynkront request/re-
sponse-mønster kan finde tilbage til den konkrete procesinstans, der afsendte forespørg-
sel-meddelelsen
– Der er behov for at forholde sig til, hvor og hvordan de data, der er blevet indhentet af
en specifik procesinstans, opbevares undervejs (ift. sikkerhed, fortrolighed m.m.)
– Der er behov for at afklare, hvordan personhenførbare data, der er omfattet af GDPR’s
ret til at blive glemt, og som er indhentet af en proces og dermed har et midlertidigt ”liv”
i en specifik procesinstans, skal håndteres, hvis den registrerede gør brug af retten til at
blive glemt.
— Log: Denne referencearkitektur har benyttet komponenten log i betydningen en persondataan-
vendelseslog. Formålet med og brugen af en log-komponent er klart beskrevet, hvorimod den
indholdsmæssige modellering af selve indholdet i loggen er forbigået. Det vil være hensigtsmæssigt
at adressere en fælles modellering af en persondataanvendelsesloginddatering i det videre arbejde
omkring standardisering af begreber relateret til videregivelse af data.
— Samtykker: I denne referencearkitektur har vi talt om den registrerede, afsender og modtager som
roller, der indtages af en ’direkte’ aktør, fx den virksomhed eller den borger, der er part i en given
sags- eller procesforløb. Imidlertid kan en anden aktør i praksis agere på vegne af den underlig-
gende aktør (partsrepræsentation), hvis sidstnævnte har givet behørigt samtykke. Det kan fx være
en advokat, der opererer på vegne af en klientvirksomhed, eller en borger, der har fuldmagt/sam-
tykke fra et familiemedlem til at agere på vegne af vedkommende. Samtykker udfolder sig som
begreb hovedsageligt inden for brugerstyringsområdet. En yderligere udfoldning af samtykke-be-
grebet i FDA-sammenhæng, herunder en afklaring af særlige aspekter, der indvirker på videregi-
velse af data, ville være værdifuld set fra denne referencearkitekturs synspunkt.
46
— Standardisering: Afsnit 4.5 har peget på en række områder, hvor standardisering vil være fordel-
agtig for at forløse denne referencearkitekturs overordnede mål om at gøre det enklere at dele og
genbruge data. I det videre arbejde med at skabe gode rammer for deling af data og dokumenter
blandt offentlige myndigheder, virksomheder og borgere i Danmark vil være formålstjenligt at
definere initiativer, der kan adressere de standardiseringsbehov, der er identificeret her, gennem
yderligere analyse og anbefalinger.
— Blockchain: Blockchain er en ny teknologi, der på tidspunktet for dette dokuments udarbejdelse
har givet anledning til en trend. Blockchain er baseret på et fuldt distribueret og modifikationssikret
datasæt og kendes særligt fra kryptovalutaer (med Bitcoin som den mest kendte). Samtidigt foregår
der en afsøgning af blockchain-teknologiens muligheder generelt. I sammenhæng med denne re-
ferencearkitektur bemærker vi, at blockchain kan være en måde at implementere integritetssikret
anvendelseslog på. Blockchain kan også udgøre en dataplatform som beskrevet i afsnit 4.2.3. Dog
vil det medføre, at ikke blot den fysiske platform, men også forretningsrollen ’platformsansvarlig’
bliver distribueret, hvilket vil have konsekvenser fx i forhold til håndhævelse af adgangskontrol,
der skal afsøges yderligere.
— Øvrige anvendelser af data: Afsnit 3.1 beskriver en række (gen)-anvendelser af data, der rækker
ud over digital selvbetjening i offentlige sammenhænge. Der er behov for at understøtte disse
anvendelser også, evt. ved at introducere yderligere forretnings- og implementeringsmønstre.
47
6 Bilag
6.1 Bilag A: Tjekliste for anvendelse af referencearkitekturen Denne tjekliste kan anvendes af projekter, der designer, bestiller eller udvikler løsninger til deling af data.
Tjeklisten trækker mange af de væsentligste punkter fra denne referencearkitektur frem og er desuden
skrevet med projektarbejde for øje, i det den fremhæver mange af de nødvendige afklaringer, der skal
foretages i projektsammenhæng.
Punkterne i tjeklisten følger opdelingen i interoperability levels fra European Interoperability Framework
(EIF). EIF benytter fire niveauer for interoperabilitet: Legal (L), Organisational (O), Semantic (S) og
Technical (T). Nummereringen nedenfor afspejler, hvilket interoperabilitetsniveau det enkelte punkt er
relevant for.
Tjeklisten anvendes desuden som en del af det arkitekturmæssige review af projektet.
Nr. Arkitekturegenskaber Reference til ref.ark Reference til hvidbog
L1 Har projektet identificeret, hvilke data der udveksles
mellem aktører, samt om data er klassificeret i forhold
til persondatalov og GDPR?
3.6 Forretningsobjekter
og begreber
3: Arkitektur og regulering under-
støtter hinanden 4: Sikkerhed, privatliv og tillid sik-
res 6: Gode data deles og genbruges
L2 Har projektet identificeret, om det data, der adresseres,
er beskrevet i offentlige kataloger i form af datasamlin-
ger og datamodeller?
3.6 Forretningsobjekter
og begreber
6: Gode data deles og genbruges
L3 Er det undersøgt, med hvilken hjemmel i GDPR even-
tuelle persondata tænkes videregivet, samt om denne
hjemmel er yderligere beskrevet i dansk lovgivning?
2.5 Juridiske rammer 3: Arkitektur og regulering under-
støtter hinanden 4: Sikkerhed, privatliv og tillid sik-
res
L4 Har projektet afklaret, hvilke aftaler mellem dataan-
svarlig, dataanvender og eventuelle databehandlere
som er nødvendige (databehandleraftale, Service Level
Agreement, håndhævelse af adgangskontrol m.m.)?
3.4 Forretningsroller og
aktører
4.1 Nødvendige applikati-
onsservices
1: Arkitektur styres på rette ni-
veau efter fælles rammer
3: Arkitektur og regulering under-
støtter hinanden
L5 Har projektet afklaret, hvem der har ansvaret for "den
registreredes" ret til indsigt i opbevaring og videregi-
velse af persondata, samt igennem hvilken bruger-
flade/proces, dette sker? Er der forskel på, hvem der
er responsible (dataansvarlig) og accountable (måske
en datadistributør)?
3.3 Forretningsroller og
aktører
3: Arkitektur og regulering under-
støtter hinanden 5: Processer optimeres på tværs
O1 Er det klarlagt, hvilken/hvilke forretningsprocesser,
den specifikke videregivelse af data indgår i? Og om
data videregives på forespørgsel eller ved meddelelse?
3.5 Tværgående processer 5: Processer optimeres på tværs 6: Gode data deles og genbruges
O2 Er udvekslede meddelelser, der videregiver data, egnet
til at indgå i offentlig forvaltning? Kan de knyttes til sa-
ger, journalplaner og parter? Er meddelelsen forberedt
på arkivering? Skal meddelelsen konsolideres i et doku-
ment egnet til visning til borgere?
3.2 Om data og doku-
menter
3: Arkitektur og regulering under-
støtter hinanden5: Processer opti-
meres på tværs
O3 Er det afklaret, hvordan ændringer til fælles informati-
onsmodeller, referencedata, applikationsprofiler og
3.6 Forretningsobjekter
og begreber
1: Arkitektur styres på rette ni-
veau efter fælles rammer
48
specifikationer, der påtænkes anvendt i projektet,
håndteres? Kan projektet blive ramt af ændringer? Kan
projektet anmode om ændringer?
O4 Er den overliggende forretningsproces/anvendelse de-
signet til at håndtere fejlscenarier ifm. tjek af hjemmel,
fx at en dynamisk angivet hjemmel (angivet i fore-
spørgslen) ikke vurderes gyldig af dataansvarlig, eller at
negativt samtykke forhindrer videregivelsen?
3.5.1 Videregivelse på fo-
respørgsel
5: Processer optimeres på tværs
O5 Benyttes den autoritative datasamling direkte? Hvis der
benyttes en dataservice eller en distributionskopi, er
alle evt. begrænsninger ift. datakvalitet, aktualitet m.m.
da velbeskrevne fra distributøren? Og er der taget stil-
ling til hvor og hvordan log af persondataanvendelse
konsolideres?
3.5.1 Videregivelse på fo-
respørgsel
7: It-løsninger samarbejder effek-
tivt
8: Data og services leveres drifts-
sikkert
O6 Er der taget stilling til, hvordan hjemmel skal angives
og håndhæves, herunder om det skal ske design-time
(hvor forespørgsler fra en given Dataanvender altid
accpteres), runtime (hvor hjemmel angives dynamisk)
eller reaktivt (hvor evt. misbrug spores gennem log-
gen)?
3.5.1 Videregivelse på fo-
respørgsel
3: Arkitektur og regulering under-
støtter hinanden
4: Sikkerhed, privatliv og tillid sik-
res
7: It-løsninger samarbejder effek-
tivt
O7 Har projektet afklaret, hvilken organisation der skal
bære omkostningen ved videregivelse af data på fore-
spørgsel - herunder, om det er en dataansvarlig, en di-
stributør eller en platformsansvarlig?
4.2 Implementering af vi-
deregivelse på forespørg-
sel
1: Arkitektur styres på rette ni-
veau efter fælles rammer
O8 Har projektet klarlagt, om genbrug af data involverer
transformation mellem datamodeller? Hvis ja, er det
afklaret, om dette skal ske på Anvenderside eller om
det skal ske i en anvendelsesorienteret dataservice? Er
der afklaring om governance ift. fremtidigt vedligehold
af datamodeller/transformation?
4.2 Implementering af vi-
deregivelse på forespørg-
sel
6: Gode data deles og genbruges
O9 Har projektet klarlagt, om en modtager, der er en orga-
nisation, har særlige krav/ønsker til at kunne route
meddelelsen efter modtagelse?
3.5.2 Videregivelse ved
meddelelse
5: Processer optimeres på tværs
O10 Hvis servicefællesskab-mønsteret for meddelelser an-
vendes, er det da klarlagt, hvilke organisationer der er
ansvarlige for service provider agreements?
3.5.2 Videregivelse ved
meddelelse
1: Arkitektur styres på rette ni-
veau efter fælles rammer
3: Arkitektur og regulering under-
støtter hinanden
S1 Har projektet afklaret, hvor der sker sammenstilling og
transformation af data? Om der anvendes fælles refe-
rencedata og oversættelser?
3.5.1 Videregivelse på fo-
respørgsel
5: Processer optimeres på tværs
6: Gode data deles og genbruges
S2 Har projektet taget stilling til anvendelse af selvbeskri-
vende data som beskrevet i niveau 3 af de Fællesof-
fentlige regler for begrebs- og datamodellering? Både
ift. genbrug af eksisterende, selvbeskrivende data, samt
ift. om data, som projektet selv skal gøre tilgængeligt
for andre, skal modelleres som selvbeskrivende data?
4.1.1 Ønskelige egenska-
ber ved videregivelse
6: Gode data deles og genbruges
T1 Har projektet anvendt relation til EIRA og andre inter-
nationale modeller med henblik på at identificere stan-
darder og specifikationer som udgangspunkt for an-
vendelsesprofiler?
6.6 Bilag F: Mapning til
EIRA
1: Arkitektur styres på rette ni-
veau efter fælles rammer
2: Arkitektur fremmer sammen-
hæng, innovation og effektivitet
49
6.2 Bilag B: Ord- og begrebsliste Listen på de næste sider definerer og forklarer betydningen af de væsentligste ord og begreber, der indgår
i den fællesoffentlige referencearkitektur for deling af data og dokumenter.
T2 Har projektet vurderet og prioriteret de forskellige im-
plementeringsmønstre for videregivelse hhv. på fore-
spørgsel eller ved meddelelse? Er skalerbarhed overve-
jet, både på kort sigt og i forhold til langsigtede behov?
4.2/4.3 Implementering
af videregivelse på fore-
spørgsel/ved meddelelse
7: It-løsninger samarbejder effek-
tivt
8: Data og services leveres drifts-
sikkert
T3 Er der taget stilling til, om en påtænkt, ny anvendelse
har et omfang, der påvirker en eksisterende data- eller
forsendelses-services robusthed (ift. SLA/availability)?
4.1.1 Ønskelige egenska-
ber ved videregivelse
8: Data og services leveres drifts-
sikkert
T4 Er det afklaret, hvordan den enkelte meddelelses inte-
gritet og fortrolighed sikres?
4.1.1 Ønskelige egenska-
ber ved videregivelse
4: Sikkerhed, privatliv og tillid sik-
res
T5 Er der taget stilling til, hvordan log/logdata beskyttes?
Både med hensyn til fortrolighed, integritet og tilgæn-
gelighed
4.1.1 Ønskelige egenska-
ber ved videregivelse
4: Sikkerhed, privatliv og tillid sik-
res
T6 Har projektet afklaret, hvordan dataanvender skal
identificere sig over for data- eller forsendelsesservices
og hvilken komponent der håndhæver adgangskontrol?
4.1.1 Ønskelige egenska-
ber ved videregivelse
4: Sikkerhed, privatliv og tillid sik-
res
T7 Indebærer forespørgslen på data en søgning/brug af
indeks? Og er det afklaret hvem der har dataansvar
herfor?
3.5.1 Videregivelse på fo-
respørgsel
5: Processer optimeres på tværs
T8 Har projektet klarlagt evt. eksisterende message-infra-
struktur hos hhv. afsender og modtager?
4.3 Implementering af vi-
deregivelse ved medde-
lelse
5: Processer optimeres på tværs
7: It-løsninger samarbejder effek-
tivt
T9 Har projektet klarlagt, om der findes et adresseregister,
der kan genbruges til adressering af meddelelser og på-
mindelser?
3.5.2 Videregivelse ved
meddelelse
5: Processer optimeres på tværs
7: It-løsninger samarbejder effek-
tivt
50
Begrebsliste: Begrebsmodel
Forretningsmetadata:
Namespace: data.gov.dk/datasharing Prefix: Modelnavn (label): Videregivelse af data Modelejer (publisher): Digitaliseringsstyrelsen Versionnummer (versionInfo): 1.0 Seneste opdateringsdato (dateModified): 26-04-2018 Modelstatus (modelStatus): development Godkendelsesstatus (approvalStatus) : in review Forretningsområde (theme): 06.38.10 Digital Infrastruktur Juridisk kilde (legalSource): Databeskyttelsesforordningen (GDPR) (EU) 2016/679; Fordning om elektroniske tillidstjenester (eIDAS) (EU) 2014/910 Kilde (source): Fællesoffentlig Digital Arkitektur (arkitektur.digst.dk), Archimate 3.0.1 Specification (via opengrup.org) Kommentar (comment): begrebsmodel under udarbejdelse i forbindelse med referencearkitektur for deling af data og dokumenter
Begreber
Foretrukken dansk term
Accepteret dansk term
Frarå-det dansk term
Definition
Eksempel Kommentar
Juridisk kilde
Kilde
besked skriftlig eller mundtlig oplysning som sendes eller overbringes til andre Den Danske Ord-bog
data Information lagret med henblik på (gen)anvendelse Tidligere dansk definition: enhver repræsentation af fakta eller idé i en sådan form, at den kan kom-munikeres eller omformes ved en eller anden proces [Bogen om EDB. H.B. Hansen, 1969]
ISO/IEC 11179-4:2004
51
dataansvarlig persondataansvarlig en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, der alene eller sammen med andre afgør, til hvilke for-mål og med hvilke hjælpemidler der må foretages behandling af person-oplysninger
En privatpraktiserende læge er da-taansvarlig for hendes patientjour-nal
(EU) 2016/679
databehandler persondatabehandler en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, der behandler personoplysninger på den dataansvarliges vegne
Driftleverandøren af en database til en offentlig myndighed er databe-handler på vegne af denne.
(EU) 2016/679
dataabonnement abonnement på regi-streringshændelser; abonnement på æn-dringer i datasamlin-ger
abonnement der specificerer hvilke meddelelser - om ændringer til en datasamling - en beskedmodtager ønsker at modtage
En kommune kan have et dataabon-nement der sender meddelelser ved ændringer i CPR oplysninger for kommunens indbyggere.
her indskrænket til at omhandle ændringer i datasamlinger i mod-sætning til abonnement på forret-ningshændelser
FDA Referencear-kitektur for de-ling af data og dokumenter
adgangskontrol forretningsfunktion der afgør hvilke funktioner og data en bruger får ad-gang til på baggrund af brugerens attributter og tjenestens sikkerheds-politik
ændret process til forretnings-funktion jf archimate.
FDA Referencear-kitektur for bru-gerstyring
adgangspolitik definition af kriterierne for at få adgang til en applikationsservice. En skoleleder kan have adgang til CPR oplysninger hvis personen er elev, ansat på skolen eller pårøre-rende til elever.
ændrer it service til applikations-service jf archimate
FDA Referencear-kitektur for bru-gerstyring
elektronisk adresse
adresse til modta-gelse af elektroniske meddelelser; adresse
dataobjekt der angiver hvor en person eller organisation ønsker at mod-tage bestemte typer af elektroniske meddelelser
e-mail eller EAN/GLN-nummer med tilhørende angivelse af hvilke typer af meddelelser der kan modtages fx fakturaer
FDA Referencear-kitektur for de-ling af data og dokumenter
afsender af elek-troniske medde-lelser
afsender person eller organisation, der sender en elektronisk meddelelse En kommune, der sender et medde-lelse via Digital Post til en borger, er en (offentlig) afsender
FDA Referencear-kitektur for de-ling af data og dokumenter
dataanvender anvender af data; an-vender
person eller organisation der behandler data til eget formål Danmarks Statistik anvender data om CPR data til udarbejdelse af le-vealders-statisk
FDA Referencear-kitektur for de-ling af data og dokumenter
behandling af per-sonoplysninger
persondatabehand-ling; behandling af persondata
be-hand-ling; data-be-hand-ling
enhver aktivitet eller række af aktiviteter — med eller uden brug af au-tomatisk behandling — som personoplysninger eller en samling af per-sonoplysninger gøres til genstand for, f.eks. indsamling, registrering, or-ganisering, systematisering, opbevaring, tilpasning eller ændring, gen-finding, søgning, brug, videregivelse ved transmission, formidling eller enhver anden form for overladelse, sammenstilling eller samkøring, be-grænsning, sletning eller tilintetgørelse
(EU) 2016/679
brugerstyring håndhævelse af adgangskontrol og administration af brugere og deres rettigheder
egen definition
FDA Referencear-kitektur for bru-gerstyring
databehandling behandling af persondata eller anden data i en organisation En skole behandler oplysninger om elevers karakter
FDA Referencear-kitektur for de-ling af data og dokumenter
datadistributør datafordeler; distri-butør
databehandler der som databehandler giver anvendere adgang til data på vegne af den dataansvarlige
Styrelsen for Dataforsyning og Ef-fektivisering distrubere CPR data på vegne af Indenrigsministeriets CPR kontor
FDA Referencear-kitektur for de-ling af data og dokumenter
datasamling datasæt; register; regi-strant
en samling af oplysninger bestående af enkelte dele der forvaltes under et
CPR registeret, Det Interregionale billedeindex (IBI)
Minder om begrebet ’arkiv’ fra Sag og Dokument, samt om PSI lovens definition af datasamling. Det kan overvejes at anvende PSI definitionen.
FDA Referencear-kitektur for de-ling af data og dokumenter
52
dataservice applikationsservice der videregiver oplysninger fra datasamlinger på fo-respørgsel under håndhævelse af nødvendig adgangskontrol
Kommunernes serviceplatform ud-stiller en person-service til opslag i CPR og skoledistrikter.
oftest ved håndhævelse af ad-gangskontrol, men ikke nødven-digvis
FDA Referencear-kitektur for de-ling af data og dokumenter
den registrerede datasubjekt person om hvem oplysninger behandles egen definition (EU) 2016/679
distributionskopi kopi af datasamling der opbevares hos databehandler med henblik på distribution efter instruks fra dataansvarlig
FDA Referencear-kitektur for de-ling af data og dokumenter
dokument afgrænset samling af informationer, i en kendt struktur, gemt på et kendt medie
Dokumenter i ESDH systemer, pati-entjournaler, selvbetjeningsløsnin-ger og vedhæftet digitale post med-delelser
OIO Referencear-kitektur for Sag og Dokument
forespørgsel request meddelelse der sendes til en dataservice med forventning om svar inde-holdende specifikke data
En link på en hjemmeside er en fo-respørgsel til en server der svarer med en hjemmeside
FDA Referencear-kitektur for de-ling af data og dokumenter
forsendelsesser-vice
elektronisk leverings-tjeneste
applikationsservice, der gør det muligt at sende og modtage meddelel-ser samt dokumenterer behandlingen af disse, herunder leverer bevis for afsendelse og modtagelse af dataene, og som beskytter dem mod tab, tyveri, beskadigelse og uautoriseret ændring
Bemærk at denne definition ikke kræver at en applikationsservice er registreret, men alene udtaler sig om funktionelle egenskaber.
egen definition (EU) 2014/910
fuldmagt formel tilladelse til at handle på vedkommendes vegne i nærmere be-stemte situationer
Den Danske Ord-bog
hjemmel til be-handling af per-sondata
hjemmel forhold der gør behandling af persondata lovlig egen definition. (EU) 2016/679
indsigt i behand-ling af persondata
persondataindsigt; indsigt
den registreredes indsigt i opbevaring, anvendelse, videregivelse og an-den behandling af persondata omhandlende sig selv
egen definition (EU) 2016/679
personoplysninger persondata enhver form for information om en identificeret eller identificerbar fysisk person (»den registrerede«); ved identificerbar fysisk person forstås en fysisk person, der direkte eller indirekte kan identificeres, navnlig ved en identifikator som f.eks. et navn, et identifikationsnummer, lokaliserings-data, en onlineidentifikator eller et eller flere elementer, der er særlige for denne fysiske persons fysiske, fysiologiske, genetiske, psykiske, øko-nomiske, kulturelle eller sociale identitet
(EU) 2016/679
persondatalog log over videregivelse af persondata; per-sondatalog; log
datasamling der beskriver de faktiske, historiske videregivelse af oplys-ninger i en given datasamling, herunder med hvilken hjemmel, behand-lingen er sket
MinLog på sundhed.dk dokumente-rer hvem der har haft adgang til en persons sundhedsdata
FDA Referencear-kitektur for de-ling af data og dokumenter
meddelelse elektronisk medde-lelse;
formel besked der sendes elektronisk med veldefineret sikkerhed, tillid, integritet og leverancesikkerhed
En e-mail sendt via sikker e-mail mellem myndigheder betragtes som ulæselig for andre end modtage-rens organisation, men den er ikke garanteret at nå frem.
FDA Referencear-kitektur for de-ling af data og dokumenter
modtager af elek-troniske medde-lelser
modtager forretningsrolle (person eller organisation), der modtager elektronisk meddelelse
En borger kan være modtager af en meddelelse sendt via Digital Post
FDA Referencear-kitektur for de-ling af data og dokumenter
påmindelse advis; notifikation en besked der får modtager til at tænke på en vigtig begivenhed Typisk uden dokumentation af behandling eller beskyttelse jf meddelelse.
FDA Referencear-kitektur for de-ling af data og dokumenter
registrator person eller apparat der registrerer noget Den Danske Ord-bog
53
retskilde omstændighed som er med til at fastlægge gældende ret ved løsningen af juridiske problemer
Persondatalov, Arkivlov omfatter først og fremmest loven og retspraksis. Her mere specifikt retskilde der beskriver forhold om behandling af ( (person)data
Den Danske Ord-bog
adgangsrettighed rettighed der tildeles en bruger eller roller, der giver adgang til at udføre funktioner i et it-system.
egen definition
FDA Referencear-kitektur for bru-gerstyring
samtykke til per-sondatabehand-ling
Samtykke; personda-tasamtykke
klar bekræftelse, der indebærer en frivillig, specifik, informeret og utve-tydig viljestilkendegivelse fra den registrerede, hvorved vedkommende accepterer, at personoplysninger om vedkommende behandles
(EU) 2016/679
svar respons meddelelse dannet af dataservice som besvarer en forespørgsel FDA Referencear-kitektur for de-ling af data og dokumenter
videregivelse af data
deling af data; data-deling
forretningsfunktion hvorved data overføres ud af organisation sende meddelelse indeholdende sagsoplysninger; Sundhedsdatasty-relsen videregiver medicinoplysnin-ger fra Fælles Medicinkort til SOSU assistenter i Ålborg Kommune.
FDA Referencear-kitektur for de-ling af data og dokumenter
videregivelse på forespørgsel
integrationsmønster hvor data videregives af dataansvarlig på fore-spørgsel på anvenders initiativ
FDA Referencear-kitektur for de-ling af data og dokumenter
videregivelse ved meddelelse
integrationsmønster hvor data videregives ved meddelelse af dataan-svarlig på dennes initiativ
FDA Referencear-kitektur for de-ling af data og dokumenter
Begreber oversat og anvendt fra Archimate©
Foretrukken dansk term
Accepteret dansk term
Frarå-det dansk term
Definition
Eksempel Kommentar
Juridisk kilde
Kilde
dataobjekt data struktureret med henblik på automatisk behandling e-mail, word-dokument, database egen oversættelse Archimate speci-fikation
applikationsser-vice
it-service; webser-vice; service
veldefineret funktionalitet udstillet af applikationskomponent Opslag i CPR, modtagelse af email egen oversættelse Archimate speci-fikation
forretningsfunk-tion
gruppering af opgaver i relation til en organisations opbygning egen oversættelse Archimate speci-fikation
forretningsobjekt begreb som det anvendes i specifik domæne egen oversættelse Archimate speci-fikation
forretningsrolle samling af funktioner en aktør har ansvar for i en specifik kontekst egen oversættelse Archimate speci-fikation
intergrationsmøn-ster
business collabora-tion; tværgående use case
to eller flere forretningsrollers koordinerede handlinger i en specifik kon-tekst
egen oversættelse Archimate speci-fikation
implementations-mønster
application collabora-tion
to eller flere applikationskomponenter der samarbejder for at udføre en fælles opgave
egen oversættelse Archimate speci-fikation
54
6.3 Bilag C: Eksempel: Anvendelse af referencearkitekturen i et projekt Dette bilag har til formål at give et eksempel på, hvordan man kan anvende Referencearkitektur for deling af data
og dokumenter i en konkret (men fiktiv) projektsammenhæng. Eksemplet er opfundet til lejligheden, og det skal
understreges, at løsningsskitser og diagrammer i dette afsnit således ikke på nogen måde hævder at repræsentere
den virkelige proces.
Eksemplet tager udgangspunkt i brugerrejsen ”jagttegns-aspirant under 18 år ønsker at tilmelde sig jagtprøve”.
Projektet har et ønske om at bygge en selvbetjeningsløsning, der understøtter denne brugerrejse, og har indled-
ningsvist identificeret og skitseret nogle af de nødvendige procestrin og datatyper, der skal understøtte løsningen
(som vist på Figur 17).
Figur 17: Indledende skitse til en løsning, der involverer videregivelse af data. Det (fiktive) eksempel beskriver bru-gerrejsen ”jagttegns-aspirant under 18 år ønsker at tilmelde sig jagtprøve”.
Projektet ønsker nu at anvende Referencearkitektur for deling af data og dokumenter for at kvalificere sit løs-
ningsdesign og løfte den indledende, rå skitse til et mere modent arkitekturdesign. I denne sammenhæng vælger
projektet at gå frem på følgende måde:
— Identificer de konkrete procestrin, hvor data videregives: Projektet finder frem til, at der skal videre-
gives:
– Et samtykke i form af en forældreaccept, der indhentes separat og videregives fra borger.dk
– Data om aspiranten (fra CPR-registeret)
– Information om tilgængelige prøvetilbud samt detaljeret information om det enkelte tilbud
– Tilmeldingsblanket (slutresultat fra selvbetjeningsforløbet)
— Analyser de implementeringsmønstre, der påtænkes anvendt ved den enkelte videregivelse: Pro-
jektet kommer frem til følgende valg:
– Samtykker fra forældre etableres som en ny datasamling på borger.dk. Selvbetjeningsforløbet, der
afvikles på Miljø- og Fødevareministeriets servere, forespørger på videregivelsen af data via møn-
steret direkte adgang.
– Data om aspiranten hentes fra Datafordeleren, der distribuerer CPR-registeret (som er en data-
samling) på vegne af Indenrigsministeriet ifølge datadistributør-mønsteret.
55
– Information om tilgængelige kurser og prøvetilbud viser sig at være spredt ud over en række ud-
bydere, der benytter sig af forskellige datadistributører. Heldigvis viser det sig, at en eksisterende
løsning hos Undervisningsministeriet, der indekserer prøvetilbud på tværs af kursus- og prøveud-
bydere, kan udvides med denne type prøver. Projektet vælger derfor implementeringsmønsteret
datadistributør (med brug af indeks).
– Tilmeldingsblanketten, der er resultatet af brugerens valg af jagtprøve, skal videregives som en
meddelelse til den valgte prøveudbyder. Fra prøvetilbud-dataservicen kender vi CVR-nummeret
på den valgte prøveudbyder. For at undgå at skulle kommunikere direkte med den valgte udbyders
system (som vi ikke kender, og hvor de mulige udbydere i øvrigt kan ændre sig over tid) vælger
projektet implementeringsmønsteret fælles system og lader Digital Post stå for formidlingen af
tilmeldingen (og sørger i den forbindelse for at designe en meddelelse, der i form af et struktureret
dokument både kan læses af en menneskelig modtager og afkodes automatisk hos de udbydere,
der har systemer, der understøtter dette).
— Annoter med begreber fra Referencearkitekturen og Fællesoffentlig Digital Arkitektur: For at
kunne tale et fælles sprog med de øvrige parter, der skal videregive data til projektet eller modtage data fra
projektet, opdaterer projektet den indledende løsningsskitse (se Figur 18):
– Selvbetjeningsforløbet annoteres med begreber fra Referencearkitektur for selvbetjening, fx for-
beredelse, kerne, afrunding – se blå tekst på Figur 18
– De identificerede videregivelser af data markeres med deres planlagte implementeringsmønster –
røde note-bokse på Figur 18
– De øvrige, underliggende komponenter annoteres med de relevante begreber, fx dataservice, da-
tasamling, distributionskopi m.m. – se øvrige bokse med rød tekst på Figur 18
— Løber tjeklisten igennem: Referencearkitektur for deling af data og dokumenter rummer en tjekliste for
anvendelse. Tjeklisten kommer rundt om såvel juridiske aspekter ved videregivelse af data (L – legal), de
forretningsmæssige overvejelser, som projektet bør gøre sig (O – organisational), det semantiske design i form
af dokumentation, datamodeller m.v. (S – semantic) samt sluttelig de tekniske overvejelser, der understøtter
valg af implementeringsmønstre, guider til valg af standarder m.m. (T – technical).
Ved at anvende Referencearkitektur for deling af data og dokumenter (samt de øvrige værktøjer, der er tilgænge-
lige som en del af Fællesoffentlig Digital Arkitektur) har projektet nu fået løftet sit løsningsdesign. De relevante
data, der kan genbruges, er blevet identificeret, og der, hvor der skal bygges nye komponenter, sikrer det fælles
sprog og begrebsapparat imod misforståelser og imod, at projektet overser væsentlige aspekter i designfasen,
hvilket ville kunne føre til forsinkelser eller fordyrelser senere i projektets levetid.
56
Figur 18: En mere detaljeret løsningsskitse, der er kvalificeret med begreber og implementeringsmønstre hentet fra Referencearkitektur for deling af data og dokumenter.
57
6.4 Bilag D: Eksempler på løsninger pr. implementeringsmønster Implementeringsmønstrene i denne referencearkitektur er beskrevet som selvstændige mønstre bygget på det
begrebsapparat, vi har valgt at beskrive videregivelse af data ud fra – uden konkrete referencer til faktiske løsnin-
ger. Det betyder imidlertid ikke, at der ikke i dag (primo 2018) findes konkrete, produktionssatte løsninger, der i
overvejende grad følger de beskrevne mønstre. Nedenfor gives en kort oversigt over faktiske løsninger, der på
væsentlige punkter passer ind i de beskrevne mønstre.
Forretningsmønster Implementeringsmønster Eksempel på løsning
Videregivelse på fore-
spørgsel
Direkte adgang — Opslag i CPR-registeret hos Indenrigsministeriet
Datadistributør — Datafordeleren
Fælles service- og dataplatform — Den Nationale Serviceplatform (NSP)
Videregivelse ved medde-
lelse
Direkte forsendelse — Sikker e-mail mellem myndigheder
Fælles system — Digital Post
Servicefællesskab — NemHandel via PEPPOL
58
6.5 Bilag E: Om specifikationer, standarder og profiler I forbindelse med udbud har man behov for at beskrive de krævede egenskaber for løsningen i en ’teknisk spe-
cifikation’. Betydningen fremgår af EU's direktiv 2014/24/EU, der regulerer offentlige udbud og definerer ‘tek-
niske specifikationer’ som: Specifikation i et dokument, som fastlægger krævede egenskaber ved et produkt eller en tjenesteydelse.
I relation til indkøb af it-løsninger til brug ved deling af data og dokumenter inkluderer dette egenskaber ved
udstillede applikationsservices.
Ofte er det muligt at beskrive den tekniske specifikation ved en henvisning til en ’standard’. Direktivet definerer
en standard således: teknisk specifikation, som er vedtaget af et anerkendt standardiseringsorgan […]. Sådanne standarder
kan kategoriseres efter den udgivende organisations udbredelse; global, europæisk eller national (fx ISO, CEN
og DS).
Inden for indkøb af it-løsninger har det vist sig, at mange vigtige, tekniske specifikationer har fundet udbredelse
uden at være officielt udgivet af en anerkendt standardiseringsorganisation. Derfor indeholder direktivet også
begrebet ‘fælles teknisk specifikation’ som henviser til it-specifikationer, der er blevet identificeret som egnet til
anvendelse i offentlige indkøb af EU gennem formel behandling i European Multi Stakeholder Platform on ICT
Standardisation.
Til en given anvendelse er det ofte hensigtsmæssigt at benytte ‘profiler’. En profil kan fx være en samling af
delmængder af forskellige standarder og kan dermed præcisere, hvordan den endelige løsning forventes at gøre
brug af de forhåndenværende standarder og tekniske specifikationer. Dette er udtrykt som: ”[...] standards alone
often leave too many degrees of freedom for efficient deployment. For that purpose, organisations [...] have introduced the concept of
Profiles, which can be seen as the cement that holds building blocks together, forming functional modules. Profiles are guidelines for
implementation of specific use cases, by selecting relevant standards and defining how they have to be configured.
https://www.antilope-project.eu/wp-content/uploads/2013/05/D1.1-Refinement_of_Antilope_Use_Cases_v1.2.pdf
I den fællesoffentlige rammearkitektur dækker begrebet ’anvendelsesprofil’ over denne betydning. Referencear-
kitekturens formål kan dermed også beskrives som, at den skal være det dokument, der udpeger områder, hvor
der mangler relevante anvendelsesprofiler.
59
6.6 Bilag F: Mapning til European Interoperability Reference Architecture v2
EU-kommissionen støtter gennem ISA2-programmet udvikling af digitale løsninger, der sætter offentlige instan-
ser, borgere og virksomheder i Europa i stand til at drage fordel af offentlige services, der er interoperable på
tværs af landegrænser, sektorer m.m.
En del af ISA2-programmet er European Interoperability Reference Architecture (EIRA), der har som mål at
facilitere interoperabilitet gennem fælles arkitektur, herunder genbrug af arkitektoniske byggeblokke på tværs af
løsninger i de europæiske lande.
EIRA definerer 4 niveauer for interoperabilitet under samlebetegnelsen LOST, der dækker over Legal, Organi-
sational, Semantic og Technical interoperabilitet.
Som en del af udarbejdelsen af rammearkitekturen under Den fællesoffentlige digitaliseringsstrategi har Digitali-
seringsstyrelsen afholdt workshops med EIRA-repræsentanter for dels at rette ind mod EIRA-rammeværket,
hvor det er relevant, dels at give input til den videre udvikling af EIRA.
Referencearkitektur for deling af data og dokumenter indgår i den fællesoffentlige rammearkitektur. Nedenfor er
de fire LOST-views angivet for denne referencearkitektur.
Figur 19: EIRA Legal View: De væsentligste elementer fra et lovmæssigt perspektiv
60
Figur 20: EIRA Organisational View: De væsentligste elementer på det forretningsmæssige/organisatoriske inter-operabilitetsniveau
Figur 21: EIRA Semantic View: De væsentligste elementer i det semantiske lag af interoperabilitet
61
Figur 22: EIRA Technical View: De væsentligste elementer til at understøtte deling af data og dokumenter fra det tekniske perspektiv
62
6.7 Bilag G: Oversigt over kilder og baggrundsmateriale Nedenstående liste viser det baggrundsmateriale, der indgår i udarbejdelsen af den tværoffentlige referencearki-
tektur for selvbetjening.
Kilde Materiale
Digitaliseringsstyrelsen Vejledning i vurdering af offentlige it-projekters potentielle konsekvenser for
privatlivet; maj 2013. http://www.digst.dk/informationssikkerhed/Konsekvensvur-
dering-for-privatlivet
Digitaliseringsstyrelsen og Center
for Cybersikkerhed
Anbefalinger til styrkelse af sikkerheden i statens outsourcede it-drift; august
2014. https://www.digst.dk/Informationssikkerhed/Cyber-og-informationssikker-
hed/Styrkelse-af-sikkerheden-i-statens-outsourcede-it-drift
EU-Kommissionen GDPR – EU’s databeskyttelsesforordning (også kendt som Persondataforord-
ningen); maj 2018. http://eur-lex.europa.eu/legal-con-
tent/DA/TXT/PDF/?uri=CELEX:32016R0679&from=DA
EU-Kommissionen ISA2-programmet – Interoperability solutions for public administrations, businesses
and citizens. 2017. https://ec.europa.eu/isa2/isa2_en
EU-Kommissionen EIF – European Interoperability Framework. https://ec.europa.eu/isa2/eif_en
EU-Kommissionen EIRA – European Interoperability Reference Architecture. V2.0.0, juli 2017.
https://ec.europa.eu/isa2/solutions/eira_en
EU-Kommissionen Europa-Parlamentets og Rådets direktiv (EU) 2016/2102 af 26. oktober 2016 om til-
gængeligheden af offentlige organers websteder og mobilapplikationer (EØS-
relevant tekst); oktober 2016. http://eur-lex.europa.eu/legal-con-
tent/DA/TXT/?qid=1481622494924&uri=CELEX:32016L2102
EU-Kommissionen EU-wide digital Once-Only Principle for citizens and businesses: Policy options
and their impacts; april 2009. https://ec.europa.eu/digital-single-market/en/news/eu-
wide-digital-once-only-principle-citizens-and-businesses-policy-options-and-their-im-
pacts
Regeringen National strategi for cyber- og informationssikkerhed; december 2014.
https://www.digst.dk/Informationssikkerhed/Cyber-og-informationssikkerhed
Regeringen Sammenhængsreformen: Borgeren først - en mere sammenhængende offentlig sek-
tor; april 2017. https://www.fm.dk/publikationer/2017/sammenhaengsreform-bor-
geren-foerst-en-mere-sammenhaengende-offentlig-sektor
Regeringen, KL og Danske Regio-
ner
Et stærkere mere trygt digitalt samfund: Den fællesoffentlige digitaliseringsstrategi
2016-2020; maj 2016. https://www.digst.dk/strategier/strategi-2016-2020
Regeringen, KL og Danske Regio-
ner
Den fællesoffentlige digitale arkitektur, https://arkitektur.digst.dk/
Regeringen, KL og Danske Regio-
ner
Den fællesoffentlige rammearkitektur; https://arkitektur.digst.dk/rammearkitektur
Regeringen, KL og Danske Regio-
ner
Den digitalt sammenhængende offentlige sektor: Hvidbog om fællesoffentlig digi-
tal arkitektur; juni 2017. https://www.digst.dk/Arkitektur-og-data/It-arkitek-
tur/Hvidbog-og-modelregler.aspx
Regeringen, KL og Danske Regio-
ner
Referencearkitektur for: Overblik over egne sager, Tværgående processer; Un-
der udarbejdelse. https://arkitektur.digst.dk/rammearkitektur/referencearkitekturer
63
Regeringen, KL og Danske Regio-
ner
Referencearkitektur for Selvbetjening; april 2017. https://arkitektur.digst.dk/refe-
rencearkitektur-selvbetjening
Regeringen, KL og Danske Regio-
ner
Referencearkitektur for Brugerstyring; april 2017. https://arkitektur.digst.dk/ram-
mearkitektur/referencearkitekturer/referencearkitektur-brugerstyring
OIO Referencearkitektur for sags- og dokumentområdet (ESDH). OIO, 2008.
https://digitaliser.dk/resource/230688
Sundhedsdatastyrelsen Referencearkitektur for deling af dokumenter og billeder. National sundheds-it,
2012. https://sundhedsdatastyrelsen.dk/da/rammer-og-retningslinjer/om-refer-
encearkitektur-og-standarder
Sundhedsdatastyrelsen Referencearkitektur for informationssikkerhed. National sundheds-it, 2013.
https://sundhedsdatastyrelsen.dk/da/rammer-og-retningslinjer/om-referencearkitek-
tur-og-standarder
Sundhedsdatastyrelsen Strategi for digital sundhed 2018-2022. Sundhedsdatastyrelsen, 2018. https://sund-
hedsdatastyrelsen.dk/da/rammer-og-retningslinjer/strategi-for-digital-sundhed
Justitsministeriet Bekendtgørelse om sikkerhedsforanstaltninger til beskyttelse af personoplys-
ninger, som behandles for den offentlige forvaltning; marts 2001.
https://www.retsinformation.dk/Forms/R0710.aspx?id=842
Justitsministeriet Forvaltningsloven; april 2014. https://www.retsinforma-
tion.dk/forms/r0710.aspx?id=161411
Justitsministeriet Arkivloven; juni 2016.
https://www.retsinformation.dk/Forms/R0710.aspx?id=183862
Regeringen Lov om behandling af personoplysninger; maj 2000. https://www.retsinforma-
tion.dk/forms/r0710.aspx?id=828
Styrelsen for Arbejdsmarked og
Rekruttering
Bekendtgørelse om obligatorisk digital selvbetjening vedrørende ansøgninger
og meddelelser mv. om sociale ydelser mv.; november 2015. https://www.retsin-
formation.dk/Forms/R0710.aspx?id=175675
The Open Group TOGAF – The Open Group Architecture Framework. http://www.open-
group.org/subjectareas/enterprise/togaf
The Open Group ArchiMate V3.0, juni 2016. http://www.opengroup.org/subjectareas/enterprise/ar-
chimate-overview
W3C Linked Data Platform v1.0, inkl. profilering af Resource Description Framework
(RDF). http://www.w3.org/standards/semanticweb/data