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