Dato: 31. januar 2020 14:36
Forfatter: Jens Bruntt

Introduktion til adressering

I denne blog vil jeg skrive om mulighederne for at adressere modtageren af en Digital Post Meddelelse med Næste generation Digital Posts MeddelelsesModel (MeMo).

Lad os sige, at vi sender et papirbrev adresseret til Rigshospitalet, Blegdamsvej 9, 2100 København Ø. Det er jo meget upræcist. Hvor på Rigshospitalet skal brevet egentlig hen? Blodbanken, Akutmodtagelsen, Vaskeriet? Når man ikke angiver præcis adressat, så er nogen nødt til at åbne brevet og læse på det for at regne ud hvor det skal hen. Det er smartere at skrive for eksempel "Vaskeriet" på selve kuverten. Det er godt for modtageren, der ikke skal bruge tid på at analysere på indholdet, med risiko for at se personfølsomme oplysninger.

Det samme gælder for Digital Post. Man bør som afsender gøre hvad man kan for at hjælpe modtager-organisationen med at få Meddelelsen hen til rette modtager. Som afsender har man en interesse i at sagsbehandlingen kan ske korrekt og hurtigt hos modtageren.

I MeMo er der rige muligheder for at udfylde felter som gør, at vi - på "ydersiden af brevet" - kan angive hvem det er vi vil skrive til.

Blogserien

Bloggen her er den anden i en serie af blogs jeg skriver om NgDP. Nederst på siden er der links til de andre blogs i serien.

Det jeg skriver er baseret på hvad jeg ved om MeMO den 5/5-2021. MeMo er offentligt tilgængelig i version 1.1. Jeg har en forventning om at der kun vil være ganske få ændringer i formatet frem mod den færdige version.

Siden er opdateret 5/5-2021 da MeMO-formatet er opdateret til version 1.1.

MeMo og adressering

Her ser vi den fulde MeMO-struktur - klik på den for høj opløsning:

Det som jeg vil se på ligger i MessageHeader, og vi er hér inde i Recipient - modtageren som vi vil sende til. Hvad er mulighederne for at ramme den rigtige modtager?

Basal adressering

Når man skal sende Digital Post, så skal man angive recipientId og idType.

idType er enten "CVR" eller "CPR". Er det en virksomhed eller en person der skrives til? Og en myndighed adresseres også med CVR.

Ovenstående er nok til at adressere en besked til en modtager. Det er minimums-adresseringen. Det er OK, hvis man skal skrive til en borger, men det kan være i underkanten når man skriver til en virksomhed eller myndighed.

Alt hvad der herefter lægges på i forhold til adresseringsoplysninger er noget vi som afsender gør for at sikre os at rette modtager i virksomheden (herunder myndigheder) vi skriver til rent faktisk får Meddelelsen.

Man kan vælge at angive en label. Det er ikke et krav at den er udfyldt. Det er her man skriver modtagerens navn.

Er det en person, så er det dennes fulde navn.

Er det en virksomhed eller myndighed, så er det dennes navn.

AttentionData

Bemærk at vi her ser på AttentionData når de er brugt i forhold til en modtager: Recipient. AttentionData kan også bruges i forhold til afsenderen - det ser vi ikke på i denne blog, men der er skrevet om det i NgDP MeMO - afsenderoplysninger med AttentionData og ContactPoint.

AttentionData indeholder en lang række under-noder som man kan vælge at udfylde med oplysninger om den modtager man skriver til.

Hvad der giver mening afhænger af situationen. Nedenfor er mulighederne illustreret.

For alle dise under-elementer gælder at man skal tænke på dem i den kontekst at det handler om at fortælle modtager-organisationen hvor vi mener at Meddelelsen skal hen. Det svarer til det der er på forsiden af et papir-brev.

GlobalLocationNumber er en ID på tretten tal efter en international standard. Den udpeger en fysisk lokation. Det kan for eksempel være en bygning. Den kan i MeMO følges af en tekst der nanvgiver lokationen, f.eks. "vaskeriet".

AttentionPerson kan angives med en personIId og en label. personID er ikke veldefineret/standardiseret; det kan være for eksempel brugernavn i et IT-system. label er personens navn, for eksempel "Nancy Ann Berggreen". Det at personID ikke er standardiseret gør dette del-element ret irrelevant, med mindre at to afsendere/modtagere vedtager en fast model for deres indbyrdes kommunikation.

ProductionUnit kan bestå af productionUnitNumber og productionUnitName. ProductionUnitNumber er det tanken skal indeholde P-nummer, et tal som er en ID på virksomheder/organisationers "produktionsenheder", hvis virksomheden har flere lokationer. P-nummer er en standardiseret størrelse. ProductionUnitName er en betegnelse for den enhed der har P-nummeret. Jeg vil mene at brug af ProductionUnit giver rigtigt god mening når man skriver til virksomheder, da disse ikke kommer til at kunne adresseres gennem ContactPoint.

ContentResponsible er der ikke grund til at bruge når vi taler om AttentionData i sammenhæng med Recipient. Det giver mening når den bruges i sammenhæng med Sender (det ser jeg på i en anden blog).

GeneratingSystem er der ikke grund til at bruge når vi taler om AttentionData i sammenhæng med Recipient. Det giver mening når den bruges i sammenhæng med Sender (det ser jeg på i en anden blog).

SORdata (Sundhedsvæsenets Organisationsregister) kan bestå af en kode og et navn. Kode er en unik talkombination, som identificerer et organisationsenhed i sundhedsvæsenet. Så det kunne være Vaskeriet på Rigshospitalet. Navn er her navnet på enheden - Vaskeriet for eksempel.

Email er modtager-emailadresse. Består af emailAddress og relatedAgent. emailAddress er selvfølgelig en emailadresse - denne kan sagtens være en funktionspostkasse/fællespostkasse, og relatedAgent er et navn på den postkasse der skrives til. Grundlæggende er Email-området en måde at hjælpe modtageren til at oversætte Digital Post til Email, hvis det er det modtageren ønsker. Man kan for eksempel forestille sig at Rigspolitiet sender straffeattester som Meddelelser, hvor Email-området indeholder en emailadresse som den person der har bestilt straffeattesten har angivet.

SEnumber består af seNumber og companyName. seNumber - SE-nummer - er et tal som indentificerer en logisk delmængde af en virksomhed, hvis virksomheden har haft brug for moms-teknisk at dele forskellige aktiviteter. companyName er det tilhørende navn på SE-nummerenheden. På samme måde som med ProductionUnit (P-nummer), så kan det hjælpe virksomheds-modtagere med at fordele indgående Digital Post.

Telephone består af telephoneNumber og relatedAgent. telephoneNumber er selvfølgelig et telefonnummer, men formatet er ikke specificeret, så der er risiko for fejltolkning her. relatedAgent er det meningen skal indeholde navnet på modtageren. Bemærk, som med Email, at det jo ikke behøver at være en persons telefonnummer, det kan for eksempel være en afdeling. Som andre steder i MeMo vil det at benytte telefonnummer som en modtager-adresse nok kræve at to afsendere/modtagere aftaler hvordan de indbyrdes vil bruge denne information.

EID består af eID og en label. eID er jeg sikker på, det er tanken skal være et nummer som kommer fra en medarbejdersignatur - NemID for virksomhedsansatte. label forestiller jeg mig vil være navnet på den person som eID-nummeret hører til. EID-numre er den velstrukturerede udgave af AttentionPerson, men til gengæld er der, tror jeg, ikke så mange ansatte der rent faktisk har medarbejdersignaturer. Man kan sagtens forestille sig modeller for hvordan afsenderen kan være i besiddelse af RID-numre på personer de ønsker at skrive til, og man kan også forestille sig modeller for hvordan modtageren kan oversætte RID til en ansat person. Men det at bruge RID-numre til addressering vil kræve at afsender og modtager er enige om at man bruger dem.

Address består af en lang række felter til at skrive en struktureret adresse, svarende til det vi skriver på papir-breve. Vejnavn, husnummer og så videre. Under Address findes et underelement der hedder AddressPoint, som kan indeholde længde-, bredde- og højde-angivelse. Adresse er igen et område som det kan være svært at automatisere modtagerens fordeling med, men om ikke andet så kan modtageren i en manuel sortering se på netop disse adresseoplysninger i stedet for at se på indholdet, og dét kan gøre at man kan fordele mere præcist.

UnstructuredAddress svarer til Address, men er et slags fritekstområde til adresseoplysninger, hvis afsenderen ikke har struktureret adresseoplysninger i delfelter.

ContactPoint

ContactPoint er en datastruktur som udpeger et "kontaktpunk" som en myndighed har i Næste generation Digital Post. Det er altså ikke noget som almindelige virksomheder har.

Nedenfor ser vi en illustration af hvor ContactPoint er i den samlede MeMo-stuktur. Bemærk at vi her ser på kontaktpunkt-oplysningerne når de er brugt i forhold til en modtager: Recipient. ContactPoint kan, ligesom AttentionData, bruges i forhold til afsenderen - det ser vi ikke på i denne blog, men det beskrives i NgDP MeMO - afsenderoplysninger med AttentionData og ContactPoint.

Myndigheder skal på NgDP-platformen definerer et eller flere kontaktpunkter som man kan kontakte myndigheden på. Et kontaktpunkt i en kommune kunne for eksempel hedde "teknik og miljø" eller"børn og unge". Detaljeringsgraden og navngivningsformen er op til den enkelte myndighed.

NgDP udstiller web services som gør at man kan slå op og finde myndigheders kontaktpunkter i Myndighedsregisteret.

Skriver man til en myndighed skal man angive et ContactPoint. Det giver ikke mening at sende ContactPoint til borgere eller virksomheder (der ikke er myndigheder). På den baggrund er der en interessant tanke her: Når en myndighed sender Digital Post til en anden myndighed (eksempel: Rigspolitiet til Horsens kommune), så vil det der gør at modtager-myndigheden kan se at der er tale om myndighed-til-myndighed kommunikation være tilstedeværelsen af ContactPoint. Er der ikke ContactPoint i den Meddelelse der modtages, så er der ikke skrevet til myndigheden i dens rolle som myndighed. Synsindkaldelser for biler bør derfor sendes uden ContactPoint når de sendes til en kommune der ejer en bil.

ContactPoint skal indeholde et contactPointID og en label, og kan også indeholde en contactGroup. Alle disse oplysninger skal hentes ved opslag til Myndighedsregisterets webservice. contactPointID er en unik nøgle der identificerer et kontaktpunkt, mens label er kontaktpunktets brugervendte navn - eksempelvis "teknik og miljø". contactGroup vil jeg mene kan udfyldes, hvis kontaktpunktet er fundet gennem en visningsklient der tillader søgning i Kontaktgrupper.

Under ContactPoint kan der være op til to sæt af ContactInfo. Det om der skal findes et eller to sæt ContactInfo vil være noget man finder ved opslaget til Myndighedsregisteret (efter kontaktpunkter). Hvis der ved opslaget er fundet en eller to af disse så er label givet derfra, og det er forventningen at afsenderen sørger for at udfylde value med en meningsfuld værdi. Grundlæggende er ConttactInfo et område, hvor myndigheden der skrives til kan bede om uddybende information. Så det kunne for eksempel være at myndigheden der skrives til beder afsender om at tage stilling til "barnets alder" (label) og at afsender så skriver "14 år" i value.

Hvordan sikres det at det er tydeligt at der er skrevet til en myndighed

MeMO har, som det er beskrevet i version 1.1 (maj 2021), plads til at der kan skelnes mellem afsendere som er

Borgere (CPR)
Virksomheder og Myndighed (CVR)

Og tilsvarende så er der også plads i formatet til at modtagere - dem man skriver til - kan være

Borgere (CPR)
Virksomheder og Myndigheder (CVR)

Men hvordan skelner man mellem Virksomheder og Myndigheder?

Når man skriver til en myndighed - i dennes rolle af myndighed - så signalerer man det på én af to måder:

Ved at angive en værdi i Message->MessageHeader->Recipient->ContactPoint
Ved at udfylde en værdi i Message->MessageHeader->postType med værdien "MYNDIGHED".