• Created by Unknown User (klaus.munk@capgemini.com), last modified by SIZR on 22-11-2022


INDHOLD

Beskrivelse

Behandlingsrelationsservicen giver adgang til at verificere hvorvidt der findes en aktuel behandlingsrelation mellem en patient og en sundhedsperson.

Support ansvarlig: Trifork
NSP: Behandlingsrelationsservice (BRS) - LeverancebeskrivelseFor at gøre det nemmere at verificere en aktuel behandlingsrelation, tilbyder SDS en national behandlingsrelationsservice (efterfølgende ”BRS”), som alle udbydere af nationale sundheds-it tjenester kan anvende til at verificere eksistensen og kvaliteten af en behandlingsrelation.
Informationen om, at en patient er ”i behandling”, er i princippet en afledt information der kan søges bekræftet ved opslag i diverse registre. Servicen opsamler og anvender informationer om eksisterende behandlingsrelationer fra følgende evidenskilder:
- Henvisningshotellet
- Landspatientregistret
- Ydelser
- Sikrede (Assigned doctor)
Desuden benyttes en intern NSP microservice SORES til SOR/SHAK mapning og opslag

Benytter sin egen whitelist: register_notifications.whitelist i BRS databasen "register_notifications"

Forretningsmæssig motivation
- Behandlingsrelationsservicen tilvejebringer en enkel it-teknisk måde at verificere og dokumentere en behandlingsrelation, der har været anvendt til informationsadgang. Servicen giver dermed mulighed for at etablere en kosteffektiv systemteknisk overholdelse af gældende lovgivning.
- Behandlingsrelationsservicen formulerer og tilbyder en ensartet klassifikation af behandlingsrelationer, der kan bruges på tværs af services og i en lang række anvendelsesscenarier, hvor der er krav til kvaliteten af en given behandlingsrelation. Servicen giver med andre ord en fælles fortolkning af begrebet behandlingsrelation.
- Behandlingsrelationsservicen giver mulighed for at optimere og effektivisere den opfølgende kontrol ved f.eks. foretage mere kvalificerede stikprøvekontroller

Produktet består af en it-service, der anvender de ovenfor nævnte registre til at kvalificere en given behandlingsrelation. BRS udbydes på NSP, så servicen er tilgængelig for alle sundhedsvæsenets parter under fælles og velkendte vilkår. Produktet giver mulighed for at serviceudbydere på en ensartet og veldefineret måde kan tilgå informationer fra en række relevante registre med henblik på at kunne vurdere, om der er tilstrækkelig evidens for en given behandlingsrelation.

BRS klassificerer behandlingsrelationer på en ordnet skala, arrangeret efter ”styrken” af behandlingsrelationsevidens, hvor ”A+” pt. er den kategori, der beskriver relationer med stærkest evidens for en aktuel behandlingsrelation.

Skalaen for klassifikationerne er:
- Kategori A+ ”Direkte behandlingsrelation”: Eksplicit relation (f.eks. henvisning) mellem navngiven behandler og navngiven patient på et kendt tidspunkt.
- Kategori A ”Samme tid, samme behandlingssted”: Patient og Behandler var på samme behandlingssted på samme tid.
- Kategori B ”Generel behandlingsrelation”: Generel behandlingsrelation, f.eks. at patienten har udpeget en læge som ”egen læge”.
- Kategori C ”Historisk betinget behandlingsrelation”: Historisk betinget behandlingsrelation. Patient og Behandler har været i kontakt tidligere.
- Kategori D ”Kan ikke afklares pt.”: Ingen evidens for nuværende.
- Kategori E ”Kan ikke afklares”: Ingen evidens hverken nu eller senere.

Tjenesteudbydere skal derfor overveje, hvorledes BRS bedst anvendes både i forhold til aktiv adgangskontrol og til opfølgende kontrol.
BRS erstatter ikke eksisterende sikkerhedsforanstaltninger, men kan indgå i foranstaltningerne og bidrage til at målrette sikkerhedsindsatsen og derigennem styrke dokumentationen af en aktuel behandlingsrelation imellem patient og sundhedsperson.

Forretningsanvendelse

^^Tilbage til toppen^^



Relaterede registre og services

Applikationsbeskrivelse

^^Tilbage til toppen^^

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.

Behandlingsrelationsservicen giver adgang til at verificere hvorvidt der findes en aktuel behandlingsrelation mellem en patient og en sundhedsperson.

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.
Der angives ligeledes et succeskriterie i form af et sæt af kategorier, der antages at være acceptable behandlingsrelationer. Skulle der ikke være en acceptabel behandlingsrelation, kan det afføde en opfølgning. For at understøtte dette, kan kalderen angive et sæt af kategorier der skal afføde en opfølgning. Dette kan også være sat til alle relationer

Benytter sin egen whitelist: register_notifications.whitelist i BRS databasen "register_notifications"

Behandlingsrelationsservicen kan tilgås i de decentrale NSP-miljøer (dNSP) under adressen: [miljøurl]/brs-nsp/service/brs, hvor den sætter operationen “treatmentRelation” til rådighed.
WSDL: https://wsdl.nspop.dk/brs-nsp/service/brs?wsdl
Notifikationsservicen udstilles på NSP'erne under adressen [miljøurl]gos/service/notification, hvor den sætter operationen “notificationQuery” til rådighed.
WSDL: https://wsdl.nspop.dk/brs-nsp/service/notification?wsdl

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.

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

BRS kan anvendes på forskellige måder af udbydere af nationale services. Den optimale anvendelse af BRS kan afhænge af systemtypen, hvorledes udbyderens tjeneste bliver anvendt, krav til særlig høj grad af robusthed hos tjenesteudbyderen etc. I nogle tilfælde vil den samme tjenesteudbyder endda med fordel kunne anvende servicen på flere forskellige måder:
- Anvendelse af BRS i forbindelse med adgangskontrol til on-line opslag
- Anvendelse af BRS til opfølgende kontrol

BRS servicen består af følgende applikationer og services:
------------------------------------------------------------

1) Behandlingsrelations applikationen giver adgang til at verificere hvorvidt der findes en aktuel behandlingsrelation mellem en patient og en sundhedsperson.
Applikationen 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.
Der angives ligeledes et succeskriterie i form af et sæt af kategorier, der antages at være acceptable behandlingsrelationer. Skulle der ikke være en acceptabel behandlingsrelation, kan det afføde en opfølgning. For at understøtte dette, kan kalderen angive et sæt af kategorier der skal afføde en opfølgning. Dette kan også være sat til alle relationer.
++ treatmentRelation: Denne operation tager en soap besked som input, indeholdende en header og en body. Headeren indeholder en wsse header samt en medcom header som specificeret i Den Gode Webservice (DGWS) version 1.0.1. IDKortet i headeren skal være på niveau 3 og udstedt af SOSI-STS. Behandlingsrelationsservicen giver mulighed for at bestille opfølgninger gennem brug af notifikations servicen.

2) Notifikation Applikationen 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.
++ notificationQuery: Man kan hente notifikationer der er ”udstedt” til ens eget CVR nummer – altså notifikationer, hvis QueryableCvr matcher CVR nummeret i headeren ved kaldet til Notifikationsservicen. Bemærk at CVR nummeret ikke indgår som en eksplicit parameter, da det er indeholdt i IDKortet, der optræder i soap headeren.
Denne operation tager en soap besked som input, indeholdende en header og en body. Headeren indeholder en wsse header samt en medcom header, som specificeret i Den Gode Webservice (DGWS) version 1.0.1. IDKortet i headeren skal være på niveau 3.

3) ReplicationJob: overfører opfølgninger (kø) til backend ReplicationService

4) 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
4a) Replication: modtager data fra frontend ReplicationJob
4b) FollowupJob: BRS relationsopfølgning i Backend afvikles periodisk. Schedule for jobs kan konfigureres vha. en cron expression, Verificerer om ønsket evidensniveau er opnået. Genererer notifikationer hvis tidsfristen for ønsket evidens er overskredet. 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 via replicationjob.
4c) CleanupJob, BRS oprydning i Backend afvikles periodisk. Schedule for jobs kan konfigureres vha. en cron expression, Sletter forældede notifikationer. 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.

Datastruktur, Sundhedsdataregister: Behandlingsrelationer (BRS)

^^Tilbage til toppen^^

Register properties:

Behandlingsrelationsservicen giver adgang til at verificere hvorvidt der findes en aktuel behandlingsrelation mellem en patient og en sundhedsperson.

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.

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.

Registeret indeholder derfor kun bestilte opfølgninger samt resulterende notifikationer.

Der er to typer databaser i datamodellen:
En opfølgningsdatabase (followup)
En database med registre og notifikationer samt whitelist (register_notifications)

Entitetsbeskrivelser

BRS Opfølgning (kø)

^^Tilbage til toppen^^

Opfølgningstabel på dNSP og cNSP

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 ("BRS Opfølgning behandling"), hvorefter data slettes fra tabellen.

CVR-nummeret bestemmer hvem der har adgang til eventuelle notifikationer. uid benyttes som identifikation af rækker over hele systemet, på tværs af NSP-miljøer. Grunden til at pk ikke kan benyttes er, at den ikke er unik på tværs af NSP'erne.

Objektet indeholder informationen:
--------------------------------------
pk -- Primær nøgle
queryableCvr -- CVR-nummer
externalReferenceId -- Id i kaldende system
Uid -- Unik nøgle i systemet
docorOrganisation -- Ydernummer for organisation
hospitalOrganisation -- SKS kode for sygehus/afdeling
ean -- EAN nummer for organisation
patientCpr -- Patientens CPR-nummer
healthProfessionalCpr -- Behandlers CPR-nummer
relationLookupStart -- Starttidspunkt for relation til patient
relationLookupEnd -- Sluttidspunkt for relation til patient
timeLimit -- Tidsfrist for opnåelse af relation inden alarm genereres
acceptableRelations -- Acceptable evidensniveauer, kommasepareret
followupRelations -- Evidensniveauer, der giver anledning til opfølgning
authorisationIdentifier -- Autorisations-id
serviceProviderName -- Navn på kaldende system
serviceProviderVersion -- Version på kaldende version
serviceProviderVendor -- Leverandør for kaldende version
created -- Tidspunkt for oprettelse af record
errorCount -- Antal gange record er forsøgt replikeret til backend
nextSync -- Tidspunkt for næste forsøg på replikering

BRS Opfølgning behandling

^^Tilbage til toppen^^

Opfølgningstabel i Backend

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 ("BRS Notifikation").


Objektet indeholder informationen:
--------------------------------------
serialNumber -- Primær nøgle
nextCheck -- Tidspunkt for næste opfølgning
queryableCvr -- CVR-nummer
externalReferenceId -- Id i kaldende system
uid -- Unik nøgle i systemet
docorOrganisation -- Ydernummer for organisation
hospitalOrganisation -- SKS kode for sygehus/afdeling
ean -- EAN nummer for organisation
patientCpr -- Patientens CPR-nummer
healthProfessionalCpr -- Behandlers CPR-nummer
relationLookupStart -- Starttidspunkt for relation til patient
relationLookupEnd -- Sluttidspunkt for relation til patient
timeLimit -- Tidsfrist for opnåelse af relation inden alarm genereres
acceptableRelations -- Acceptable evidensniveauer, kommasepareret
followupRelations -- Evidensniveauer, der giver anledning til opfølgning
authorisationIdentifier -- Autorisations-id
serviceProviderName -- Navn på kaldende system
serviceProviderVersion -- Version på kaldende version
serviceProviderVendor -- Leverandør for kaldende version
created -- Tidspunkt for oprettelse af record

BRS Notifikation (replikeres til dNSP/cNSP)

^^Tilbage til toppen^^

Notifikationstabellen i Backend-miljøet indeholder alarm-notifikationer for behandlingsrelationer, som der ikke kunne findes evidens for indenfor tidsfristen
Replikeres til NSP miljøerne
Det eksterne referenceid svarer til den id der blev modtaget i den oprindelige opsamlingsforespørgsel. CVR-nummeret bestemmer hvem der har adgang til notifikationen. Den unikke nøgle svarer til den unikke nøgle på opsamlingsforespørgselstabellen ("BRS Opfølgning behandling").

Objektet indeholder informationen:
---------------------------------------
serialNumber -- Primær nøgle
externalReferenceId -- Id i kaldende system
queryableCvr -- CVR-nummer
creationTimestamp -- Tidspunkt for oprettelse af record
docorOrganisation -- Ydernummer for organisation
hospitalOrganisation -- SKS kode for sygehus/afdeling
ean -- EAN nummer for organisation
patientCpr -- Patientens CPR-nummer
healthProfessionalCpr -- Behandlers CPR-nummer
relationLookupStart -- Starttidspunkt for relation til patient
relationLookupEnd -- Sluttidspunkt for relation til patient
timeLimit -- Tidsfrist for opnåelse af relation inden alarm genereres
acceptableRelations -- Acceptable evidensniveauer, kommasepareret
actualRelations -- Bedste relation opnået under opfølgning
followupRelations -- Evidensniveauer, der giver anledning til opfølgning
authorisationIdentifier -- Autorisations-id
serviceProviderName -- Navn på kaldende system
serviceProviderVersion -- Version på kaldende version
serviceProviderVendor -- Leverandør for kaldende version
uid -- Unik nøgle i systemet

Whitelist config (BRS)

^^Tilbage til toppen^^

Objektet indeholder de CVR som er whitelisted til brug på test/prod for BRS servicen

Objektet indeholder informationen:
---------------------------------------
service_key
-- BRS behandlingsrelationsservice:
+ dk.nsi.auth.query.type.cvr.list - BRS
+ dk.nsi.auth.create.type.cvr.list - BRS
+ dk.nsi.auth.brs.cvr.list - NO_TYPE
-- Min Log:
+ dk.nsi.minlog.registration (registration service)
+ minlogws (opslags service)

service_type
-- NO_TYPE
-- BRS
-- CPRSUBSCRIPTION
cvr -- CVR nummer
comment -- Her anføres NSP Jira nummer som relaterer den enkelte whitelisting

Tabelbeskrivelser

Tabel: BRS2_Followup

^^Tilbage til toppen^^

Database "follow-up" (dNSP/cNSP)

CREATE TABLE BRS2_Followup (
pk bigint NOT NULL, -- Auto increment is set in alter table (due to hsqldb and mysql syntax)

queryableCvr char(8) NOT NULL, -- cvr nummer der kan hente alarmer paa baggrund af denne followup
externalReferenceId varchar(50) NOT NULL,
uid varchar(36) NOT NULL,

doctorOrganisation varchar(7) NULL,
hospitalOrganisation varchar(7) NULL,
ean varchar(20) NULL,
patientCpr char(10) NOT NULL,
healthProfessionalCpr char(10) NOT NULL,
relationLookupStart DATETIME NOT NULL,
relationLookupEnd DATETIME NOT NULL,
timeLimit DATETIME NOT NULL,
acceptableRelations varchar(20) NOT NULL, -- separated by comma

followupRelations varchar(20),
authorisationIdentifier varchar(20) NOT NULL,
serviceProviderName varchar(50) NOT NULL,
serviceProviderVersion varchar(30) NOT NULL,
serviceProviderVendor varchar(50) NOT NULL,

created DATETIME NOT NULL,
errorCount INTEGER NULL,
nextSync DATETIME NULL,

PRIMARY KEY (pk)
);

ALTER TABLE BRS2_Followup MODIFY COLUMN pk bigint NOT NULL auto_increment;
CREATE UNIQUE INDEX uidIndex on BRS2_Followup(uid);

Tabel: BRS2_TreatmentRelationFollowup

^^Tilbage til toppen^^

Database "follow-up" (Backend)

CREATE TABLE BRS2_TreatmentRelationFollowup (
serialNumber bigint NOT NULL, -- Auto increment is set in alter table (due to hsqldb and mysql syntax)
nextCheck datetime NOT NULL,

queryableCvr char(8) NOT NULL, -- cvr nummer der kan hente alarmer paa baggrund af denne followup
externalReferenceId varchar(50) NOT NULL,
uid varchar(36) NOT NULL,

doctorOrganisation varchar(7) NULL,
hospitalOrganisation varchar(7) NULL,
ean varchar(20) NULL,
patientCpr char(10) NOT NULL,
healthProfessionalCpr char(10) NOT NULL,
relationLookupStart DATETIME NOT NULL,
relationLookupEnd DATETIME NOT NULL,
timeLimit DATETIME NOT NULL,
acceptableRelations varchar(20) NOT NULL, -- separated by comma

followupRelations varchar(20),
authorisationIdentifier varchar(20) NOT NULL,
serviceProviderName varchar(50) NOT NULL,
serviceProviderVersion varchar(30) NOT NULL,
serviceProviderVendor varchar(50) NOT NULL,

created DATETIME NOT NULL,

PRIMARY KEY (serialNumber)
);

ALTER TABLE BRS2_TreatmentRelationFollowup MODIFY COLUMN serialNumber bigint NOT NULL auto_increment;

CREATE INDEX NextCheckIndex on BRS2_TreatmentRelationFollowup(nextCheck);
CREATE INDEX uidIndex on BRS2_TreatmentRelationFollowup(uid);

Tabel: BRS2_Notification

^^Tilbage til toppen^^

Database: "register_notifications" (Til brug for BRS servicen: BRS2_Notification, LPT, SSR og refhost; replikeret mellem Backend og NSP-miljøer)

CREATE TABLE BRS2_Notification (
serialNumber bigint NOT NULL,

externalReferenceId varchar(50) NOT NULL,
queryableCvr char(8) NOT NULL,
creationTimestamp datetime NOT NULL,

doctorOrganisation varchar(7) NULL,
hospitalOrganisation varchar(7) NULL,
ean varchar(20) NULL,
patientCpr char(10) NOT NULL,
healthProfessionalCpr char(10) NOT NULL,
relationLookupStart DATETIME NOT NULL,
relationLookupEnd DATETIME NOT NULL,
timeLimit DATETIME NOT NULL,
acceptableRelations varchar(20) NOT NULL, -- separated by comma
actualRelations varchar(20) NOT NULL, -- separated by comma
followupSerialNumber bigint NOT NULL,

followupRelations varchar(20),
authorisationIdentifier varchar(20) NOT NULL,
serviceProviderName varchar(50) NOT NULL,
serviceProviderVersion varchar(30) NOT NULL,
serviceProviderVendor varchar(50) NOT NULL,

uid varchar(36) NOT NULL,

PRIMARY KEY (serialNumber)
);

Tabel: whitelist_config (BRS)

^^Tilbage til toppen^^

CREATE TABLE whitelist_config (
service_key VARCHAR(50) NOT NULL,
service_type VARCHAR(20) NOT NULL,
cvr CHAR(8) NOT NULL,
comment VARCHAR(100) NULL,
PRIMARY KEY (service_key, service_type, cvr)
); -- ENGINE=InnoDB COLLATE=utf8_bin;

Teknologibeskrivelse

^^Tilbage til toppen^^

Refereres fra

^^Tilbage til toppen^^





  • No labels