Page History
| Anchor | ||||
|---|---|---|---|---|
|
Design og Arkitektur
Version 0.7, 2017-03-14
Indhold
1 Formål
2 Arkitekturoverblik
2.1 BRS-Frontend
2.2 BRS-Backend
3 Logisk arkitektur
3.1 Webservices
3.2 Batchjobs i Backoffice
3.3 Fælles valideringsbibliotek
4 Flowchart
5 Fysisk datamodel
5.1 Datamodel for opfølgningsdatabaserne (followup)
5.1.1 Opfølgningstabel på dNSP og cNSP (brs2_followup)
5.1.2 Opfølgningstabel i Backoffice (brs2_treatmentrelationfollowup)
5.2 Datamodel for register- og notifikationsdatabasen (register_notifications)
5.2.1 Landspatientregister (LPR)
5.2.2 Sygesikringsregister (SSR)
5.2.3 Henvisningshotellet (Refhost)
5.2.4 Notifikationstabel (brs2_notification)
5.3 Datamodel for data hentet fra Stamdata
6 Valideringsregler for behandlingsrelationer
7 Teknologiarkitektur
8 Ændringslog
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Nedenfor er der et flowchart, for det overordnede flow i systemet.
ServiceudbyderdNSP/cNSPBackofficeRelationsforespørgselSvar m. opfølgningsstatusokOverfør opfølgningerSlet lokaltPeriodiskServiceudbyderdNSP/cNSPBackofficePeriodiskTjek valideringsbibliotek, slet opfølgninger, overfør til notifikationerPeriodiskDatabase replikering (notifikationer og kildedata)ServiceudbyderdNSP/cNSPBackofficeNotifikationsforespørgSvar m. notifikationerSlet gamle notifikationerPeriodisk
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
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 |
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.
| Anchor | ||||
|---|---|---|---|---|
|
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 |
Tidspunktet i nextCheck benyttes af opfølgningsjobbet til at vurdere om en opfølgning skal behandles på kørselstidspunktet.
...
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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 |
| Anchor | ||||
|---|---|---|---|---|
|
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 |
| Anchor | ||||
|---|---|---|---|---|
|
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 |
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Kilden til dette dokument kan findes på:
https://svn.nspop.dk/svn/trifork/brs/trunk/doc/
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 |
| Anchor | ||||
|---|---|---|---|---|
|