Page History
...
Anchor | ||||
---|---|---|---|---|
|
Version 0.9, 2019-11-11
...
Table of Contents | ||||
---|---|---|---|---|
|
Formål
Dette dokument beskriver arkitekturen for Behandlignsrelationsservicen (BRS), herunder beslutningsflowet (algoritmer) i BRS, for de forskellige evidenskilder (konkrete registre).Der beskrives
- Moduler i BRS
- Services og jobs, der rummes af BRS
- NSP miljøer, hvorpå i BRS modulerne er installeret
- Dataflow
- Datamodul, herunder databaser og tabelstruktur.
Arkitekturoverblik
Table of Contents |
---|
Arkitekturoverblik
Behandlingsrelationsservicen (BRS) udstillet på NSP 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".
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).
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:
- Landspatientregistret (LPR)
- Sygesikringsregistret (SSR)
- Henvisningshotellet (Refhost)
- Sikrede (AssignedDoctor)
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.
Logisk arkitektur
Webservices
På NSP-miljøerne udstilles følgende webservices:
...
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.
HTML |
---|
<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).
Logisk arkitektur
Systemet er opdelt i to dele "frontend" og "backend":
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
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.
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 (se driftsvejledning for detaljer).
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.
Jobbet afvikles med et fast interval, som
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:
- En opfølgningsdatabase
- En database med registre og notifikationer
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.
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.
Software Blueprint
Nedenstående blueprint viser lagdelingen i BRS. For yderlige detaljer henvises der til de enkelte services.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
BRS-Frontend
Frontend'en indeholder behandlingsrelationsservicen og notifikationsservicen, som er de webservices, der kaldes udefra, fra eksempelvis FMK.
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
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Notifikation
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
BRS-Backend
Backend'en indeholder en servlet, som ved afvikling henter at batch af beskeder fra Kafka. Hver kafka-besked indeholder netop én bestilt opfølgning. Det tjekkes, om der er opnået evidens for de behandlingsrelationer, der er sat til opfølgning, og der oprettes alarm-notifikationer i de tilfælde, hvor evidens ikke blev opnået indenfor tidsfristen. Desuden afvikles et andet batchjob, 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:
- Landspatientregistret (LPR)
- Sygesikringsregistret (SSR)
- Henvisningshotellet (Refhost)
- Sikrede (AssignedDoctor)
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
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
RelationRelayer
FollowupConsumer kalder RelationRelayerInterface, som bruger og kalder alle underliggende RelationRelayers.
Blueprint for opbygningen af RelationRelayer service ser således ud.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Fysisk datamodel
Der er to typer databaser i datamodellen:
- En opfølgningsdatabase
- En database med registre og notifikationer
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-14616003-c1ad-40ab-822a-146eb00293a1.html" name="test" height="510" width="600">You need a Frames Capable browser to view this content.</iframe> |
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 |
sor | bigint | SOR 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.
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.
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 |
sor | bigint | SOR 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 | ||
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 |
sor | bigint | SOR 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 |
creatednextSync | datetime | Tidspunkt for næste forsøg på replikering |
...
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
...
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
...
Datamodel for register- og notifikationsdatabasen (register_notifications)
Landspatientregister (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
...
oprettelse af record |
Tidspunktet i nextCheck benyttes af opfølgningsjobbet til at vurdere om en opfølgning skal behandles på kørselstidspunktet.
Datamodel for register- og notifikationsdatabasen (register_notifications)
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 |
sor | bigint | SOR 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.
Whitelist config (BRS) 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
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.
Valideringsregler for behandlingsrelationer
I de følgende afsnit gennemgås algoritmerne/valideringsreglerne for de enkelte kildedataregistre.
Landspatientregister (LPR)
Flowdiagram over LPR evidenstjek.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
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 SORES servicen til at mappe fra Shak koder til Sor identifkation.
LPR3 evindenstjek foretages udfra følgende algoritme:
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
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.
Betegnelserne SHAK(sundhedsprofessionel) og SOR(sundhedsprof) skal forståes som to af de parametre BRS'en er blevet kaldt med. I BRS Avenderguide betegnes SHAK og SOR som OrganisationIdentifier. Sundhedsprofessionel betegnes HealthProfessionalCpr.
De væsentligste ændringer fra forrige version af LPR3 i BRS er:
- Mapning fra Shak til Sor foregår nu vha. Sores servicen, hvor den før blev indsamlet fra databasen.
- Sor koderne for alle underafdelinger til de afdelinger (Sor koder) der blev fundet ved mapning fra Shak til Sor hentes vha. Sores Servicen.
- Både Sor koder fra afdeling og underafdelinger bruges i evidenstjek.
- Sor kode det sygehus en afdeling hører til bruges.
- Hvis der ikke opnåes god nok klassifikation efter tjek af LP3 data (Se nedenfor) og Sor koder for afdeling og underafdelinger, så tjekkes Sor koder for sygehuse.
- LPR3 data bruges til at hente sygehus koder fra Sores servicen.
- Der tjekkes på sygehus koder fra afdeling og LPR3 data.
Data fra LPR3 findes i en tabel med dette skema:
Landspatientregister (LPR3)
LPR3 er begyndt at benytte SORLS servicen til at mappe fra Shak koder til Sor identifkation.
Se bl.a. SORLS - Guide til anvendere
De ændringen der er til LPR3 evindens tjek ender ud med et flow således ud:
...
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:
- Mapning fra Shak til Sor foregår nu vha. Sorls servicen, hvor den før blev indsamlet fra databasen.
- Sor koderne for alle underafdelinger til de afdelinger (Sor koder) der blev fundet ved mapning fra Shak til Sor hentes vha. Sorls Servicen.
- Både Sor koder fra afdeling og underafdelinger bruges i evidenstjek.
- Sor kode det sygehus en afdeling hører til bruges.
- Hvis der ikke opnåes god nok klassifikation efter tjek af LP3 data (Se nedenfor) og Sor koder for afdeling og underafdelinger, så tjekkes Sor koder for sygehuse.
- LPR3 data bruges til at hente sygehus koder fra Sorls servicen. (I skrivende stund er der problemer med denne funktion, så sygehuskoden kan ikke hentes.)
- Der tjekkes på sygehus koder fra afdeling og LPR3 data.
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:
- FORLOEBSELEMENT
- KONTAKT
- PROCEDURE
- INITIEL_HENVISNING
- HENVISNING
- RESULTATINDBERETNING
- OPHOLDSADRESSE
Sygesikringsregister (SSR)
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 | ||||
externalReferencelprReference | varchar(40256) | Fra inputdata - audit |
Henvisningshotellet (Refhost)
– audit | ||
relationType | ||
Navn | Type | Beskrivelse |
---|---|---|
pk | bigint, auto_increment | Primære nøgle |
healthProfessionCpr | varchar(80) | SHA-1 hash |
doctorOrganisationIdentifier | varchar(640) | ydernummerSe kommentarer |
hospitalOrganisationIdentifiersorKode | varcharbigint(720) | SKSSOR-kode |
EAN | char(13) | EAN-nummer |
patientCpr | varchar(80) | SHA-1 hash |
referralStart | datetime | Henvisningens start | referralEnd | datetime |
refhostReference | varchar | Fra inputdata – audit |
Notifikationstabel (brs2_notification)
Relationstypen kan antage følgende værdier:
- FORLOEBSELEMENT
- KONTAKT
- PROCEDURE
- INITIEL_HENVISNING
- HENVISNING
- RESULTATINDBERETNING
- OPHOLDSADRESSE
Sygesikringsregister (SSR)
SSR evindenstjek foretages udfra følgende algoritme:
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Data fra SSR findes i en tabel med dette skema:Notifikationstabellen i Backoffice-miljøet indeholder alarm-notifikationer for behandlingsrelationer, som der ikke kunne findes evidens for indenfor tidsfristen.
Navn | Type | Beskrivelse |
---|---|---|
serialNumberpk | bigint, auto_increment | Primær Primære nøgle |
externalReferenceIdpatientCpr | varchar(5080) | 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 |
sor | bigint | SOR 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 |
...
SHA-1 hash | ||
doctorOrganisationIdentifier | varchar(6) | ydernummer |
admittedStart | datetime | |
admittedEnd | datetime | |
externalReference | varchar(40) | Fra inputdata - audit |
SSR benytter SORES servicen til at mappe fra SOR koder til ydernumre.
Se bl.a. SORES - Guide til anvendere
Henvisninger
Henvisningers evindenstjek foretages udfra følgende algoritme:
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Data fra stammer fra Henvisningshotellets tabel 'Refhost' 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 |
therapistSorCode | bigint | SOR-kode for behandler |
referrerSorCode | bigint | SOR-kode for henviser |
Benytter SORES servicen til at mappe fra sorkoder til ydernumre og Shak koder.
Se bl.a. SORES - Guide til anvendere
Henvisninger (SOR)
Henvisninger (SOR) evindenstjek foretages udfra følgende algoritme:
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Sikrede (AssignedDoctor)
Sikrede evindenstjek foretages udfra følgende algoritme:
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Kafka beskedformat
Der anvendes Kafka til overførsel af opfølgningsbestillinger fra frontend til backend. Beskederne indeholder følgende attributter:
Navn | Type | Beskrivelse |
---|---|---|
followup | FollowupType | Selve bestillingen. For flere detaljer om indholdet henvises til servicens wsdl-filer. |
nextCheck | Datetime | Hvornår bestillingen næste gang skal forsøges udført. |
lastProcessingTime | DateTime | Hvornår beskeden sidst har været behandlet. Bemærk at 'behandlet' blot betyder at BRS har haft fat i beskeden, men at nextCheck godt kan ligge i fremtiden, hvorfor beskeden blot lægges tilbage i køen. Attributten bruges til at tjekke, om det er de samme beskeder der behandles flere gange efter hinanden. |
Behandling af opfølgningsbestillinger foregår ved at frontend'en lægger beskeder i kø i Kafka, og backend'en tager dem af og behandler dem. Det er muligt at udsætte behandling til senere ved brug af nextCheck-tidsstemplet. Hvis backend'en forsøger at behandle en bestilling, der først skal behandles i fremtiden, lægges bestillingen blot tilbage i køen.
Teknologiarkitektur
Komponenter og services beskrevet her følger de overordnede retningslinier og krav udstukket af NSP-operatøren, herunder:
- Alle services skal bruge MySQL databaser til persistering af data.
- Alle services skal kunne eksekveres på JBoss. Aktuelt anvendes Wildfly 8.2.
- Al tilgang til services udefra skal foregå ved brug af den gode webservice (DGWS) (STS-signerede IDkort, niveau 3).
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.
Valideringsregler for behandlingsrelationer
I dokumentet "Behandlingsrelationsregler" findes en liste af valideringsregler for de enkelte kildedataregistre. Der henvises til dette dokument for yderligere detaljer.
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:
- Alle services skal bruge MySQL databaser til persistering af data.
- Alle services skal kunne eksekveres på JBoss. Aktuelt anvendes Wildfly 8.2.
- Al tilgang til services udefra skal foregå ved brug af den gode webservice (DGWS) (STS-signerede IDkort, niveau 3).
- Internt anvendes usignerede DGWS niveau 1 ID-kort til kommunikation mellem frontend og backend.
Æ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
...