Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchor
top
top


INDHOLD

Table of Contents

Beskrivelse

Multiexcerpt
MultiExcerptNameFormål

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

...

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^^


Multiexcerpt
MultiExcerptNameArkitekturtegning

Image RemovedImage Added


Relaterede registre og services

Multiexcerpt
MultiExcerptNameUnderstøttede komponenter

Applikationsbeskrivelse

^^Tilbage til toppen^^

Image RemovedImage Added

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.

...

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.

...

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

Image RemovedImage Added

Entitetsbeskrivelser

BRS Opfølgning (kø)

^^Tilbage til toppen^^

Opfølgningstabel på dNSP og cNSP

...

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

...


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

...

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)

...

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

...

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^^

Incoming Links