Förtydliga regler kring paketering av poster i en Update-transaktion

[Henrik Emilsson]

Vi hade en genomgång av självdeklaration för tjänsteproducenter med A&R och ICC i dag. En sak som dök upp var att det borde framgå tydligare en regel eller ett krav på att en Update-konsument inte ska skicka en transaktion med en post i (finns vissa som gör detta i dag).

Jag har kollat igenom den senaste TKB för EI, både version 1.0.1 som är den releasade samt den version som ligger i Trunk. Och jag tror det behöver förtydligas med avseende på transaktioner och minimala antalet poster per transaktion. Dvs, en regel som säger att det måste paketeras (inte bara att det ska gå att konfigurera). Kanske också bör hänga ihop med att tidsintervall och paketering ska synkas så att det skickas om tidsintervallet har inträffat och att alla poster som är upparbetade ska paketeras i en transaktion (eller flera transaktioner om antalet poster överstiger 1000).

Det som finns i dag är:

R8: Poster med samma unika nyckel skall inte skickas oftare än var 5:e minut även om det skett fler än en matchande händelse i källsystemet under den tidsrymden. Detta intervall bör vara konfigurerbart. Under en grundladdning får inga dubbletter (med avseende på fälten som utgör del i postens unikhet) förekomma under hela körningen (d.v.s. inte bara inom ett Update-anrop, utan sammantaget för alla Update-anrop som sker under grundladdningen).

R11: Tjänstekonsumenten ska kunna konfigureras med avseende på hur många engagemangsposter som paketeras i varje Update-anrop, utan krav på release eller ominstallation. De engagemangsposter som är färdiga att skickas under det intervall som är angivet I R8 skall skickas enligt max antal tillåtna poster som är angivet I SLA-krav under “Last”. Exempel: Finns 500 nya poster så anropas Update 1 gång med 500 poster i en och samma transaktion. Finns 1003 nya poster så anropas Update 2 ggr, ett anrop på 1000 poster och ett på 3 poster. Finns 2000 nya poster så anropas Update 2 ggr, vardera anrop med 1000 poster.

Samt en skrivning i SLA-tabellen kring Last:

En begäran ska kunna innehålla upp till 1 000 engagemangsposter.

[Thomas Fafoutis]

Är detta ett krav vi vill ha i TKB:n (för att gälla generellt för alla EI implementationer) eller kan det vara ett fall för respektive specifika implementation?

[Henrik Emilsson]

Jag uppfattar reglerna 8 och 11 som generella för alla tjänstekonsumenter av Update, men de går i dag att misstolka. Så ett förtydligande enligt förslaget skulle göra det lättare att förstå att paketering ska göras.

[Thomas Fafoutis]

Om jag tolkar dig rätt så förespråkar du att vi ska förtydliga att poster alltid ska grupperas (i grupper om max 1000). Alltså aldrig tillåta att en konsument (källsystemet som anropar EI-Update) att skicka in enstaka poster. Det är då inte enbart ett förtydligande utan ett nytt krav. Implementationer som idag inte gör så får därmed kravet att byta logik.

[Henrik Emilsson]

Enligt Rolf Rönnback (ICC) och Johan Eltes (A&R) så är det så dessa regler ska tolkas, dvs det är inget nytt krav. Men däremot så är dagens skrivning öppen för tolkning och det går att uppfylla reglerna fast man skickar in enstaka poster. (det står i R11 "ska kunna konfigureras" och att "max antal tillåtna poster" ska vara 1000. ==> 1 post i taget bryter inte mot det)

[Rolf Rönnback]

Om man bara kan skicka en post per anrop så är ju antalet poster per anrop inte konfigurerbart ;-) Exemplet som finns i TKB är nog nyckeln till förståelse. Jag försöker beskriva min tolkning av kraven nedan:

---Löpande uppdatering • Uppdatering måste ske inom det aktualitetskrav som står i respektive TKB (typiskt en timme). • Man får inte skicka dubbletter oftare än var femte minut. Detta intervall bör vara konfigurerbart. • Uppdatering ska endast ske var femte minut för att filtrera bort dubbletter. • Antal poster i anrop ska vara konfigurerbart upp till maximalt 1000 poster. • Anrop får inte ske parallellt om det medför att poster med samma identitet sänds samtidigt. Sekvensbeskrivning: 1) Man samlar alltså på sig alla EI-poster i buffert 1 under fem minuter. 2) Man byter sedan till buffert 2. 3) Man rensar buffert 1 från dubbletter. 4) Man påbörjar sändningen av innehållet i buffert 1 med max 1000 poster per anrop. 5) Man gör anrop till dess bufferten är tom. Jag antar att man ska gå på huvud-SLA vilket är maximalt en transaktion (anrop) per sekund(?) ---Grundladdning • Anropsfrekvens ska vara konfigurerbar men förvald till 5000ms. • Maximalt 1000 EI-poster per anrop.

[Rolf Rönnback]

Atlassian är så efter. Det går inte att formatera texten vettigt. Tips: kopiera ut den till Word så att den blir läsbar.

[Thomas Fafoutis]

Det är tydligt att vi behöver förtydliga dessa regler. Jag tycker inte att det idag framgår huruvida man måste skicka som oftast max med frekvensen 5min, således inte tillåta oftare frekvens. Det jag tolkar från regelverket är att man inte får skicka dubbletter oftare än var 5:e minut. Men poster som inte är dubbletter skulle kunna skickas oftare. Om jag läser Henriks första inlägg och försöker förstå det så är det just det vi vill styra.

Är det rätt uppfattat?

[Rolf Rönnback]

Instämmer i att det enda som är tydligt är att det är otydligt. Min sekvensbeskrivning ovan bygger på det exemepl som TKBn innehåller. Man behöver inte skicka skurar med anrop var femte minut om man kan garantera att man inte skickar dubbletter oftare än var femte minut. Om jag som aldrig har sett ett journalsystem ska spekulera så misstänker jag att en fem minuters fördröjning ska hantera journalsystem som anser att patientjournalen är uppdaterad varje gång en tangent trycks ner. Om man skickar var femte minut så hinner kanske läkaren skriva klart sina journalanteckningar för den patienten och det blir då bara en EI-post av hela journaluppdateringen. En alternativ lösning är ju att man detekterar dubbletter och håller på dem i fem minuter innan man skickar dem. Men då får man ju ha en kö per informationsmängdsdubbletter vilket känns opraktiskt. Likaså kommer man ju då att skicka upp alla dubbletter förr eller senare vilket är precis det vi vill undvika. Men vet man att journalsystemet inte kommer att generera en dubblett inom fem minuter så kan man ju skicka upp allt undan för undan. Femminuterskravet härstammar rimligen från att vi vill ha EI-information så aktuell som möjligt samtidigt som vi vill hålla ner antalet poster. Antagligen har man då funnit att fem minuter är en acceptabel fördröjning som minimerar onödiga poster (dubbletter) utan att försämra aktualiteten nämnvärt. Jag tror att en muntlig avstämning är befogad för att undvika missförstånd.

[Rolf Rönnback]

Jo en sak till. Notifieringstjänsten lär vara implementerad så att den hanterar alla EI-poster som kommer in i ett anrop. Skickar man in en EI-post per anrop blir det en hiskelig mängd utgående notifieringsanrop från NTjP.