Formål

Dette dokument beskriver arkitekturen for Behandlignsrelationsservicen (BRS).
Der beskrives

Arkitekturoverblik

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.
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). 
 
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 og kalder alle underliggende RelationRelayers.

Blueprint for opbygningen af RelationRelayer service ser således ud.

Logisk arkitektur

Webservices

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


Behandlingsrelationservice (BRS):
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.


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. Schedule for jobs kan konfigureres vha. en cron expression.


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 via GOS.


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.

Fælles valideringsbibliotek

Valideringsbiblioteker har adgang til data fra en række databaser, deriblandt landspatientregisteret og sygesikringsregisteret, for at kunne udlede om en behandlingsrelation er til stede. Valideringsbiblioteket tilgås af behandlingsrelationservicen i dNSP/cNSP-miljøerne samt relationsopfølgningsjobbet i Backoffice miljøet.
Valideringsbiblioteket er implementeret som en fælles kodebase, der deles af front- og backend modulerne.

Flowchart

Nedenfor er der et flowchart, for det overordnede flow i systemet.

Fysisk datamodel

Der er to typer databaser i datamodellen:

Tabellerne på de to typer databaser er beskrevet i det følgende.

Datamodel for opfølgningsdatabaserne (followup)

Opfølgningstabel på dNSP og cNSP (brs2_followup)

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.

Navn

Type

Beskrivelse

Pk

bigint, auto_increment

Primær nøgle

queryableCvr

char(8)

CVR-nummer

externalReferenceId

varchar(50)

Id i kaldende system

Uid

varchar(36)

Unik nøgle i systemet

docorOrganisation

varchar(7)

Ydernummer for organisation

hospitalOrganisation

varchar(7)

SKS kode for sygehus/afdeling

ean

varchar(20)

EAN nummer for organisation

sorbigintSOR nummer for organisation

patientCpr

char(10)

Patientens CPR-nummer

healthProfessionalCpr

char(10)

Behandlers CPR-nummer

relationLookupStart

datetime

Starttidspunkt for relation til patient

relationLookupEnd

datetime

Sluttidspunkt for relation til patient

timeLimit

datetime

Tidsfrist for opnåelse af relation inden alarm genereres

acceptableRelations

varchar(20)

Acceptable evidensniveauer, kommasepareret

followupRelations

varchar(20)

Evidensniveauer, der giver anledning til opfølgning

authorisationIdentifier

varchar(20)

Autorisations-id

serviceProviderName

varchar(50)

Navn på kaldende system

serviceProviderVersion

varchar(20)

Version på kaldende version

serviceProviderVendor

varchar(50)

Leverandør for kaldende version

created

datetime

Tidspunkt for oprettelse af record

errorCount

int

Antal gange record er forsøgt replikeret til backend

nextSync

datetime

Tidspunkt for næste forsøg på replikering


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.

Opfølgningstabel i Backoffice (brs2_treatmentrelationfollowup)

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.

Navn

Type

Beskrivelse

serialNumber

bigint, auto_increment

Primær nøgle

nextCheck

datetime

Tidspunkt for næste opfølgning

queryableCvr

char(8)

CVR-nummer

externalReferenceId

varchar(50)

Id i kaldende system

uid

varchar(36)

Unik nøgle i systemet

docorOrganisation

varchar(7)

Ydernummer for organisation

hospitalOrganisation

varchar(7)

SKS kode for sygehus/afdeling

ean

varchar(20)

EAN nummer for organisation

sorbigintSOR nummer for organisation

patientCpr

char(10)

Patientens CPR-nummer

healthProfessionalCpr

char(10)

Behandlers CPR-nummer

relationLookupStart

datetime

Starttidspunkt for relation til patient

relationLookupEnd

datetime

Sluttidspunkt for relation til patient

timeLimit

datetime

Tidsfrist for opnåelse af relation inden alarm genereres

acceptableRelations

varchar(20)

Acceptable evidensniveauer, kommasepareret

followupRelations

varchar(20)

Evidensniveauer, der giver anledning til opfølgning

authorisationIdentifier

varchar(20)

Autorisations-id

serviceProviderName

varchar(50)

Navn på kaldende system

serviceProviderVersion

varchar(20)

Version på kaldende version

serviceProviderVendor

varchar(50)

Leverandør for kaldende version

created

datetime

Tidspunkt for oprettelse af record


Tidspunktet i nextCheck benyttes af opfølgningsjobbet til at vurdere om en opfølgning skal behandles på kørselstidspunktet.

Notifikationstabel (brs2_notification)

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

Navn

Type

Beskrivelse

serialNumber

bigint, auto_increment

Primær nøgle

externalReferenceId

varchar(50)

Id i kaldende system

queryableCvr

char(8)

CVR-nummer

creationTimestamp

datetime

Tidspunkt for oprettelse af record

docorOrganisation

varchar(7)

Ydernummer for organisation

hospitalOrganisation

varchar(7)

SKS kode for sygehus/afdeling

ean

varchar(20)

EAN nummer for organisation

sorbigintSOR nummer for organisation

patientCpr

char(10)

Patientens CPR-nummer

healthProfessionalCpr

char(10)

Behandlers CPR-nummer

relationLookupStart

datetime

Starttidspunkt for relation til patient

relationLookupEnd

datetime

Sluttidspunkt for relation til patient

timeLimit

datetime

Tidsfrist for opnåelse af relation inden alarm genereres

acceptableRelations

varchar(20)

Acceptable evidensniveauer, kommasepareret

actualRelations

varchar(20)

Bedste relation opnået under opfølgning

followupRelations

varchar(20)

Evidensniveauer, der giver anledning til opfølgning

authorisationIdentifier

varchar(20)

Autorisations-id

serviceProviderName

varchar(50)

Navn på kaldende system

serviceProviderVersion

varchar(20)

Version på kaldende version

serviceProviderVendor

varchar(50)

Leverandør for kaldende version

uid

varchar(36)

Unik nøgle i systemet


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 på NSP.

Datamodel for data hentet fra Stamdata

Behandlingsrelationsservicen benytter data udstillet af Stamdatamodulet. Det drejer sig om tabellen AssignedDoctor der dækker registret "Sikrede". Dokumentationen af denne tabel forefindes i dokumentationen for Stamdata.

Datamodel for register- og notifikationsdatabasen (register_notifications)


Valideringsregler for behandlingsrelationer

I  de følgende afsnit gennemgås algoritmerne/valideringsreglerne for de enkelte kildedataregistre.

Landspatientregister (LPR)

Flowdiagram over LPR evidenstjek.


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:

Navn

Type

Beskrivelse

pk

bigint, auto_increment

Primære nøgle

patientCpr

varchar(80)

SHA-1 hash

admittedStart

datetime


admittedEnd

datetime


lprReference

varchar(40)

Fra inputdata – audit

relationType

varchar(40)

Se kommentarer

organisationIdentifier

varchar(7)

ydernummer eller SKS-kode


Relationstypen kan antage værdierne "REFERRING_UNIT", "TREATMENT_UNIT" eller "DISCHARGED_TO_OWN_DOCTOR" svarende til om der er tale om en henvisende afdeling, en behandlingsafdeling eller om patienten er udskrevet til egen læge. Hvis patienten er udskrevet til egen læge skal feltet organisationIdentifier indeholde et ydernummer, ellers skal det indeholde et sks.

Landspatientregister (LPR3)

LPR3 er begyndt at benytte SORLS servicen til at mappe fra Shak koder til Sor identifkation.

LPR3 evindenstjek foretages udfra følgende algoritme:

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.

De væsentligste ændringer fra forrige version af LPR3 i BRS er:


Data fra LPR3 findes i en tabel med dette skema:

Navn

Type

Beskrivelse

pk

bigint, auto_increment

Primære nøgle

patientCpr

varchar(80)

SHA-1 hash

admittedStart

datetime


admittedEnd

datetime


lprReference

varchar(256)

Fra inputdata – audit

relationType

varchar(40)

Se kommentarer

sorKode

bigint(20)

SOR-kode

Relationstypen kan antage følgende værdier:

Sygesikringsregister (SSR)

SSR evindenstjek foretages udfra følgende algoritme:

Data fra SSR findes i en tabel med dette skema:

Navn

Type

Beskrivelse

pk

bigint, auto_increment

Primære nøgle

patientCpr

varchar(80)

SHA-1 hash

doctorOrganisationIdentifier

varchar(6)

ydernummer

admittedStart

datetime


admittedEnd

datetime


externalReference

varchar(40)

Fra inputdata - audit

SSR benytter SORLS servicen til at mappe fra SOR koder til ydernumre.

Se bl.a. SORLS - Guide til anvendere

Henvisningshotellet (Refhost)

Refhost evindenstjek foretages udfra følgende algoritme:

Data fra Refhost findes i en tabel med dette skema:

Navn

Type

Beskrivelse

pk

bigint, auto_increment

Primære nøgle

healthProfessionCpr

varchar(80)

SHA-1 hash

doctorOrganisationIdentifier

varchar(6)

ydernummer

hospitalOrganisationIdentifier

varchar(7)

SKS-kode

EAN

char(13)

EAN-nummer

patientCpr

varchar(80)

SHA-1 hash

referralStart

datetime

Henvisningens start

referralEnd

datetime


refhostReference

varchar

Fra inputdata – audit


Benytter SORLS servicen til at mappe fra sorkoder til ydernumre og Shak koder.

Se bl.a. SORLS - Guide til anvendere

Sikrede (AssignedDoctor)

Sikrede evindenstjek foretages udfra følgende algoritme:


Teknologiarkitektur

Der henvises til NSP-dokumentationen for information vedrørende den overordnede arkitektur og omkringliggende komponenter.
Komponenter og services beskrevet her følger de overordnede retningslinier og krav udstukket af NSP-operatøren, herunder:


Ændringslog


Version

Dato

Ændring

Ansvarlig

0.1

2011-06-15

Initielt dokument

Trifork

0.2

2011-07-27

Ændringer jf. databaseskema indeholdende generelle notifikationer

Trifork

0.3

2011-08-10

Opsplitning af dokumentation jf. BRS og GOS opsplitning

Trifork

0.4

2011-10-05

Tilføjelse af information om eksternt "Sikrede" register fra Stamdata

Trifork

0.5

2013-10-21

Opdateret SVN link

Trifork

0.6

2017-03-10

Tilpasset til BRS2

Trifork

0.7

2017-03-14

Rettet betegnelser på NSP-miljøer

Trifork

0.82019-07-12Tilføjet mulighed for registrering med SOR kodeKvalitetsIT
0.92019-11-11Opdateret afsnit omkring LPR3KvalitetsIT
0.102020-09-30Siden er opdateret med flere oversigtsdiagrammer over relays og opslag.
Desuden ændring  til  beskrivelse af de forskellige relays og opslag.
KvalitetIT