Invalid patient IDs when retrieving ThinkFast data

[ColinBD]

I am logging 9 patient IDs which fail validation but appear similar to valid IDs which makes me suspect these are the result of manual input errors when setting up a patient on the CANTAB and/or ThinkFast platforms. The IDs are shared in MS Teams.

I have setup a dictionary so that once we identify the typos/errors we can replace the invalid IDs during the validation process. Thus far we are confident making two corrections:

known_incorrect_ids = {'WRONG01':R-IGHT01', 'WRONG02': R-IGHT02'} 

We need to investigate the remaining 7 invalid IDs and then think about how we share this information.

[davidverweij]

I'd argue that we would like to have the ability to inject / insert additional known 'oddities' to this list in the future as possible errors are made throughout the clinical study.

How about we create an additional MongoDB table where we can manually inject mappings if we uncover them. Then, if the pipeline would ever run again; it can automatically resolve the unresolved records (given it looks far enough back in time).

Having this as an injectable 'table' also allows us to develop additional features for the Clinician Facing app - where a user could report this error and mismatch and possibly automatically add the new 'oddity' to the list.

In any case, I would suggest to have the check for oddities as a final resort - after any lookup with ucam, inventory and even after checking its validity. Because, if a ID is wrong but valid - we can change this in UCAM and the DMP would still accept the entry and all is well. If it is edited wrongly and it is no longer valid ID; then we need to catch these in our middleware only.