Page History
...
Dette dokument beskriver arkitekturen for Behandlignsrelationsservicen (BRS).
Der beskrives
...
, herunder beslutningsflowet (algoritmer) i BRS, for de forskellige evidenskilder (konkrete registre).
| Table of Contents |
|---|
Arkitekturoverblik
...
| HTML |
|---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-39ae766a-05e8-4933-bc54-9aea0ff8451e.html" name="test" height="1020810" width="1000800">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 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.
...
| HTML |
|---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-14616003-c1ad-40ab-822a-146eb00293a1.html" name="test" height="500510" width="800600">You need a Frames Capable browser to view this content.</iframe> |
...
Tabellerne på de to typer databaser er beskrevet i det følgende. Det skal bemærkes at followup-databasen skal udgå, da BSR er lagt om til at overføre opfølgningsbestiliinger via Kafka. Når indholdet af BRS2_TreatmentRelationFollowup-tabellen er migreret til Kafka, kan afsnit 5.1 nedenfor slettes. Der henvises til driftsvejledningen for yderlygere detaljer om denne migrering.
Datamodel for opfølgningsdatabaserne (followup)
Opfølgningstabel på dNSP og cNSP (brs2_followup)
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ø. 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.
...
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 | 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 | 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 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)
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
...
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
, 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.
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 StamdataDet 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.
Valideringsregler for behandlingsrelationer
...
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. (I skrivende stund er der problemer med denne funktion, så sygehuskoden kan ikke hentes.)
- Der tjekkes på sygehus koder fra afdeling og LPR3 data.
...