NgDP MeMO - adressering med AttentionData og ContactPoint

NgDP MeMO - adressering med AttentionData og ContactPoint

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 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.

Siden er opdateret 26/3-2020 da MeMO-formatet er opdateret til version 0.9.

MeMo og adressering

Her ser vi den fulde MeMO-struktur:

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?

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, så er det virksomhedens 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.

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.

RIData 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. 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.

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. 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 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.

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.