ADR 3; maximale duur/responsetijd van de lokalisatie vraag

[RonObbens]

Bij lokalisatie zijn meerdere systemen betrokken; de NVI en, indien er gegevens zijn, één of meerdere LMR's. Zowel de NVI als elk LMR kent enige verwerkingstijd. Deze ADR stelt voor dat er een bovengrens is aan de tijd die de totale lokaliatie mag duren. Sneller is altijd beter, als streef waarde wordt daarom uitgegaan van XXX. Als bovengrens wordt YYY gedefinieerd als acceptable waarde.

De responstijd van de lokalisatievraag wordt weergegeven in seconden. Voorstel is maximaal 3 seconden per lokalisatievraag.

Overwegingen

Totale responstijd is opgebouwd uit losse requests.Het gaat hier om de totale responstijd van sequentie van interacties.
Ttotaal = Tps + Tnvi + Tlmr

De pseudoniemen, NVI en mogelijk toestemmingsregister zijn redelijk te voorspellen. De LMR's zijn lastiger in te schatten. Dit hangt o.a. af van:

• Welke queries moet een LMR kunnen beantwoorden?
• Is een LMR een geoptimaliseerd systeem voor lokalisatie of een laag over bijv. een EPD heen wat misschien meer tijd vraagt.
• Bij het benaderen van meerdere LMRs, krijg je snelle antwoorden eerder binnen, of wacht je op de traagste?

Een LMR zal ontwikkeld worden op basis van de informatiestandaard van de NEN Lokalisatie. Er zal een inventarisatie bij leveranciers en bronhouders gedaan worden of zij het realistisch achten een systeem te kunnen bouwen die de voorgestelde maxTlmr kunnen afhandelen.

Afhankelijk van de gekozen topologie zoals besproken in #15 , benadert de raadpleger rechtstreeks de NVI en LMRs of via een "gateway".

Afhankelijk of er over de resultaten nog operaties moeten worden gedaan zoals ontdubbeling kan de raadpleger wel of niet een deelresultaat al gebruiken, of moeten wachten op de traagste LMR.

Voor de governance:
Hoe ga je toezicht houden op responstijd en handhaven? Is het realistisch dat een groot deel zich houd aan de responstijd, als het niet realistisch is, misschien rekening houden met trage partijen die ruim buiten het afgesproken maximum uitkomt zonder dat dit alle interacties negatief beïnvloed.

[meneerhenk]

Vanuit onze UI/UX expert @ iRealisatie
over snelheden: https://www.nngroup.com/articles/response-times-3-important-limits/

• Alles trager dan 0.1s voellt niet meer alsof je direct met een systeem interacteert
• Alles trager dan 0.2s per interactie wordt bewust waargenomen als 'het systeem is iets voor me aan het doen'
• Alles trager dan 1s zorgt voor onderbrekingen in je aandacht
• Alles trager dan 10s is 'ik ga koffiezetten' en vereist duidelijke feed forward over hoe lang je moet gaan wachten.

Normaal is dat het overgrote deel van je interacties onder de 0.2s response times heeft. En voor alle gebruikelijke acties je flow of though niet wordt onderbroken (<1s).

[RizAhmed85]

Het voorstel van 3 seconden wordt 'veel' beschouwd. Inclusief ophalen van gegevens zou dit binnen een seconden moeten kunnen. De bovengrens zou op 500ms moeten zitten om de user interactie te bevorderen.

Voorstel zou kunnen zijn dat 99% van de verzoeken binnen 500ms worden afgehandeld.
De vraag is wanneer je een technische time-out identificeerd (inclusief retry) en dan is die bovengrens belangrijk.
De user time-out zou dan 3 technische retries kunnen zijn.

De use-case die het 'snelst' een response vereist bepaalt daarmee de drempelwaarde.

Het gaat hier dan om de totale 'vraag' van de NVI.
Reikwijdte van de 'vraag' (voorziening of ook achterliggend netwerk)
Het betreft een synchrone uitvraag (response is gelokaliseerde gegevens en geen HTTP 200 bijv.)

[albertvlug]

Voordeel van centrale NVI is dat de eerste stap ('waar vraag') binnen halve seconde gedaan kan zijn. Decentraal is dat niet te garanderen.

[RonObbens]

We moeten door voor plateau 1 met inrichting van de NVI. Voorstel is daarom, hoort ook bij andere ADR, waar ik hem wat uitgebreider op zal nemen, dat we nu voor een centrale NVI gaan waarin in ieder geval de 5 geprioriteerde uitwisselingen in worden vormgegeven. Deze NVI kan door meerdere partijen/dienstverleners worden aangeboden waarbij die ontstane NVI's dan continu synchroniseren.