...

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/39ae766a-05e8-4933-bc54-9aea0ff8451e.html" name="test" height="1020" width="1000">You need a Frames Capable browser to view this content.</iframe>   

...

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

Logisk arkitektur

Systemet er opdelt i to dele "frontend" og "backend":

1. SDM4 stamdata importeres. Der er i dag 4 registre som importeres og danner evidens-grundlag for visse behandlingsrelationer (henvisningshotellet/Refhost, Landspatientregisteret/LPR, ydelsesregisteret og sikrede registeret).
2. Disse replikeres løbende fra den centrale database til cNSP'ens og dNSP'ernes databaser.
3. Service providers (fx FMK og Sundhed.dk) kalder BRS for at registrere en adgang til data. Der angives hvilken person fra hvilken organisation, der har tilgået (eller skal til at tilgå) hvilken patient. Samtidig angives om, og i givet fald hvornår i fremtiden der ønskes opfølgning.
4. BRS servicen checker først om der kan etableres tilstrækkelig evidens for en behandlingsrelation ud fra eksisterende evidens kilder.
5. Hvis ikke, så skrives opslaget til Kafka.
6. FollowupServlet kaldes løbende, og henter et batch fra Kafka.
7. Bestillingerne behandles ud fra stamdata, eller lægges tilbage i køen hvis de først skal behandles senere.
8. Notifikationer til service providers replikeres til databaserne på NSP'erne.
9. Service provider (fx FMK) kalder notifikations-servicen for at hente de genererede notifikationer. Ud fra disse kan den data-ansvarlige for service providerne (fx FMK eller Sundhed.dk) følge op på, om opslagene alligevel var berettigede, fx stikprøvevis.
10. Efter en fastsat periode slettes notifikationerne, uagtet om de er hentet af service providerne eller ej.

Logisk arkitektur

...

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

...

Nedenstående blueprint viser lagdelingen i BRS. For yderlige detaljer henvises der til de enkelte services.

BRS-Frontend

...

Behandlingsrelation

...