Page History
...
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)
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 L
...
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
...
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.
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.
| 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
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:
| 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.
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(25640) | Fra inputdata – audit |
relationType | varchar(40) | Se kommentarer |
sorKodeorganisationIdentifier | bigintvarchar(207) | SORydernummer eller SKS-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
...
externalReference
...
varchar(40)
...
Fra inputdata - audit
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.
Se bl.a. SORLS - Guide til anvendere
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.
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 |
Benytter SORLS servicen til at mappe fra sorkoder til ydernumre.
Se bl.a. SORLS - Guide til anvendere
Henvisningshotellet (Refhost)
...
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 | |
referralStartadmittedStart | datetime | ||
Henvisningens startadmittedEnd | referralEnd | datetime | |
refhostReferencelprReference | varchar(256) | 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)
...
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
...
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)
SSR evindenstjek foretages udfra følgende algoritme:
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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:
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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:
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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:
...