Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Comment: flyttet behandlingsrelationsreglerne fra yderligere dokumentation til leverancedokumentet

...

Den sikkerhedsmæssige opfølgningsservice giver en systemteknisk mulighed for automatisk at følge op på, om de formelle regler og relevanskriterier for adgang til sundhedsdata rent faktisk er opfyldt.
Opfølgningsservicen udstiller et ensartet workflow til at oprette, lagre og afvikle sikkerhedsmæssig hændelser ved brug af nationale services.
Servicen tilbyder en høj grad af automatisering af ovenstående workflow til erstatning for en omfangsrig, bagudrettet, manuel opfølgning.

Behandlingsrelationsregler

BRS klassificerer behandlingsrelationer på en ordnet skala, arrangeret efter ”styrken” af behandlingsrelationsevidens, hvor ”A+” pt. er den kategori, der beskriver relationer med stærkest evidens for en aktuel behandlingsrelation.

Skalaen for klassifikationerne er:

Kategori	Navn	Beskrivelse	Anbefalet tolkning
A+	Direkte behandlingsrelation	Eksplicit relation (f.eks. henvisning) mellem navngiven behandler og navngiven patient på et kendt tidspunkt.	Behandlingsrelationer i denne kategori er for tiden de bedst dokumenterede, og det anbefales, derfor at betragte kategorien A+ relationer som værende verificerede og kræver ikke yderligere tiltag.
A	Samme tid, samme behandlingssted	Patient og Behandler var på samme behandlingssted på samme tid.	Det anbefales at betragte kategori A relationer som værende verificerede og kræver ikke yderligere tiltag.
B+	Samme behandlingssted	Patient og Behandler var på samme behandlingssted (f.eks. sygehus)	Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre.
B	Generel behandlingsrelation	Generel behandlingsrelation, f.eks. at læge er patientens ”egen læge”.	Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre.
C	Historisk betinget behandlingsrelation	Historisk betinget behandlingsrelation. Patient og behandler har været i kontakt tidligere.	Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre.
D	Kan ikke afklares pt.	Ingen evidens for nuværende.	Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre.
E	Kan ikke afklares	Ingen evidens hverken nu eller senere.	Behandlingsrelationer i denne kategori er ikke verificerede, og kan heller ikke blive det senere.

Registre (Evidenskilder)

Sygesikringsregistret (også kendt som "ydelsesregistret"):

Match på ydernummer, patient cpr og dato (interval bestående af start- og slutdato): Kategori A
Match på ydernummer, patient cpr, men ikke dato: Kategori C
Ingen af ovenstående, og testet interval er max 62 dage (konfigurerbart) siden: Kategori D
Ingen af ovenstående: Kategori E
Forespørgsler, hvor ydernummer ikke indgår: Kategori E

Sikrede/Egen læge/Sygesikringsregistret:

Match på ydernummer, patient cpr og dato: Kategori B
Match på ydernummer og patient cpr, men ikke dato: Kategori C
Ingen af ovenstående, og testintervallet er max 10 dage siden: Kategori D
Ingen af ovenstående: Kategori E
Forespørgsler, hvor ydernummer ikke indgår: Kategori E

Henvisningshotellet (REFHOST):

Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. REFHOST-kilden benytter SHAK som nøgle.

Match på "STED", patient cpr, yder cpr og dato: Kategori A+
Match på "STED", patient cpr og dato: Kategori A
Match på "STED", patient cpr, men ikke dato: Kategori C
Ingen af ovenstående, og testintervallet er max 2 dage siden: Kategori D
Ingen af ovenstående: Kategori E

LPR:

Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. LPR-kilden benytter SHAK som nøgle.

Match på SKS afdelingskode, patient cpr og dato (Lookup overlapper med admitted): Kategori A
Match på SKS sygehuskode, patient cpr og dato (Lookup overlapper med admitted): Kategori B
Match på sks, patient cpr: Kategori C
Ingen af ovenstående: Kategori E

LPR3:

Mulighed for intern BRS-mapning fra SHAK til SOR kode. LPR3-kilden benyttes SOR-kode som nøgle. LPR3-data forefindes med nedenstående typer, som benyttes af reglerne:

F: FORLOEBSELEMENT
K: KONTAKT
P: PROCEDURE
I: INITIEL_HENVISNING
H: HENVISNING
R: RESULTATINDBERETNING
O: OPHOLDSADRESSE

Reglerne er således:

Match på SOR afdelingskode eller underafdeling, patient cpr, dato (Lookup overlapper med admitted) og type F, K, P, I eller H: Kategori A
Match på SOR sygehuskode, dato (Lookup overlapper med admitted) og type og type F, K, P, I eller H: Kategori B+
Match på SOR afdelingskode eller underafdeling, patient cpr, dato (Lookup overlapper med admitted) og type R eller O: Kategori B
Match på SOR afdelingskode eller underafdeling og patient cpr: Kategori C
Ingen af ovenstående: Kategori E

Beregning af om der skal bestilles opfølgning

Følgende logik afgør om der skal bestilles opfølgning:

1. Der tjekkes om der skal laves follow up. Det sker på baggrund af parametrene acceptableRelations, followupRelations og worstRelation (altid E)

Logikken til dette er:
- Hvis worstRelation (E) er stærk nok i forhold til acceptableRelations returneres der falsk til at der skal laves follow up.
- Hvis followupRelations er ALL returneres der sandt til at der skal laves follow up.
- Hvis worstRelation (E) er stærk nok i forhold til followupRelations så returneres der falsk ellers returneres der sandt.

Hvis punkt 1 returnerer sandt: bestilles der opfølgning og der returneres E til brugeren.

Hvis punkt 1 returnerer falsk: udfør beregningen på baggrund af actual relations (se logikken punkt 2).

2. Der tjekkes om der skal laves follow up. Det sker på baggrund af parametrene acceptableRelations, followupRelations og actual relations.
Logikken til dette er:
- Hvis actualRelation er stærk nok i forhold til acceptableRelations returneres der falsk til at der skal laves follow up.
- Hvis followupRelations er ALL returneres der sandt til at der skal laves follow up.
- Hvis actualRelation er stærk nok i forhold til followupRelations så returneres der falsk ellers returneres der sandt.

Hvis punkt 2 returnerer sandt: bestilles der opfølgning og actual relations returneres til brugeren.

Hvis punkt 2 returnerer falsk: der bestilles ikke opfølgning

Logikken i punkt 1 udføres ikke hvis property dk.nsi.brs.extended.followup.enabled er sat til falsk

I nogle tilfælde vil der være forsinkelser i registreringen af informationerne i kilderegistrene, og dokumentationen for relationen bliver mere sikker over tid, som illustreret nedenfor:

...

Content

Space Tools