evolutiva
EVO-80
Central patient DB + shared identity/auth hub in enamel (mars/pluto/venus consume) - item f
Backlog normal
pepm-enamel-cc
Elazar 2026-07-20: enamel becomes the CENTRAL HUB for user authentication + patient info storage. Centralized patient DB lives in enamel; mars/pluto/venus consume it (DNI autocomplete-suggest on patient load, mismatch warnings 'DNI ya existe con otro nombre', cross-record dedup, shared statistics). Design owner: pm-enamel-cc. Per-app consumers already planned: MARS-331, PLUTO-437 (re-point these to consume the enamel store rather than each app building its own). Class-A when it touches auth/identity. Design-first: how apps read/write the shared patient store (API vs shared schema), identity anchor (DNI canonical), and access boundaries per app.
Sub-tickets — 0/1 done
MARS-534 Backlog
pmpm-mars-cc
Questions
No questions.
Activity
-
Elazar direction 2026-07-20: not a build-now decision - DISCOVERY/DATA-GATHERING phase. Two threads, different SSOT strength: (1) USER MANAGEMENT = enamel will be a HARD SSOT - authenticates users + holds the roster of catedras, comisiones, roles (this is the SSO/(b) direction, but future not now). (2) PATIENTS = enamel will PROBABLY be a SOFT source of truth; unifying patient data from mars/pluto/venus is expected to surface plenty of dirty data, so the model is uncertain. FOR NOW: pm-enamel-cc GATHERS DATA (design needs for the user-mgmt SSOT + profile/assess the patient-data landscape across the 3 apps to expose the dirty-data problem) and we revisit with Elazar. Deliverable = data + findings, NOT an implementation plan. No per-app auth rewrite committed.
-
pm-enamel dispatching read-only same-app profiling to db-mars/pluto/venus (patient schema shape, documento coverage/format quality, same-app dup + name-mismatch rates) + sketching user-mgmt hard-SSOT entities. CROSS-APP overlap detection HELD as a separate future decision: needs a privacy-conscious comparison method (canonicalized/hashed documento via the enamel hub, NOT raw PII exchange app-to-app) - to be proposed for Elazar sign-off once same-app findings exist. Deliverable = one combined findings doc.
-
EVO-80 interim (pluto profile, mars/venus pending): STRUCTURAL - pluto has NO patient DNI/name model; patient identity = free-text numeroHistoriaClinica per practica. Item (f)/MARS-331/PLUTO-437 shared-DNI premise does not hold for pluto. Design fork for Elazar: pluto adopts DNI+name capture vs central identity keys differently. Headline for the combined findings doc. PLUTO-437 caveated to block premature re-point.
-
COMBINED FINDINGS (pm-enamel, all 3 apps profiled read-only). HEADLINE: 'DNI autocomplete / DNI ya existe con otro nombre' is NOT buildable as specified for 2 of 3 apps - patient identity models are architecturally different. VENUS: real name+DNI, DB-unique (UNIQUE INDEX dniNormalizado), clean by construction - ONLY app where 'DNI ya existe' is answerable today. MARS: no patient name, no DNI number (only a document-TYPE field), anchors on free-text numeroHistoriaClinica; format messy; REAL dirty data - 59/293 reused-HC groups (~20%) have internal demographic conflict (different birthdate/sex under SAME HC). PLUTO: no patient name, no DNI at all, free-text-HC-only; clean format but mismatch-detection architecturally impossible. CENTRAL IMPLICATION: cross-app overlap can't be computed even ignoring privacy - mars/pluto HC are per-institution LOCAL ids (mars '12345' != pluto '12345'), not a shared key; only venus DNI could anchor cross-app matching. Unifying mars/pluto on DNI requires them to START capturing name+documentoType/Number first = per-app schema+workflow change, not just backend merge. USER-MGMT SSOT: findings only, (a) enamel-API role/roster lookups [small blast radius] vs (b) login-through-enamel true SSO [rewrites auth/callback fleet-wide] tension explicitly DEFERRED. Full detail in pm-enamel memory.
-
Patient-identity-model finding CONFIRMED by all 3 coders (Elazar-requested cross-check): coder-mars = practicas free-text numeroHistoriaClinica only, no patient DNI/name (tipoDocumentoOptionId type but no number). coder-pluto = free-text numeroHistoriaClinica only, no patient DNI/name. coder-venus = pacientes.dniNormalizado NOT NULL UNIQUE (real DNI anchor), nombreCompleto stored-not-unique, HC free-text. Confirms: venus has DNI patient identity, mars+pluto do NOT (free-text HC only). Item f blocked on: add patient name+DNI capture to mars+pluto (schema+data-entry) before any DNI unification. Decision pending Elazar (yes/not-now/discuss).
-
Mars patient-DNI finding FLIPS at data level (coder-mars-cc live read, Elazar-asked). practicas.numeroHistoriaClinica (2226 live values): 84.2% clean 7-8-digit Argentine-DNI shape, ~97% bare numeric. Field is de-facto populated with DNIs by data-entry convention. Schema intent is still HC-number: plain text, no validation, no separate documentoNumber column - so DNI-by-convention, not enforced. Implication: mars ALREADY captures patient DNI in practice; the fix is to formalize/validate the existing HC field (+ optional separate documentoNumber), NOT build new capture. Pluto uses the same numeroHistoriaClinica free-text field - obvious parallel to check if Elazar directs. Venus already has real pacientes.dniNormalizado NOT NULL UNIQUE.
-
Mars-PM adds to the HC-is-DNI finding: (1) no live PII leak from the stats surface - MARS-524 already excludes numeroHistoriaClinica from the clinico aggregate fact views because it reads as an identifier. (2) Any remediation (dedicated documentoNumber + validation, or scrub) is a patient-PII governance call for Elazar, NOT a proactive mars edit - mars stands by, no mars WI filed until EVO-80 assigns a leg.
task
4w ago by wi-cli-venus
4w ago