feat(ern): Create Internal Pseudonym (using Auto ID #183 dev team)

[Fernananas]

Is your feature request related to a problem? Please describe. For ERN ITHACA local installations we need a local pseudo-tool (Create Internal Pseudonym). This feature request provides a foundation for implementing the "Create Internal Pseudonym" feature. It ensures that patient identifiable information is stored separately from other patient data, with a pseudonym linking the two databases.

Describe the solution you'd like System Components: EMX2 installation, with two ILIAD databases: ”subject” and “internalIdentifier” User Interface: a. New Patient Creation Form (can be plus sign in EMX2) b. Pop-up Modal for Patient Identification (<needs to be created) Workflow:

1. User initiates "New Patient" action
2. System displays Pop-up Modal with fields:

• First Name (required)
• Last Name (required)
• Date of Birth (required)
• Hospital Identifier (optional)

3. User fills in the required information
4. User submits the form
5. System performs duplicate check
6. If duplicate found, display warning with existing pseudonym
7. If no duplicate, generate pseudonym and proceed
8. System displays Patient Information Form pre-filled with pseudonym
9. User completes Patient Information Form
10. System saves data to respective databases

Detailed Component Specifications: a. Pop-up Modal:

• Fields: First Name, Last Name, Date of Birth, Hospital Identifier
• Validation: Ensure required fields are filled
• Submit button

b. Application Server:

• Duplicate Check Logic
• Pseudonym Generation Algorithm (for now can be something easy, using molgenis-logic, computed value: ​​dataprovider.name_${mg_autoid})

Additional context In the future, fields that are required to create pseudonym, can be changed. And creation of pseudonym can be more complex, then my solution dataprovider.name_${mg_autoid}.

Design: ~~- if the hospital identifier is given, we use that to generate the pseudoid. Otherwise we use firstname, lastname, birthdate. ~~- we want the id field to check in the database if it already exists before we save, so that we can give the error immediately. ~~"There is already a pseudoid 'xxxx' for this hospital id/firstname/lastname/birthdate" => if(mg_clientside) ~~....; ~~- we use the firstname/lastname/birthdate OR hospitalid for the duplicate check, not the generated pseudoid so that the pseudo can be totally random. => this means we can use the autoid? <= can we make that shorter?

emx1 genetic line psuedo id: https://registry.molgenis.org/#browse/browse:appstore:molgenis-app-pseudonym-registration%2F1.2.0%2Fmolgenis-app-pseudonym-registration.v1.2.0.zip

[mswertz]

kan dit niet met aparte patienten details tabel (met dus pseudo, firstname, lastname, birthdate en dat je dan vanuit je research data tabel daarnaar verwijst (zodat je die research data apart kunt exporteren met alleen de pseudo)

[mswertz]

Gewenst:

• onderzoekers kunnen wel pseudoid zien maar niet de naam (dwz niet pseudo tabel, maar wel de waarde in huidige tabel)
• data invoerders moeten alleen van hun eigen patienten de naam zien, niet van anderen (is dat waar?)

oplossingrichting:

• we maken een staging area aan voor elke dokter / invoer groep (waar dus research ref heeft naar pseudo tabel met naam)
• en dan als 'klaar' dan wordt die data gekopieerd naar de research database, als dat voor 'centraal' is is dat niet meer werk en vinden we het prima, anders zouden we liever iets met een query doen (waarbij naam tabel dus wordt weggelaten en autoid als string wordt)

we worden niet blij van meerdere staging areas en/of heen en weer kopieren. Ideale oplossing is

• row level permissies, dwz, policy je ziet rijen in pseudo tabel als je de persoon ben die het ook heeft aangemaakt
• column level permissions, dwz, alle gebruikers mogen alle pseudo zien maar niet de namen

Het is een poging waard of we met sql deze permissies kunnen invoeren zonder dat het 'stuk' gaat.

• row level permissies zou dan een policy moeten zijn gebaseerd op user + mg_insertedby kolom => we denken dat dit kan zonder emx2 stuk te maken omdat er alleen rijen worden verborgen voor huidige gebruiker.
• column level is meer werk om uit te zoeken want verwachting is dat emx2 stuk gaat omdat ie probeert een kolom te querien waar dat niet mag => gewenste gedrag is dat ie dan die waarden laag laat ofzo.

https://www.postgresql.org/docs/current/ddl-rowsecurity.html