Introduktion til afsenderoplysninger

I denne blog skriver jeg om hvordan man kan forsyne en Digital Post Meddelelse med god afsenderinformation i Næste Generation Digital Posts MeddelelsesModel (MeMO).

Lige som med papir-breve så kan også Næste Generation Digital Post forsynes med information om hvem man sender til og om hvem der er afsenderen.

Når jeg en sjælden gang modtager et papir-brev så er jeg interesseret i om det er til mig eller en anden i husholdningen, og så er jeg interesseret i hvem afsenderen er.

Det som afsenderen skriver på brevet - om sig selv - gør at jeg som modtager kan vælge at sortere hvor posten skal hen.

Men ikke mindst så er god information om afsenderen også det der gør at jeg kan svare tilbage igen på en god måde. Til rette modtager. Som afsender bør man være meget interesseret i at den man skriver til er i stand til at svare korrekt tilbage igen.

Og det gælder selvfølgelig også for Digital Post, hvor MeddelelsesModellen har masser af mulighed for at afsenderen fortælle om sig selv, og om hvor eventuelle svar ønskes sendt hen.

Blogserien

Bloggen her er den tredje 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 25/3-2020. MeMO er offentligt tilgængelig i version 0.9 Jeg har en forventning om at der kun vil være ganske få ændringer i formatet frem mod den færdige version.

MeMo og afsenderoplysninger

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

I denne blog ser jeg på MessageHeader, og det er nu Sender jeg går længere ned i - hvilke faciliteter findes der til at jeg som afsender kan sige noget om mig selv?

Basal afsenderinformation

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

idType vil for min målgrupper altid være "CVR". Hvis der her i stedet stod "CPR", så ville afsenderen være en borger. Så både myndigheder og virksomheder skal altså her angive "CVR".

senderID vil være afsenderens CVRnummer.

label skal udfyldes med afsenderorganisationens navn. Navnet skal hænge sammen med det CVRnummer der er brugt.

Ovenstående er nok til at fortælle modtageren om hvem der er afsender. Det er minimums-oplysningerne. Men der findes så muligheder for at fortælle mere. Og det kan give værdi både for den der sendes til, men også for os som afsender.

AttentionData

Vi her ser på AttentionData når de er brugt i forhold til det at være afsender: Sender. AttentionData kan også bruges i forhold til modtageren, og det har jeg skrevet om i NgDP MeMO - adressering med AttentionData og ContactPoint.

AttentionData indeholder en lang række under-noder som man kan vælge at udfylde med oplysninger om os som afsender. Så vi skriver her flere linjer "på bagsiden af kuverten".

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 modtageren noget om hvem afsenderen er. Det svarer til det der er på bagsiden af et papir-brev. Og ved at udfylde disse oplysninger gør man det muligt for modtageren at svare tilbage og inkludere de samme oplysninger i svaret - men blot knyttet op som AttentionData på Recipient; ved at give rige afsender-oplysninger kan du blive belønnet med at få rige modtager-oplysninger tilbage.

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". Så det vil altså være afsenderens navn. Det er oplagt her at skrive navnet på den person der har trykke på send-knappen, hvis der altså er sådan en person (hvis Meddelelsen er sendt helt maskinelt er der nok ikke sådan en). Om borger.dk/virk.dk-Visningsklienterne vælger at vise denne information vides ikke, men andre visningsklienter kan vælge at gøre det. Hvis man kan udfylde den vil jeg anbefale at gøre det.

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, specielt når en virksomhed sender Digital Post, da det giver modtageren mulighed for at svare tilbage igen til samme P-nummer. Hvis man er en myndighed der sender, så er det mere relevant at se på ContactPoint-faciliteterne, der er mere rige.

ContentResponsible giver mulighed for at sige noget mere præcist om hvem der er ansvarlig for Meddelelsen der er sendt. Tidligere har vi set at man som virksomhed eller Myndighed skal angive sit CVRnummer (senderID), men det kan være meget upræcist hvis der er tale om en stor organisation. Men her kan vi angive en contentResponsibleID som det ikke er defineret hvad er, så den ignorerer vi, og så kan vi angive label, som er en tekst, det kunne for eksempel være "Rigshospitalets vaskeri" eller "Andeby Taxa - Bogholderiet". Visningsklienterne på borger.dk og virk.dk vil vise den label der angives her.

GeneratingSystem kan bruges til at angive hvilket IT-system der har oprettet Meddelelsen. Der kan her bruges en generatingSystemID og en label. Det er ikke defineret hvordan de skal bruges, men ved at angive dem med værdier der er de samme altid, så giver man modtageren mulighed for at sortere posten til det rigtige sted. Så en label kunne for eksempel være "Rykkersystemet" eller "Synsindkaldelsessystemet", og generatingSystemID bør så være nogle unikke værdier som hænger sammen med disse (eksempelvis "RYKKERSYS", "SYSIND").

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 Blodbanken på Rigshospitalet. Navn er her navnet på enheden - "Blodbanken" for eksempel. Hvis afsenderorganisationen har en SOR-kode, så giver det rigtigt god mening at udfylde den. Det giver mulighed for at modtageren kan sortere godt, og det giver mulighed for at den kan blive udfyldt i svarets AttentionData når der svares på Meddelelsen.

Email er afsenders 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 fra. Om Email vises i Visningsklienter på borger.dk/virk.dk vides ikke. Men andre visningsklienter kan vælge at vise oplysningen.

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, og værdien kan blive sendt tilbage igen ved retursvar, hvis den svarende organisation vælger at sende den retur.

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å den ansvarlige afsender. 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. Om oplysningen vises i Visningsklienterne på borger.dk/virk.dk vides ikke, men andre visningsklienter kan vælge at vise den.

RIDData består af ridNumber og companyName. ridNumber er et nummer som kommer fra en medarbejdersignatur - NemID for virksomhedsansatte. companyName er navnet på den virksomhed som RID-nummeret hører til. RID-numre er den velstrukturerede udgave af AttentionPerson, men til gengæld er der, tror jeg, ikke så mange ansatte der rent faktisk har medarbejdersignaturer. Hvis man som afsender udfylder RIDData giver man modtageren mulighed for at vælge at returnere de samme RIDData i svarets AttentionData, og det vil så kunne bruges til sortering af svaret.

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. Om Address vises i Visningsklienter på borger.dk/virk.dk vides ikke. Men andre visningsklienter kan vælge at vise oplysningen.

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. Jeg ser nu på kontaktpunkt-oplysningerne når de er brugt i forhold til en afsender: Sender. ContactPoint kan, ligesom AttentionData, bruges i forhold til modtageren - det ser vi ikke på i denne blog.

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 vil udstille 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 under Sender-området af Headeren kombineret med at der også er ContactPoint under Recipient-området af Headeren.

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 vil givetvis være en unik nøgle der identificerer et kontaktpunkt, mens label vil være kontaktpunktets brugervendte navn - eksempelvis "teknik og miljø". contactGroup ved jeg ikke hvad bruges til.

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. Hvis der ved opslaget er fundet en eller to af disse så er label givet, 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.

Når man sender en Digital Post Meddelelse, og man vælger at knytte ContactPoint-oplysninger til Sender-området, så er det et meget kraftigt signal til modtageren om hvor man ønsker at svar skal sendes hen. Hvis den man sender til er en borger (der læser gennem en Visningsklient på borger.dk) eller en virksomhed (der læser gennem Visningsklienten på virk.dk) så kan man forvente at et svar vil indeholde de samme ContactPoint-oplysninger i AttentionData under Sender-området.

Hvis den man sender til er en myndighed, eller en virksomhed der har eget modtager-system, så kan man ikke være sikker på at svaret vil indeholde de samme ContactPoint-oplysninger i AttentionData under Sender-området, da det er op til disses afsender-systemer at sørge for at genbruge disse oplysninger i svaret.

Om det at skrive fra en myndighed til en myndighed

MeMO har, som det er beskrevet i version 0.9 (marts 2020), plads til at der kan skelnes mellem afsendere som er

• Borgere
• Virksomheder
• Myndigheder

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

• Borgere
• Virksomheder
• Myndigheder

Det at man som afsender og modtager tydeligt kan angives som myndighed er nyt i Næste generation Digital Post. Og det er en god idé.

Det at angive at der er tale om en myndigheds-afsender eller -modtager gøres ved at man i idType angiver "MyndighedsID" i stedet for "CVR", og i senderID eller recipientID angiver man en "MyndighedsID" frem for et CVRnummer.

Der er dog et problem: Der er endnu ikke vedtaget en model for hvordan myndigheder får en MyndighedsID. Så man kan ikke bruge denne facilitet i dag.

Lige nu ser det ud til at det ikke bliver muligt tydelig at angive at man skriver til en myndighed i dennes rolle som myndighed.