...

Skalaen for klassifikationerne er4:

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

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" (af CSC betegnet "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

...

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.

...

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

Ændringslog