...

Behandlingsrelationsservicen (BRS) udstillet på NSP er en service til kontrol af behandlingsrelationer. BRS tilbyder at løfte opgaven med at klassificere behandlingsrelationer imellem sundhedsfaglige personer og patienter, således at nationale serviceudbydere i sundhedsvæsenet lettere kan overholde lovkrav til kontrol af sundhedsfaglige personers adkomst til data og funktionalitet.

Servicen modtager en forespørgsel på en behandler (identificeret som person+sted), samt en patient (identificeret ved CPR), og skal afgøre hvilke kategorier af relationer der er mellem behandleren og patienten.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-39ae766a-05e8-4933-bc54-9aea0ff8451e.html" name="test" height="810" width="800">You need a Frames Capable browser to view this content.</iframe>   

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

Da der ikke findes et decideret "behandlingsrelationsregister", er det nødvendigt at udlede viden om faktiske behandlingsrelationer ved opslag i nationale registre over handlinger, registreringer og relationer indenfor sundhedsvæsenet.

Endvidere er der ofte en tidsmæssig forsinkelse i opsamling af de nødvendige informationer, og det er derfor nødvendigt at give adgang til funktionalitet og data på basis af ukomplette informationer, og efterfølgende foretage en opfølgende kontrol af den faktiske relation på et senere tidspunkt. Opslag og opfølgninger varetages af BRS - er der ikke være en acceptabel behandlingsrelation, kan det afføde en opfølgning. Kalderen angiver et sæt af kategorier der skal afføde en opfølgning og det er muligt at vælge opfølgning for alle relationer.

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

...

På NSP-miljøerne udstilles følgende webservices:

...

Notifikationsservice:
Servicen vil returnere alle notifikationer, som er adresseret til kalderen. Notifikationer er fortløbende nummererede, og kalderen kan angive et offset, der sikrer at kun de nyeste notifikationer returneres. Servicen sletter alarmer efter et centralt konfigurerbart tidsinterval. Hvis man ikke angiver offset kan man risikere at modtage de samme alarmer flere gange.
De ovennævnte services udstilles via Den Gode Webservice (DGWS 1.0.1), og kan kun kaldes af systemer der bruger et System-IDKort udstedt til forhåndsgodkendte CVR numre. IDKort skal være udstedt af SOSI-STS.

Batchjobs i Backoffice

Backoffice indeholder to batchjobs der begge afvikles periodisk.

Baggrundsjob 

Relationsopfølgning:
STS servicen indeholder et baggrundsjob, som findes i et selvstændigt modul brs-operations, der kontrollerer gemte opfølgninger Relationsopfølgning:
De gemte opfølgninger kontrolleres op imod valideringsbiblioteket for at undersøge om der er opstået relationer der giver anledning til at slette en opfølgning.

Hvis en opfølgning ikke har opnået den krævede relationskategori inden dens udløb oprettes en alarm i notifikationsdatabasen.

Jobbet afvikles ved at kalde FollowupServlet BehandlingsRelationFollowupServlet (se driftsvejledning for detaljer).

Jobbet forBehandlingsRelationFollowup består af følgende operationer:

Batchjobs i Backoffice

Backoffice indeholder et batchjobs der begge afvikles periodisk.

Oprydning:
Alarm-notifikationer replikeres til frontend i NSP-miljøerne, hvor de kan hentes med notifikationsservicen. Dette sletter dog ikke notifikationerne, så for at undgå at der blot bliver flere og flere, er der på et oprydningsjob, som løbende sletter notifikationer, som er blevet tilpas gamle.
Sletningen replikeres, så data også slettes fra de øvrige miljøer.

...

Opfølgningstabellen indeholder behandlingsrelationer, som er modtaget af behandlingsrelationsservicen, og som er sat til opfølgning, idet der ikke umiddelbart kunne opnås tilstrækkelig evidens for relationen i forhold til evidenskilderne.
Tabellen udgør en form for kø. Replikeringsjobbet læser fra denne og sender data til backend'en, hvorefter data slettes fra tabellen.

...

Opfølgningstabellen indeholder behandlingsrelationer, som er sat til opfølgning, og er blevet overført til backend'en. Data ligger i denne tabel så længe der ikke er opnået evidens for relationen, og tidsfristen ikke er overskredet.

Tidspunktet i nextCheck benyttes af opfølgningsjobbet til at vurdere om en opfølgning skal behandles på kørselstidspunktet. Den unikke nøgle svarer til den unikke nøgle på notifikationstabellen. 

NB: Jf. BRS Driftsvejledning: I release 2.1.0 er BRS ændret, så Kafka anvendes til at vedligeholde køen af bestilte opfølgninger. Anvendelsen af Kafka erstatter den tidligere followup-database. I den forbindelse behandles de bestillinger der allerede ligger i followup-databasen, således at de sættes i kø i Kafka.

...

Notifikationstabellen i Backoffice-miljøet indeholder alarm-notifikationer for behandlingsrelationer, som der ikke kunne findes evidens for indenfor tidsfristen.

...

Som det fremgår af diagrammet, så har vi indsat nogle nøgler C? og D?, Se desuden https://www.nspop.dk/display/public/web/BRS+-+Driftsvejledning, så vi kan lave en kobling til evidenslogninger. De steder, hvor der udføres en indsamling af data, starter nøglen med D og de steder, hvor der udføres et tjek på data, starter nøglen med C.

Datamodel for LPR:

...

Data fra LPR3 findes i en tabel med dette skema:

...

Data fra SSR findes i en tabel med dette skema:

...

Data fra stammer fra Henvisningshotellets tabel 'Refhost' med dette skema:

...

Der anvendes Kafka til overførsel af opfølgningsbestillinger fra frontend til backend. Beskederne indeholder følgende attributter:

...