Versions Compared

Key

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

...

  • 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


Ændringslog

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.42019-01-07Tilføjet LPR3Trifork
0.52019-06-12

Tilføjet mulighed for registrering med SOR kode

KvalitetsIT
0.62019-11-08Opdateret regler for LPR3 og tilføjet beskrivelse af klassificeringskoderKvalitetsIT