pluto PLUTO-437

Plan: paciente DNI + HC central store — autocomplete, dedup warning, estadísticas

Todo normal unassigned ⛔ awaiting elazar

Sub-tickets

No sub-tickets.

+ Add sub-ticket

Questions

q#35 · rob → elazar · 2026-05-25 · answered by wi-cli-venus

DNI obligatorio o opcional? (algunos pacientes podrían ser anónimos o extranjeros sin DNI argentino)

OPTIONAL — app prompts for DNI once, user may leave empty if insisted. (Elazar 2026-07-03)

q#36 · rob → elazar · 2026-05-25 · answered by wi-cli-venus

Key de dedup: ¿numeroHistoriaClinica es único por paciente, o DNI es el key canónico? ¿O ambos opcionales con warning si difieren?

DNI+HC both lookup keys; typing one autocompletes the other from the matched patient (user can overwrite, free text); warn on DNI<->HC conflict. PM-interpretation of Elazar's 'find two values, whatever not typed' — coder confirms exact UX at design.

q#37 · rob → elazar · 2026-05-25 · answered by wi-cli-venus

Migración: ¿backfill practicas existentes creando una fila pacientes por HC existente, o solo aplica a prácticas nuevas?

BACKFILL existing prácticas into pacientes rows. (Elazar 2026-07-03)

Activity

system created · 2026-05-22

wi cli
system note · 2026-05-22

Current state: practicas.numeroHistoriaClinica (HC) stored per-practica; NO dniPaciente column exists. Patients have no separate entity — identity only through HC + fechaNacimientoPaciente + sexoPaciente. Plan needed: (1) new 'pacientes' table with DNI + HC + nombre + apellido + fechaNacimiento; (2) FK practicas.pacienteId → pacientes.id; (3) autocomplete endpoint for HC/DNI lookup; (4) server-side warning on create-practica if DNI matches a different HC (or vice versa); (5) statistics queries (distinct patient count vs practica count). DB-first design; coder implements autocomplete + warning on practica form.
rob questionAsked · 2026-05-25

q#35 to=elazar: DNI obligatorio o opcional? (algunos pacientes podrían ser anónimos o extranjeros sin DNI argentino)
rob blocked · 2026-05-25

awaiting elazar
rob questionAsked · 2026-05-25

q#36 to=elazar: Key de dedup: ¿numeroHistoriaClinica es único por paciente, o DNI es el key canónico? ¿O ambos opcionales con warning si difieren?
rob blocked · 2026-05-25

awaiting elazar
rob questionAsked · 2026-05-25

q#37 to=elazar: Migración: ¿backfill practicas existentes creando una fila pacientes por HC existente, o solo aplica a prácticas nuevas?
rob blocked · 2026-05-25

awaiting elazar
wi-cli-venus questionAnswered · 6w ago

OPTIONAL — app prompts for DNI once, user may leave empty if insisted. (Elazar 2026-07-03)
wi-cli-venus questionAnswered · 6w ago

DNI+HC both lookup keys; typing one autocompletes the other from the matched patient (user can overwrite, free text); warn on DNI<->HC conflict. PM-interpretation of Elazar's 'find two values, whatever not typed' — coder confirms exact UX at design.
wi-cli-venus questionAnswered · 6w ago

BACKFILL existing prácticas into pacientes rows. (Elazar 2026-07-03)
wi-cli-venus statusChanged · 6w ago

All 3 product Qs answered by Elazar 2026-07-03; ready for db-first design (new pacientes table + autocomplete/dedup-warn).
wi-cli-venus note · 4w ago

2026-07-20: patient-DB centralization is now enamel's lane (EVO-80). Elazar: enamel = central hub for auth + patient storage. Re-point this to CONSUME the enamel-hosted patient store rather than building a pluto-local one. Coordinate with pm-enamel-cc / EVO-80 before implementing.
wi-cli-venus note · 4w ago

CAVEAT 2026-07-20 (EVO-80 discovery, pm-enamel): pluto captures NO patient DNI or name - patient identity is a single free-text numeroHistoriaClinica (NHC) on the practica row (no documentoType/documentoNumber, no patient name in schema). 100% NHC coverage, clean format, but same-NHC dup rate (49/417 groups) is UNCLASSIFIABLE (no name/DNI to corroborate). So the 'DNI autocomplete / DNI ya existe con otro nombre' framing does NOT apply to pluto as specified - it's an identity-MODEL mismatch vs the shared-DNI assumption. DO NOT re-point PLUTO-437 to 'consume a central DNI-keyed store' until Elazar decides: pluto adopts DNI+name capture (schema+workflow change) vs central identity keys on what pluto holds. Blocked on that design fork.