¿Cómo dar de alta a un paciente de forma segura?

Alta segura no significa capturar todos los datos posibles

Un expediente necesita identificar correctamente al paciente, pero pedir campos sin propósito también aumenta el volumen de datos sensibles que debes proteger.

La forma más segura de dar de alta es separar tres preguntas:

1. ¿Qué datos mínimos necesita el expediente?
2. ¿Qué identificador necesitas para el flujo o intercambio que vas a realizar?
3. ¿Qué datos adicionales realmente son necesarios para la atención, contacto o cumplimiento?

El objetivo no es llenar todas las casillas: es que la persona correcta quede vinculada al expediente correcto y que cada dato tenga una razón para existir.

Qué datos mínimos debe tener un paciente en el expediente

El numeral 5.2 de la NOM-004-SSA3-2012 exige que el expediente incluya datos generales del establecimiento y, respecto del paciente:

• nombre;
• sexo;
• edad;
• domicilio;
• y los demás datos que establezcan las disposiciones sanitarias aplicables.

Eso es distinto de los campos que una aplicación puede pedir durante el primer formulario.

Por ejemplo, una fecha de nacimiento exacta permite calcular la edad y evita que el dato quede obsoleto al cumplir años. Un teléfono puede ser necesario para agenda o consentimiento remoto. Un país o entidad de nacimiento puede ser relevante para identificación e intercambio. Pero esos campos no deben confundirse con la lista literal de §5.2.

Importante: domicilio sí forma parte del mínimo general de NOM-004. Si el alta de tu software permite dejarlo pendiente, no debes interpretar “paciente creado” como “expediente documentalmente completo” hasta capturarlo cuando corresponda.

¿La CURP es obligatoria para crear un expediente clínico?

No como una regla universal derivada de NOM-004.

La NOM-004 §5.2 no enumera la CURP dentro de los datos generales mínimos del paciente.

La NOM-024-SSA3-2012 §6.5 sí introduce una regla específica para los SIRES: con fines de intercambio de información en salud, la CURP validada conforme a los lineamientos de la Secretaría de Gobernación debe ser el atributo de identificación única de personas. La misma norma dice que los SIRES no deben autogenerar la CURP y pueden soportar identificadores adicionales.

Por eso son incorrectas dos simplificaciones opuestas:

• “todo expediente clínico es ilegal si no tiene CURP”; y
• “la CURP nunca importa en un ECE”.

Importa especialmente en los escenarios de identificación e intercambio regulados por NOM-024.

Qué hacer si el paciente no recuerda su CURP

No la reconstruyas de memoria ni conviertas una estimación en un identificador confirmado.

RENAPO permite consultar la CURP en gob.mx/curp de dos maneras:

• introduciendo la clave cuando ya se conoce; o
• usando nombre, apellidos y datos de nacimiento.

Si el paciente puede ser localizado por esa vía, usa el valor emitido por RENAPO.

Un sistema puede calcular una propuesta estructural a partir de datos personales, pero eso no equivale a consultar RENAPO. Hay componentes de la CURP que no pueden confirmarse únicamente con nombre, fecha, sexo y entidad. Una propuesta debe cotejarse contra la constancia/documento antes de tratarla como identificador validado.

Y si el paciente realmente no tiene una CURP propia

No inventes una que parezca real.

El sistema debe poder representar explícitamente que no consta una CURP propia y evitar usar ese marcador para fusionar personas.

VITALINK utiliza en los flujos aplicables un valor genérico para declarar ausencia de CURP. Ese valor no identifica al paciente y puede repetirse entre personas; por eso el backend no lo reutiliza como si fuera una identidad única.

Cuando el paciente obtenga o aporte una CURP real, el dato vigente puede corregirse con trazabilidad.

Cómo numerar o identificar expedientes sin exponer datos

Separa tres identificadores que cumplen funciones distintas:

• ID técnico interno: opaco, estable y no derivado de datos personales;
• folio de expediente: identificador humano para operación/documentos;
• identificadores oficiales: CURP u otros, solo cuando corresponden a identificación/intercambio.

No uses como clave técnica pública:

• nombre + fecha de nacimiento;
• teléfono;
• email;
• CURP incrustada en una URL;
• números secuenciales expuestos sin autorización server-side.

Un UUID no sustituye autorización: que una ruta sea difícil de adivinar no significa que cualquiera con el ID deba poder leerla.

En VITALINK el paciente usa un UUID interno generado aleatoriamente. Además existe un folio de expediente para operación humana. La CURP real es una señal de identidad/intercambio, no el primary key del paciente ni una capacidad de acceso.

Cómo evitar pacientes duplicados

La deduplicación debe usar identificadores que realmente distingan personas.

Con una CURP real

Una CURP real y validada es una señal fuerte de identidad. Antes de crear un nuevo expediente conviene buscar si ya existe uno accesible en el universo autorizado.

En VITALINK, una CURP no genérica se comprueba contra los expedientes que el profesional está autorizado a consultar. Si existe un paciente autorizado con esa CURP, el alta se resuelve hacia ese paciente en vez de crear una copia.

Además, la base protege la unicidad de CURP reales. Los marcadores genéricos quedan fuera de esa regla porque, por definición, no identifican a una sola persona.

Sin CURP real

No fusiones expedientes solo porque dos personas comparten:

• nombre;
• fecha de nacimiento;
• teléfono;
• domicilio;
• o una CURP genérica.

Esos datos pueden coincidir legítimamente.

Ante una coincidencia probable, la decisión debe pedir evidencia adicional y conservar registro de por qué se unificó o no se unificó. Una deduplicación agresiva puede ser más peligrosa que un duplicado: mezclar la historia clínica de dos personas es un error de identidad clínica.

Qué datos pide hoy VITALINK al dar de alta

El flujo actual de alta de Expediente VITALINK exige, entre otros datos operativos:

• nombre;
• primer apellido;
• fecha de nacimiento;
• sexo biológico;
• país de nacimiento;
• entidad de nacimiento cuando corresponde a México;
• una CURP real o el marcador previsto para ausencia de CURP;
• y el flujo de privacidad/consentimiento que corresponda.

También dispone de campos para domicilio, contacto, nacionalidad, derechohabiencia y otras variables.

Que un campo exista en el formulario no significa que sea obligatorio en todas las normas. Y, a la inversa, que el sistema permita posponer un campo no elimina una obligación documental. El domicilio del paciente debe estar en el expediente conforme a NOM-004 §5.2.

¿Puede el paciente llenar sus datos antes de llegar?

Sí, si el flujo está diseñado como pre-registro y no como acceso abierto al expediente.

Un formulario previo debería:

• pedir solo lo necesario para preparar el alta;
• usar HTTPS;
• evitar identificadores o datos sensibles en la URL;
• tener un enlace impredecible y con vigencia cuando el formulario sea individual;
• no mostrar datos de otro paciente si alguien reenvía o manipula el enlace;
• separar datos declarados por el paciente de datos validados por el consultorio;
• exigir revisión antes de fusionar esa información con un expediente existente.

El paciente puede ayudar a capturar nombre, contacto, domicilio o antecedentes administrativos. La responsabilidad de evitar duplicados y vincular la identidad correcta sigue siendo del flujo del ECE.

A septiembre de 2026, VITALINK no publica un formulario general de autoregistro del paciente que cree el expediente completo. El alta ECE se realiza desde el entorno autenticado del profesional/equipo. Sí existen enlaces patient-facing específicos —por ejemplo privacidad, consentimientos y estudios— con alcances separados.

¿Es seguro enviar un formulario de alta por enlace?

Depende del diseño del enlace, no de que “sea un link”.

Para una operación sensible evita:

• IDs secuenciales fáciles de adivinar;
• información clínica en query parameters;
• enlaces permanentes que no puedan revocarse;
• respuestas cacheables;
• formularios que revelen el expediente con solo conocer un nombre o email.

Un patrón más seguro combina:

1. token aleatorio de alta entropía;
2. almacenamiento del hash del token cuando sea posible;
3. expiración;
4. uso único o alcance limitado;
5. rate limiting;
6. no-store para contenido sensible;
7. un factor adicional cuando la acción sea irreversible o de mayor riesgo.

No todos los formularios necesitan el mismo nivel de autenticación. Un formulario que solo recoge datos pendientes y requiere validación posterior tiene un riesgo distinto a firmar un consentimiento o descargar el expediente completo.

Cómo verificar que firma la persona correcta

Distingue dos controles:

• vincular el documento al paciente correcto;
• autenticar a la persona que está realizando la firma.

Un token que abre “el consentimiento de María” puede demostrar que el enlace apunta al registro correcto, pero no demuestra por sí solo que María sea quien sostiene el dispositivo.

Un flujo remoto puede elevar la confianza usando factores adicionales como:

• fecha de nacimiento u otro dato que ya conste y pueda verificarse;
• sesión autenticada;
• código de un solo uso a un canal previamente verificado;
• verificación presencial cuando el acto lo requiera.

No uses datos fáciles de adivinar como único factor para acciones de alto impacto. Y no presentes una firma gráfica como firma electrónica avanzada solo porque se capturó en pantalla.

Qué hace hoy VITALINK

Para consentimiento informado NOM-004, VITALINK usa un enlace con token expirante y resuelve en servidor la identidad canónica del paciente y del profesional; si esa identidad no puede resolverse, la superficie falla cerrado. Ese control evita que el documento muestre identidades inventadas o incompletas. El token, por sí solo, no es una prueba fuerte de la persona física que firma.

Para el consentimiento remoto de privacidad existe un flujo separado que combina el bearer con la fecha de nacimiento, limita intentos y puede bloquear el enlace. Son contratos distintos y no deben venderse como si tuvieran el mismo nivel de autenticación.

Cómo manejar pacientes menores de edad

No modeles al representante como si fuera el paciente. Mantén identidades separadas:

• paciente menor: expediente, datos clínicos y documentos propios;
• madre, padre, tutor o representante: identidad, relación y evidencia de la representación cuando corresponda;
• firmante: quién realizó cada acto concreto.

La capacidad para consentir depende del acto, edad/capacidad y marco aplicable; evita una regla de software que asuma que “ser menor” siempre implica el mismo firmante para todo.

En los consentimientos informados regulados por NOM-004 que requieren firmas, la norma contempla firma del paciente o de su representante legal y, en los supuestos correspondientes, testigos. El sistema debe poder registrar quién firma y en qué calidad, sin atribuir la firma del representante al menor.

Para comunicaciones y accesos digitales añade reglas de privacidad: no uses el teléfono del menor o del representante indistintamente sin saber a quién pertenece, y revisa los permisos cuando cambie la representación o el paciente alcance una situación de capacidad distinta.

Contacto de emergencia no es identidad ni representación legal

Guárdalo como una relación separada del paciente. Como mínimo:

• nombre;
• teléfono;
• parentesco o relación declarada.

No copies su teléfono al campo principal del paciente “para que haya uno” y no conviertas automáticamente al contacto de emergencia en tutor, representante legal o persona autorizada para recibir información clínica. Son conceptos distintos y pueden requerir evidencia diferente.

VITALINK modela hoy el contacto de emergencia como un objeto separado (name, phone, relationship) y permite retirarlo sin borrar la identidad del paciente.

Pacientes extranjeros sin CURP

La falta de una CURP mexicana propia no justifica inventar una. Conserva por separado país de nacimiento, nacionalidad y demás datos aplicables y usa el mecanismo previsto por el sistema para declarar ausencia de CURP cuando corresponda al flujo.

En VITALINK, el alta distingue nacimiento extranjero y soporta el marcador genérico XXXX999999XXXXXX99 para declarar que no consta una CURP propia en los escenarios que lo requieren. Ese marcador puede repetirse y no se usa para deduplicar personas.

Si la persona sí tiene una CURP emitida por RENAPO, registra la real. “Extranjero” y “sin CURP” no son sinónimos.

Qué hacer cuando dos pacientes tienen nombres muy parecidos

Nunca fusiones por nombre. Tampoco por una combinación débil como nombre + teléfono si existe ambigüedad.

Compara señales independientes:

• CURP real cuando exista;
• fecha de nacimiento;
• apellidos completos;
• contacto;
• domicilio cuando sea pertinente;
• identificadores/documentos adicionales disponibles.

Si la coincidencia no es suficiente, mantén expedientes separados hasta verificar. Un duplicado administrativo puede corregirse después; mezclar historias clínicas de dos personas puede contaminar diagnósticos, alergias, recetas y decisiones asistenciales.

La búsqueda debe ayudar a detectar posibles duplicados, no decidir automáticamente que dos nombres parecidos son la misma persona.

Cómo corregir datos sin borrar el historial

Un apellido mal capturado, una CURP equivocada o una fecha de nacimiento errónea no deben obligarte a conservar para siempre un dato falso.

La corrección segura distingue:

• actualización: el dato era correcto y cambió, como un teléfono o domicilio nuevo;
• rectificación: el dato era falso desde el principio, como una CURP mal transcrita.

En ambos casos importa la trazabilidad.

VITALINK permite rectificar identidad con:

• valor anterior y nuevo;
• motivo;
• autor;
• fecha/hora del servidor;
• control de versión para detectar cambios concurrentes.

Los documentos clínicos ya firmados no se reescriben. Conservan la identidad con la que fueron emitidos y la corrección pasa a regir hacia delante. Eso mantiene una historia comprensible de qué se sabía y cuándo.

Qué comprobar antes de terminar el alta

Una checklist útil es:

• ¿el nombre está completo y correctamente escrito?
• ¿sexo y fecha de nacimiento corresponden a la persona?
• ¿el domicilio exigido por NOM-004 quedó registrado?
• si usaste CURP, ¿es la emitida/consultada y no una aproximación?
• si no hay CURP propia, ¿el sistema lo representa sin fingir una identidad?
• ¿revisaste si ya existe un expediente antes de crear otro?
• ¿el aviso de privacidad y el consentimiento aplicable quedaron resueltos?
• ¿sabes cómo corregir un error posterior sin borrar documentos históricos?

Un alta segura no termina cuando el botón dice “Guardar”. Termina cuando la identidad puede sostenerse, la privacidad está resuelta y el expediente no mezcla a una persona con otra.