Næste Generation Digital Post - returdata ser fattigt ud

I Næste generation Digital Post kan vi bruge returdata / returnData til at skabe tråd i en udeksling af beskeder mellem to parter. For eksempel myndighed-myndighed eller myndighed-borger.

returdata skal ersatte flere ting i det vi kender i dag i Digital post:

  • de fire DKAL-felter
  • dkalafsendermetadata.xml filen
  • tråd-id-feltet

I Convergens bruger vi i dag dkalafsendermetadata.xml til at løse nogle behov som vores kommunale kunder har.

Jeg har set på hvordan der (som NgDP MeMo ser ud lige nu) kan skiftes til returdata-faciliteten. Kilde: Materiale til workshop om MeMo-format 1. marts.

Jeg tror det ender i at vi kommer til at savne noget.

De to meningsbærende felter der er til rådighed hedder

  • CaseID = en sagsid
  • Comment = skriv hvad du vil (antager jeg)

Umidelbart synes jeg det ser ud til at de øvrige felter er IDer til at binde ud- og indgående meddelelse sammen.

 

Lad os tage et par behov der illustrerer problemstillingen.

 

Flere afsendersystemer skal kunne modtage svar

Æblerød kommune har tre systemer der danner udgående Digital Post. 

Hvert af disse tre system sender nu en meddelelse, og angiver i CaseID henholdsvis xxx, yyy og zzz.

De tre modtagere svarer nu på meddelelserne, og de overholder konventionen og sikrer at returdata indeholder de originale informationer (+ egne returdata).

De tre (svar)meddelelser kommer nu ind på Æblerød kommunes IO-manager. Denne IO-manager skal nu bestemme hvilke tre systemer svarene skal placeres i. Men det eneste IO-manageren har adgang til er en CaseID. Og en CaseID indeholder normalt ikke information om hvad systemet der har sagen hedder.

Er løsningen at de tre systemer og IO-manager skal bestemme en konvention for at navngive afsender/modtager-systemer som en del af CaseID?

Eller kan/skal vi "hacke" i Comment-feltet?

 

Part-information ønskes tilbage i svar

Lad os sige at Æblerød kommune skriver til Lavenæs kommune.

Man skriver fra et system som ikke har ESDH-faciliteter, så der findes (endnu) ikke en CaseID. Eksempel på sådan en forsendelse er når man benytter doc2mail printerdriveren direkte fra for eksempel MS-Word.

Man skriver om borgeren med cprnummer aaaaaa-bbbb. Så man angiver i attention-delen af headeren at det er aaaaaa-bbbb som er primær part.

Man kan ikke i ReturnData angive den primære part. 

Efter forsendelsen sørger Æblerød kommunes IO-manager for at journalisere meddelelsen på en passende sag, baseret på primær part i attention og KLE - også fra attention.

Når nu Lavenæs kommune svarer om borgerens sag, så skriver man desværre ikke fra et ESDH-system som sørger for at berige attention med primær part. Eksempel: Man skriver direkte fra MS-Outlook via en Sikker Mail løsning.

Nu modtager Æblerød kommune svaret. Der er ikke skyggen af et CPRnummer på den primære part. Der er ikke en CaseID i returnData.

Så hvordan skal Æblerød kommunes IO-manager "hægte" svaret op på den sag som ligger og venter på svar?

 

Debat

Jeg har startet en diskussion om emnet her: https://www.digitaliser.dk/forum/3987965

 

0 kommentarer til artiklen

Skriv de tegn, du ser på skærmen,
så vi ved, du ikke er en robot”
Indtast den viste kode: