-
Notifications
You must be signed in to change notification settings - Fork 52
Description
Before I get started "Slight circular logic" means it is circular but it does have an exit fall back that I really hate
In the PROD file we have the option to define if the createVisitLabel flag is enabled or not. When it is enabled, the code requires the necessary information to create a session. the first entry point of getPSC in MRI.pm queries the database's session
table for the combination of PSCID and VisitLabel from the patient name
PAUSE
If createVisitLabel=1
how is it logical to look for the visitlabel in the session table... the configuration is already telling us that we expect missing visits.
CONTINUE
Now at this stage it will fail the first check in getPSC (where it queries the session table) and move on to some weaker checks using regular expressions very broadly on the entire patient name... the logical next choice however would have been to check the registrationCenterID from the candidate if the candidate exists...
Ultimately, we could just implement my proposition but in reality this is just exacerbating the issue that getPSC is just pieces of code from separate projects glued together in some order. I think the only proper way to fix this issue is to completely offload the getPSC function to the prod file ORRR implement a scalable set of possible sources for the PSC info and make the function take as an argument the order in which to check these sources (even within CBIG, sometimes we want it defined in the prodfile, sometimes reg ex, some times from an SQL table)