Version 0.6, 2019-11-08
Indholdsfortegnelse
Formålet med dette dokument er at beskrive de regler der giver anledning til de forskellige behandlingsrelationer.
Ud fra kilderegisterdata kan BRS udlede relationstyper imellem behandler og patient. De fire registre "Sikrede", LPR, Sygesikringsregisteret samt Henvisningshotellet håndteres som beskrevet nedenfor:
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 A+ ”Direkte behandlingsrelation”:
Eksplicit relation (f.eks. henvisning) mellem navngiven behandler og navngiven patient på et kendt tidspunkt.
Kategori A ”Samme tid, samme behandlingssted”:
Patient og Behandler var på samme behandlingssted på samme tid.
Kategori B ”Generel behandlingsrelation”:
Generel behandlingsrelation, f.eks. at patienten har udpeget en læge som ”egen læge”.Kategori C ”Historisk betinget behandlingsrelation”:
Historisk betinget behandlingsrelation. Patient og Behandler har været i kontakt tidligere.
Kategori D ”Kan ikke afklares pt.”:
Ingen evidens for nuværende.Kategori E ”Kan ikke afklares”:
Ingen evidens hverken nu eller senere.
Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. REFHOST-kilden benytter SHAK som nøgle.
Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. LPR-kilden benytter SHAK som nøgle.
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:
Reglerne er således:
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
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
0.1 | 2011-09-07 | Initielt Dokument | Trifork |
0.2 | 2013-10-21 | Opdateret SVN link | Trifork |
0.3 | 2017-03-08 | Tilføjet LPR evidensniveau B | Trifork |
0.4 | 2019-01-07 | Tilføjet LPR3 | Trifork |
0.5 | 2019-06-12 | Tilføjet mulighed for registrering med SOR kode | KvalitetsIT |
0.6 | 2019-11-08 | Opdateret regler for LPR3 og tilføjet beskrivelse af klassificeringskoder | KvalitetsIT |