Version 0.6, 2019-11-08

Indholdsfortegnelse

1. Formål

Formålet med dette dokument er at beskrive de regler der giver anledning til de forskellige behandlingsrelationer.

2. Regler

Ud fra kilderegisterdata kan BRS udlede relationstyper imellem behandler og patient. De fire registre "Sikrede", LPR, Sygesikringsregisteret samt Henvisningshotellet håndteres som beskrevet nedenfor:

2.1. Klassificeringer

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+ "Samme behandlingssted "Patient og Behandler var på samme behandlingssted (f.eks. sygehus)

• 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.

2.2. Registre (Evidenskilder)

2.2.1. 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

2.2.2. 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

2.2.3. 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

2.2.4. 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

2.2.5. 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

3. 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

4. Ændringslog