Page History
...
Hvis en serviceudbyder giver adgang til en bruger under forudsætning af at brugerens adkomst senere kan bekræftes, men det ikke sker, udsteder BRS en alarm, som serviceudbyderen kan agere på (en manuel opfølgning). 
Systemet er opdelt i to dele "frontend" og "backend".
Software Blueprint
Nedenstående blueprint viser lagdelingen i BRS. For yderlige detaljer henvises der til de enkelte services.
BRS-Frontend
Frontend'en indeholder behandlingsrelationsservicen og notifikationsservicen, som er de webservices, der kaldes udefra, fra eksempelvis FMK. Herudover afvikles et job som løbende replikerer behandlingsrelationer, der er sat til opfølgning, til backend'en.
Frontend'en er installeret i dNSP-miljøerne (decentral National Service Platform), samt til i cNSP-miljøet (central National Service Platform).
Frontend Blueprint
Nedenstående blueprints viser lagdelingen for henholdsvis behandlingsrelationsservicen og notifikationsservicen
Behandlingsrelation
Notifikation
BRS-Backend
Backend'en indeholder en webservice, som modtager de data, der replikeres fra frontend'en. Herudover afvikles der et batchjob, der foretager løbende opfølgning på, om der er opnået evidens for de behandlingsrelationer, der er sat til opfølgning, og opretter alarm-notifikationer i de tilfælde, hvor evidens ikke blev opnået indenfor tidsfristen. Endelig afvikles et andet bachjob, der løbende sletter gamle notifikationer.
Backend'en er installeret i NSP's Backoffice-miljø (tidligere benævnt DoDi).
I Backoffice opsamles data fra følgende kilderegistre:
...
Data indsættes i de samme MySQL databaser, som BRS anvender, men det foretages i praksis af separate stamdata-importere.
Disse data, samt de notifikationer, der er oprettet af opføgningsjobbet, replikeres løbende til NSP-miljøerne, så data er tilgængelige for frontend'en. Denne replikering foretages i praksis som MySQL-databasereplikering.
Backend Blueprint
Nedenstående blueprints viser lagdelingen for replikering og opfølgning
Replikering og Opfølgning
RelationRelayer
Både behandlingsrelation og opfølgningsjob (Followupjob) kalder RelationRelayerInterface, som bruger en kalder alle underliggende RelationRelayers.
Blueprint for opbygningen af RelationRelayer service ser således ud.
Logisk arkitektur
...