Proyecto ECE

Con lo del hospital Entre juntas informales, solicitudes contradictorias y equipos que parecen salidos de una subasta de 2010, al mismo tiempo terminé comprando para mi casa dos computadoras nuevas:

• PC armada: Ryzen 7 5700G, 32GB RAM, SSD de 512GB + 2 HDD, gabinete DeepCool CG530. aprox 7900
• Laptop ASUS e1504f: Ryzen 5 7520U, 8GB RAM, 512GB SSD.

Por separado, ambas son más poderosas que todo el parque tecnológico del hospital junto. Literalmente.

Como comenté antes llevaba unos 15 días en un hospital que me invitó a hacer el servicio social colaborando en la implementación de un Expediente Clínico Electrónico (ECE), pero hoy decidí retirarme. No por falta de ganas, sino porque el proyecto era tan absurdo como un caníbal vegetariano con helado de pollo rostizado. Técnicamente posible, conceptualmente insalvable.

Hoy llegué y a las 10:37 el Doctor César (seudonimo ) me preguntó si se podia hacer interfaz con el sistema de Farmacias. Y le dije que no porque no tenemos computadoras.

Avisé a la asistente del director y me dijo gracias. Y unos cinco minutos después me di cuenta que «Daniel» el de las farmacias, poco probable que pueda ser el proveedor, y que evidentemente no iba a recibir los cinco entregables. De eso deduzco que las farmacias no existen o no cumplen la normativa, que no existe la tabla de medicamentos, y que no tienen idea de las necesidades HL7 ni DICOM ni de como se lleva una farmacia.

Pero se desencadenan varias cosas. Es cinismo que si no tienen computadoras quieran hacer interfaz a un sistema de farmacia. Y que con las 15 hojas de la junta, mas la falta EVIDENTE de entregable de Daniel, el desorden administrativo es tal que no hay condiciones para cumplir la normatividad.

Así que me retiré.

No comenté que en 15 dias se pelearon con seis proveedores que llevé. En paralelo al arranque del proyecto, mi intento por resolver los problemas de infraestructura del hospital chocó de inmediato con la incompetencia y los constantes cambios de jugada en cosas básicas. En solo quince días, se pelearon con seis proveedores distintos. Intenté traer profesionales de confianza, pero cada propuesta de solución se estrellaba contra un ecosistema completamente disfuncional. El hospital quería lanzar una campaña publicitaria mientras tenía cámaras CCTV sin cableado, conmutadores obsoletos y equipo digno de una subasta de 2010. Querían implementar inteligencia artificial predictiva en un chat sin contar siquiera con infraestructura básica ni datos definidos. Gestioné seis proveedores: desde el técnico que diagnosticó 32 equipos en cuatro horas y entregó un reporte impecable (al que no le pagaron porque “no era lo suficientemente detallado”), hasta expertos en IA que ofrecieron soluciones viables pero fueron descartados por falta de claridad institucional. Intenté facilitar préstamos de computadoras Ryzen 5–7 con 16 GB de RAM, pero tras autorizaciones verbales y contradicciones internas, cancelaron todo sin previo aviso. Incluso para un proyecto urgente de reparación de teléfonos y conmutadores, propuse separar facturas y exigir anticipos mínimos, pero el hospital ni siquiera entregó su CIF. Al final, el dueño declaró que se haría lo que él dijera, que pagaría cuando quisiera, y que Daniel podía mover lo que fuera. En nuestra última reunión quedó claro que la lógica operativa era esa: pagar cuando se le antojara, sin respetar procedimientos ni garantías mínimas. En lugar de resolver problemas, prefería culpar a los demás—incluyendo a los proveedores que se negaban a trabajar sin condiciones claras. Y como colofón, me salió con que “lo verificaba alguien con maestría en evaluación COFEPRIS”, como si eso resolviera el desastre estructural que tenían frente a ellos.

¿Por qué me fui?

• Se niegan a firmar convenio de confidencialidad.
• Nadie sabe qué especialidades médicas manejan.
• Faltan hojas secundarias de permisos COFEPRIS en el área pública.
• El dueño afirma que quien lo verifica tiene una “maestría en regulación COFEPRIS” (spoiler: no existe).
• Hay razones para suponer que los equipos de cómputo pertenecen a otra razón social (falta grave). ¿Por qué?
• El servidor principal es un DELL 2010. Otro está tirado en el piso con el password en una etiqueta.
• Se pelearon con seis proveedores míos y otros dos en esos mismos quince días.
• No hay seguridad privada en la puerta. ¿Por qué?

El caso de la farmacia es una de cinco  o seis banderas amarillas

Como dije Un personaje (seudónimo: Daniel) pidió que el ECE tuviera un sistema de facturación multi clínica que manejara 128 farmacias, sin vincular receta, paciente ni factura. Quería que las enfermeras no usaran el sistema, pero sí operaran caja en una farmacia de 1.5 × 1.5 metros. Todo esto con laptops Celeron de 2017 y una impresora de tickets con QR mágico.

La operación propuesta requeriría una enfermera con OCHO manos y hasta desde el punto de vista eléctrico es imposible. Literalmente:

• Sostener la laptop (que no se debe usar en ese espacio reducido y viola otras normas)
• Escribir y mover el mouse
• Escanear el QR del ticket impreso y de la credencial de cliente. Nunca se les ocurrió del barcode del medicamento si lo hay y si no había que hacerlo (unidades de medida intrahospitalarias).
• Sostener la impresora
• Entregar el ticket
• Recibir la firma (para medicamento gratis)
• Entregar el medicamento
• Recibir la receta FISICA firmada del paciente, la mas necesaria por la norma.

Todo esto contradice la NOM-197-SSA1-2000, la NOM-004-SSA3-2012 y el sentido común.

Además:

• La factura electrónica requiere otro tipo de controles. Es un ámbito legal y fiscal que conozco bien.
• Un proyecto de ese tipo lo puedo hacer pero por el alcance del desarrollo no lo hago por menos de $90,000 MXN, más $15,000 por razón social adicional, más iguala de soporte, y empezando con anticipo de 40mil.
  • La iguala de soporte es indispensable porque el sistema requiere respaldos periódicos, adaptación constante de formatos fiscales, y atención a cambios de último momento del SAT—como los ajustes recientes en centavos dentro del Complemento de pagos. Esto sin contar las actualizaciones mayores (como el salto de CFDI 3.2 a 4.0), que se cotizan aparte. Por eso, en cualquier sistema de facturación serio, la iguala no es opcional: es parte del cumplimiento operativo y fiscal.
• Daniel no tiene idea del SAT ni de COFEPRIS, pero como se ve, tampoco de proyectos de sistemas y menos de farmacias:
• LIMITACIONES ENERGÉTICAS Y DE HARDWARE (anexo en respuesta a un lector 13/sep/25) Incluso desde el punto de vista energético, el modelo es inviable. La especificación mínima para operar expediente clínico electrónico, navegación institucional y periféricos (impresora, lector, red) debería incluir al menos un Intel Core i3 de 10.ª generación o AMD Ryzen 3 de 4.ª generación, con 8 GB de RAM y SSD de 256–512 GB. En cambio, se observaron dos o tres Lenovo de 4 GB, etiquetadas por cuatro personas: tres técnicos y yo como inservibles sin capacidad real para soportar carga operativa continua. Como dice el lector por whatsapp, El consumo energético de periféricos conectados supera la capacidad de batería de cualquier equipo moderno, que se agotaría en menos de dos horas. La infraestructura eléctrica no está diseñada para operación hospitalaria digital, ni cuenta con respaldo, reguladores o UPS. No hay computadoras de reemplazo disponibles en caso de falla, descompostura o agotamiento de batería, lo que compromete la continuidad operativa. Además, el cableado improvisado, la falta de canalización segura y la presencia de equipos conectados en pasillos y áreas comunes generan riesgos evidentes de tropiezos, cortocircuitos e incendios, especialmente en un entorno hospitalario donde circulan pacientes, personal y visitantes.Para transportar y operar el sistema completo, habría que sumar las manos 9 y 10… y aún así no funcionaría.

   

Lo que esto significa técnicamente :
En un sistema multifarmacia:

En teoría:

• Cada responsable sanitario debe validar digitalmente sus dispensaciones, es un rol nuevo
• Trazabilidad legal individual por establecimiento
• En teoría sellos digitales de facturación diferentes por ubicación geográfica de cada emisor, aunque sean varias sucursales por el código Postal
• Elaboración de documentación seguimiento y controles adicionales por cada establecimiento y RFC para garantizar «negocio en marcha» (principio NIIF basico y cumplir con normativas fiscales 29, 29-a y anexo 20),
• adaptar formatos de impresión de Ingreso, notas de crédito de inventario, notas de crédito financieras , cartas porte de traslado y complementos de pago por todas y cada una de las razones sociales y establecimientos
• Firmas electrónicas diferenciadas por responsable, y escanear la autógrafa
• Auditoría independiente por farmacia para COFEPRIS permiso 06 Y yo lo pediría en digital antes de hacerlo.

Su sugerencia de «multiclinicas/multirazón» es CRIMINALMENTE NEGLIGENTE:

• Mezclaria responsabilidades sanitarias (no solo el de farmacia sino del ECE)
• Violaría trazabilidad requerida por COFEPRIS
• Pondría en riesgo penal a los responsables sanitarios
• Incumpliría normativa de farmacovigilancia

Un verdadero experto en farmacias JAMÁS sugeriría eso.

Mi respuesta?

Ese día entregué un reporte técnico de 15 hojas sobre la junta, acompañado de otros nueve documentos relacionados de ese mismo día. Documenté cada contradicción, cada violación normativa y cada petición absurda de esa junta. No me fui por enojo. Me fui porque el proyecto era inviable, y porque no voy a simular cumplimiento donde no hay ni infraestructura ni voluntad de cumplir. Hay varias banderas amarillas y una o dos banderas rojas.

Para ellos, la causa de que los profesionales se vayan no es su desorden o su ilegalidad. La causa es que «la gente no aguanta la presión,» «no entiende la forma de trabajar aquí,» o «se espantó con la complejidad del proyecto.»» Esa narrativa les permite seguir medio operando sin corregir nada y hacerse tontos solos.

Conclusión?

Estrené computadoras. Me fui del hospital. Y dejé constancia. Porque cuando el absurdo supera la logística, lo más profesional es retirarse sin ruido, con los reportes entregados y todo anotado para cerrar el ciclo con claridad.

En agosto 2025 intenté implementar un ECE en un hospital sin computadoras funcionales.

Ante la falta de infraestructura mínima (ni una computadora funcional), el proyecto fue inviable. Sin embargo, generé una serie de documentos técnicos que pueden servir como referencia para estudiantes, auditores o consultores enfrentando condiciones similares.

Por la forma en que se dieron las cosas me di cuenta que no tenía caso entregar este reporte. Lo iba a entregar el día que decidí irme. Es un borrador pero funcional.

Titulo Opcional: Violación masiva de normas en 128 farmacias.

Dilema de Cuernos: Sistema Farmacéutico y Cumplimiento Normativo

Caso de Estudio para Profesionales en Sistemas, Contabilidad y Asistentes de Dirección

Contexto del Problema

Te contactan para desarrollar una interfaz entre tu sistema ECE (Expediente Clínico Electrónico) y un supuesto «software de farmacias» que según el propietario:

• Está «comercializado» e instalado en 128 farmacias
• No proporciona documentación técnica inicial
• El propietario demuestra desconocimiento básico de normativas farmacéuticas / sat / contabilidad
• No aparece en búsquedas de internet como software farmacéutico (solo algo parecido como software de consultorios)

Marco Normativo Aplicable

Para Sistemas:

• SIRES (Estandard para comercializar Software Farmacéutico relacionado con ECE en Empresas Farmacéuticas) – Obligatorio
• HL7 / HL7-JSON Estándar para intercambio de datos médicos
• COFEPRIS – Regulación sanitaria de establecimientos farmacéuticos, que se suma a ley de general de salud
• Licencias – Se compró? a quién ? Software libre, donde está el código ?
• Soporte – No podemos permitir acceso a base de datos ni hosting sin contrato o confidencialidad
• Tolerancia – Si son 128 instalaciones son 128 respaldos y PC / hospedajes. Si es una sola, se rompen todas las leyes

Para Contabilidad:

• Facturación obligatoria de software comercial
• Registro ante SAT de actividades comerciales
• Trazabilidad de licencias y mantenimiento
• Nadie trabaja gratis en 128 farmacias a la vez
• Donde se pone el software ? ¿que usuario firma de recibido?

Para Protección de Datos:

• LFPDPPPSO – Convenios de confidencialidad obligatorios por razón social y/o responsable sanitario
• Responsabilidad por manejo de datos médicos sensibles
• Autorización específica por razón social/responsable sanitario
• Cofepris pide software en plataforma propia o documentada

El Dilema de Cuernos

Cualquier decisión que tomes te lleva a la conclusión de que algo está mal:

Opción A: «El software es gratuito»

Implicaciones:

• ❌ Imposible económicamente: Nadie da soporte ni hospedaje gratuito a 128 farmacias
• ❌ Imposible económicamente: Mucho menos en 128 servidores distintos
• ❌ Probable evasión fiscal: Sin facturación de servicios comerciales
• ❌ Sin garantías: Software gratuito MASIVO sin responsable legal definido violatorio a COFEPRIS
• ❌ Mantenimiento inexistente: ¿Quién respalda las actualizaciones o corrige errores?
• ❌ Código Libre: ¿Donde está el código?

Opción B: «El software es comercial pagado»

Implicaciones:

• ❌ No está en SIRES: Operación ilegal de software farmacéutico
• ❌ Sin cumplimiento COFEPRIS: Violación de normativas sanitarias por SIRES / software /hospedaje
• ❌ Facturación irregular: Si es comercial, ¿dónde están las facturas?
• ❌ Alojamiento irregular: Si es comercial, ¿dónde están las facturas y respaldos? Se viola COFEPRIS.

Opción C: «Es software libre comercializado»

Implicaciones:

• ❌ Sin código fuente disponible: Violación de licencias de software libre
• ❌ Comercialización irregular: Software libre no puede venderse sin código fuente
• ❌ Marco legal confuso: ¿Quién es el responsable legal?

Opción D: «Verificación técnica estándar»

Si yo solicité entregables SIMPLES y no los dieron: Exportación HL7/JSON del sistema

• ❌ No podrían proporcionarla: Confirma que no es sistema profesional
• ❌ Responsables sanitarios: Imposible que sean iguales para 128 establecimientos
• ❌ Estándares inexistentes: Sin HL7 no hay interoperabilidad real

Análisis de Protección de Datos

El Problema de Confidencialidad

128 farmacias implican:

• Miles de expedientes médicos
• Datos personales sensibles (recetas, diagnósticos)
• Requisito legal: Convenio de confidencialidad con cada razón social
• Responsabilidad civil: Filtración de datos = sanciones INAI, COFEPRIS, SALUD
• Trazabilidad a Paciente implica facturación del mismo producto. Tormenta SAT en camino.
• 128 respaldos independientes que requieren hacerse, y verificarse, o uno solo que incumple todas las leyes.

La Pregunta Clave

¿Cómo puede alguien sin idea de farmacias (dice que en un hospital no deben coincidir las recetas cobradas con lo que se factura), y que dice que las enfermeras no tienen que interactuar con el sistema garantizar que se de soporte técnico a datos médicos de 128 establecimientos sin convenios de confidencialidad?

Respuesta: Es técnica y legalmente imposible de manera legal.

Consecuencias de Crear la Interfaz

Para un Sistema ECE o Contable:

• Contaminación de datos: Interfaz con sistema irregular vicia la integridad
• Responsabilidad legal: Ser cómplice de irregularidades normativas
• Riesgo institucional: El hospital , y empresa, no solo el sistema quedan expuestos a sanciones regulatorias

Para Responsabilidad Profesional:

• Art. 222 CNPP: Obligación de denunciar delitos detectados
• Ética profesional: No participar en esquemas irregulares
• SAT y COFEPRIS: Probablemente responsable solidario como contador, dueño, responsable sanitario
• Protección patrimonial: Evitar responsabilidades civiles y penales

La Decisión Correcta

Metodología de Verificación Previa:

1. Solicitar factura de compra del software (probablemente inexistente)
2. Verificar registro SIRES (seguramente no existe)
3. Pedir exportación HL7/JSON (técnicamente no podrán proporcionarla)
4. Revisar convenios de confidencialidad (128 convenios requeridos)

Fundamento de la Negativa (salida elegante):

«Crear interfaz con sistema que no cumple normativas SIRES/COFEPRIS viciaría la integridad de nuestro ECE y nos expondría a responsabilidades legales por manejo irregular de datos médicos sensibles.»

Lecciones Aprendidas

Para Profesionales en Sistemas:

• Verificar cumplimiento normativo antes de crear interfaces
• Proteger la integridad de sistemas existentes
• HL7 y estándares son obligatorios, no opcionales
• Respaldos: Son coherentes ? cuanto tiempo  se necesita ? quien los hace y verifica?

Para Profesionales Contables:

• Software comercial requiere facturación rastreable
• 128 licencias = inversión considerable verificable
• Sin documentación fiscal = red flag inmediata

Para Asistentes de Dirección:

• Convenios de confidencialidad son obligatorios para datos sensibles
• Verificar credenciales antes de autorizar accesos
• Marco legal claro protege a la organización

Conclusión del Dilema

Resultado: Por cualquier camino de análisis (técnico, contable, legal, de protección de datos), la conclusión es que  en caso de existir, el supuesto sistema presenta irregularidades fundamentales.

La decisión profesional correcta: Negarse a crear la interfaz para proteger la integridad del sistema propio y cumplir con obligaciones legales y éticas.

Moraleja: Un «dilema de cuernos» bien analizado demuestra que cuando todas las opciones señalan problemas, la respuesta correcta es no participar en el esquema irregular.

Este caso de estudio está basado en situaciones reales y sirve como ejemplo de aplicación de metodología profesional en la detección de irregularidades sistémicas.

Titulo Opcional : Fantasía Operativa en farmacias hospitalarias.

El miércoles a las 16, durante una junta de otra cosa pedí una revisión técnica de los datos para el módulo de farmacia del hospital, se detectó una serie de inconsistencias que no solo contradicen la normativa vigente, sino que exigen una capacidad operativa digna de una criatura mitológica.

Una persona al que llamaré Daniel, que conocí ese día, Quería que el ECE ser volviera un sistema multi facturas de clinicas con farmacias y dijo tener un catálogo completo de medicamentos que podía pasar. Pero me pidió al mismo tiempo un layout catálogo de artículos, así que el jueves en la tarde le pasé a la asistente del director mi layout simplificado con trazabilidad de incoterms, armas de fuego, lote y perfiles aduaneros para poder hacer las cartas porte de traslado/cadena de frio. Y al mismo tiempo pedí cinco entregables que no creo que me den.

El layout de cat_articulos que entregué es un estandard de inventarios (NO FISCAL NI DE MEDICAMENTOS que usan tablas aparte) que no incluye los datos fiscales y a la vez incluía trazabilidad para identificación de artículos sensibles como medicamentos, insumos de cadena de frío, y también elementos de seguridad como chalecos antibalas o municiones, que en ciertos entornos operativos forman parte del inventario logístico. En estos casos, es indispensable verificar que el receptor cuente con permiso vigente de portación de armas de fuego antes de entregar, ya que son insumos que entran y salen del almacén bajo control normativo. Este tipo de trazabilidad lo desarrollé años atrás para un sistema de transporte de valores, y ha sido necesario cuando tienen guardaespaldas de alto perfil. He tenido que hacer pocos cambios en el transcurso de los años al layout , principalmente cuando cambia alguna normativa y es necesario por trazabilidad técnica.

En particular, cuando se trata de guardaespaldas o personal de seguridad que realiza prácticas de tiro, o que usa los insumos, no se puede dar entrada ni salida a municiones sin documentación formal. Incluso con Permiso colectivo. La Ley Federal de Armas de Fuego y Explosivos, junto con su reglamento, exige que toda munición esté registrada y vinculada a un permiso vigente. Entregar balas sin constancia, incluso en un entorno privado, puede derivar en responsabilidad penal directa. Por eso, en cualquier sistema logístico serio, este tipo de artículos debe incluir trazabilidad por lote, perfil aduanero, y validación de permisos antes de su entrega. El hecho de que los permisos puedan tener cambios (por ejemplo, cuando se contrata o se despide personal) hace que esta verificación sea un paso crítico en cada entrega.

Al entregar el layout, me acordé de los horrores de un sistema de compras que implementé en 2008, diseñado para manejar cadena de frío con controles de 90 días. Uno de sus campos estaba destinado a explicar qué modalidad DDP (INCOTERMS) se aplicaba, y otros registraban volumen, peso y kilos por pallet—datos indispensables para compras masivas, como las de papel higiénico o insumos de transporte internacional. Tanto la correcta especificación del modo DDP como el control de volumen son esenciales en farmacias, especialmente cuando se requiere emitir cartas de traslado bien hechas y mantener trazabilidad en la relación con proveedores. Y el volumen es necesario para medir espacio NECESARIO para calcular el costo de almacenamiento, componente del precio final.

La propuesta presentada por Daniel quien afirma tener un sistema funcional, es inviable incluso desde el punto de vista eléctrico. Tener un sistema instalado en cientos de farmacias (sin evidencia técnica ni comercial verificable), según el requiere para funcionar que una enfermera realice simultáneamente las siguientes tareas:

1. Sostener la laptop que él considera indispensable y que no se debe usar por varias razones.
2. Escribir en la laptop y mover el mouse.
3. Escanear el QR del ticket impreso y de la credencial de cliente. Nunca se les ocurrió del barcode del medicamento si lo hay y si no había que hacerlo (unidades de medida intrahospitalarias).
4. Entregar el ticket.
5. Recibir la firma del paciente. (tiene derecho a medicina gratis)
6. Sostener la impresora.
7. Entregar el medicamento.

En el documento no quise parecer burlón y poner la octava y mas importante.

1. Recibir la receta física, validarla y archivarla conforme a trazabilidad clínica.

La octava mano que no mencioné originalmente es, de hecho, la más crítica. Sin este paso:

• No hay vínculo entre prescripción y entrega.
• No hay trazabilidad fiscal ni sanitaria.
• Se rompe el flujo de validación exigido por la NOM-004-SSA3-2012 y la NOM-197-SSA1-2000.

Esto no es un capricho operativo. Es una exigencia legal. Y lo que se propone no es un flujo técnico: es una fantasía logística sin respaldo normativo ni infraestructura real.

• LIMITACIONES ENERGÉTICAS Y DE HARDWARE (anexo en respuesta a un lector 13/sep/25) Incluso desde el punto de vista energético, el modelo es inviable. La especificación mínima para operar expediente clínico electrónico, navegación institucional y periféricos (impresora, lector, red) debería incluir al menos un Intel Core i3 de 10.ª generación o AMD Ryzen 3 de 4.ª generación, con 8 GB de RAM y SSD de 256–512 GB. En cambio, se observó una Lenovo de 4 GB, sin capacidad real para soportar carga operativa continua.Como dice el lector por whatsapp, El consumo energético de periféricos conectados supera la capacidad de batería de cualquier equipo moderno, que se agotaría en menos de dos horas. La infraestructura eléctrica no está diseñada para operación hospitalaria digital, ni cuenta con respaldo, reguladores o UPS. No hay computadoras de reemplazo disponibles en caso de falla, descompostura o agotamiento de batería, lo que compromete la continuidad operativa.Además, el cableado improvisado, la falta de canalización segura y la presencia de equipos conectados en pasillos y áreas comunes generan riesgos evidentes de tropiezos, cortocircuitos e incendios, especialmente en un entorno hospitalario donde circulan pacientes, personal y visitantes.Para transportar y operar el sistema completo, habría que sumar las manos 9 y 10… y aún así no funcionaría.

Además, la farmacia en cuestión cuenta con un área de 1.5 × 1.5 metros, lo cual imposibilita la operación simultánea de laptop, lector de códigos, impresora de tickets y firma de paciente. La norma es clara: no puede haber equipo instalado sin condiciones específicas de seguridad, espacio y trazabilidad.

La frase “sin perjuicio de otras disposiciones aplicables” abre la puerta a aplicar también la NOM-241-SSA1-2021 (buenas prácticas de dispositivos médicos) y la NOM-016-SSA3-2012, si el equipo se usa para prescripción o trazabilidad.

Los entregables que pedí  y pase por escrito a la asistente del director hoy jueves fue

«Asunto: Limitaciones Legales y de Hardware para Sistema Electrónico y Deslinde Técnico» (pag 8 / 15)

ENTREGABLES DANIEL
Requerimientos mínimos para avanzar en el módulo de farmacia
De acuerdo con lo conversado el día de ayer, y en seguimiento al punto anterior sobre
infraestructura y hardware, se establece que para poder avanzar en el desarrollo del módulo de
farmacia, se requiere la entrega inmediata de los siguientes cinco elementos por parte del Sr.
Daniel:
a) Catálogo de medicamentos Se solicita el catálogo completo de medicamentos que Daniel
tiene implementado en su sistema, con el objetivo de evitar duplicidad de captura por parte del
personal hospitalario. Este insumo es indispensable para garantizar compatibilidad operativa y
trazabilidad clínica.
b) Modelo de impresora de tickets y lector de QR Debe indicarse con precisión el modelo de
impresora de tickets y el lector de códigos QR que se utilizan en las farmacias donde su sistema
está instalado. Esta información permitirá al tesorero, Luis, realizar la cotización y gestionar la
orden de compra correspondiente sin mi intervención. Sin esta especificación, no se puede
garantizar la interoperabilidad del sistema.
c) Definición del flujo QR Se requiere una explicación clara y verificable sobre quién genera el
código QR, quién lo escanea, y en qué momento del flujo operativo ocurre cada paso. Esta
definición es crítica para evitar simulación tecnológica y garantizar trazabilidad fiscal y sanitaria.
d) Ejemplo impreso de QR funcional Solicitamos un ejemplo impreso de un código QR funcional,
con el fin de verificar su legibilidad, estructura de datos, y destino (es decir, a qué dirección de
internet conduce). Dado el alto nivel de saturación de errores en códigos QR mal diseñados,
contar con un ejemplo real permitirá validar el diseño y replicarlo de forma segura.
e) Demostración operativa en farmacia Se solicita fecha y hora para realizar una demostración completa del proceso en farmacia, utilizando el equipo actualmente disponible y el flujo que Daniel propone. Esta demostración permitirá verificar la viabilidad física, técnica y normativa de su propuesta.

Nota adicional: Sería ideal que el lector de QR propuesto también pudiera leer el código de barras de el proyecto de credenciales de clientes. En caso contrario, las credenciales de cliente requerirían su propio lector, lo cual complica aún más la operación. Si, como se ha afirmado, las enfermeras no utilizan computadoras, entonces no queda claro quién escanearía las credenciales ni cómo se integraría ese paso al flujo operativo.

Conclusión: Sin estos cinco entregables, no es posible avanzar en el desarrollo del módulo de farmacia. La responsabilidad de definir estos elementos recae directamente en el Sr. Daniel, quien ha afirmado conocer el sistema y su operación. En caso de no entregarlos, su propuesta
quedaría expuesta como materialmente inviable

Lo pude entregar hasta las 5 de hoy jueves esa hoja al tesorero y a la asistente del director, a ella todo,  después de entregarlo físico. Mi idea es pasar a diario con ella y checar a diario con ella cual de los cinco ya tienen listo.

Anexo del 12/sep/2025

Como dato curioso de esos mismos nueve documentos que entregué, uno era para documentar un error garrafal de otro doctor sobre algo relativo a recetas. Daniel no es doctor, pero al empezar las pruebas de mi módulo de recetas, me pidieron hacer un cambio (no digo qué) pero iba contra al norma, y además debí avisar por escrito al hospital. Así que sin decir lo que me pidieron que cambiara en la captura de datos Copio un fragmento de el documento, y remuevo la parte del error de doctor implicado.

Pongo un Fragmento de 10 sep 2025

Peticiones de cambiar módulo de recetas van contra la norma COFEPRIS  solicitado por Dr (removido)

2. Aclaración normativa

Las normas que regulan la prescripción médica y la trazabilidad farmacológica son:

• Ley General de Salud, artículos 226 y 227 Regulan la clasificación de medicamentos y el control de su prescripción.
• Reglamento de Insumos para la Salud, artículos 28 , 29 a 32
• Establecen los requisitos de la receta médica, incluyendo firma del prescriptor, datos del paciente, y conservación como parte del expediente clínico. a la letra :»

  ARTÍCULO 29. La receta médica deberá contener impreso el nombre y el domicilio completos y el número de cédula profesional de quien prescribe, así como llevar la fecha y la firma autógrafa del emisor.»

   

• NOM-004-SSA3-2012 (Expediente clínico) Define los elementos mínimos del expediente, incluyendo la receta como documento legal vinculante.
• NOM-220-SSA1-2016 (Farmacovigilancia) Regula el seguimiento de reacciones adversas y el uso seguro de medicamentos, lo que exige trazabilidad completa.

Así que el dato lo tengo fresco.

En particular, el artículo 29 del Reglamento de Insumos para la Salud establece que la receta debe conservarse como respaldo legal de la dispensación. Pero no es el único ni el más importante. No contemplar la firma del prescriptor es absurdo, tanto desde el punto de vista clínico como legal.

y que no lo cheque una enfermera menos, como diría una conocida «Por Dios !!!»

En agosto 2025 intenté implementar un ECE en un hospital sin computadoras funcionales.

Ante la falta de infraestructura mínima (ni una computadora funcional), el proyecto fue inviable. Sin embargo, generé una serie de documentos técnicos que pueden servir como referencia para estudiantes, auditores o consultores enfrentando condiciones similares.

Los documentos aquí publicados fueron entregados formalmente durante ese tiempo. No han sido modificados ni corregidos, ya que hacerlo sería alterar la historia institucional que los generó. En lugar de mantener copias, los presento como evidencia técnica acompañada de contexto operativo, normativo y estratégico. Esta publicación busca preservar la memoria de decisiones, omisiones y simulaciones que afectan la trazabilidad clínica, fiscal y legal de los sistemas hospitalarios.

Este es un reporte que entregué de una junta que duró unos 45 minutos.

Los nombres y entidades específicas han sido anonimizados para proteger la privacidad institucional. Las referencias operativas se mantienen para fines técnicos y de trazabilidad.

Asunto: Limitaciones Legales y de Hardware para Sistema Electrónico y Deslinde Técnico

Asunto: Limitaciones Legales y de Hardware para Sistema Electrónico y Deslinde Técnico

Fecha: 10 de septiembre de 2025

Preparado por: 

Dirigido a: Direccion:

Este informe técnico tiene como objetivo documentar las limitaciones operativas, legales y normativas que afectan el desarrollo e implementación del sistema electrónico solicitado, así como establecer un deslinde técnico ante propuestas que no cumplen con los requisitos mínimos de infraestructura, trazabilidad y cumplimiento fiscal-sanitario.

Partes del documento:

1. Elección de Equipo de Cómputo Requerida por Daniel y Luis (tesorero), sin insumos mínimos ni validación técnica. Esta solicitud viola normas operativas de COFEPRIS y me hizo perder aproximadamente 30 horas reales de trabajo.
2. Inconsistencias SAT / COFEPRIS / Funciones de Farmacia (Daniel) Se documentan contradicciones entre lo propuesto y lo exigido por normativa fiscal y sanitaria, incluyendo simulación operativa y ausencia de trazabilidad.
3. Entregables necesarios de Daniel para avanzar en farmacia y módulo de caja Se detallan los insumos técnicos que deben entregarse para poder iniciar desarrollo: catálogos de medicamentos, definiciones operativas, y aclaraciones normativas.
4. Entregables contradictorios Se documenta la expectativa de seis módulos operativos en cinco días, sin infraestructura ni definición de responsables, formatos clínicos o condiciones mínimas.
5. Notas por área Análisis técnico por módulo (Credenciales de Descuento, ECE, Recetas, Farmacia, Caja, Citas Médicas), incluyendo implicaciones fiscales, sanitarias y contables. Se anexan las normas violadas y recomendaciones formales.
6. Apendice Software – Daniel

ELECCION DEL EQUIPO DE COMPUTO:

1. Contexto de decisión

El día 10 de septiembre, estaba por entregar la cotización del plan de computadoras en préstamo (Cibercafé), previamente autorizado por el Dr. John Doe. Sin embargo, se me indicó que debía coordinar directamente con Daniel y Luis. A las 16:00 horas, ambos expresaron lo siguiente:

• Luis: Solicita exclusivamente equipos All-in-One.
• Daniel: Solicita laptops, afirma que él las comprará si se le entregan especificaciones.
• Luis: Pide revisar laptops con 4 GB de RAM que ya fueron descartadas por tres técnicos. Estos equipos, con Windows 10 y procesador Celeron, no cumplen los requisitos mínimos. Es como intentar correr una maratón con los pies atados: no pueden ni abrir un navegador sin colapsar.
• Ambos: Rechazan el equipo armado que ya había sido validado y entregado en préstamo.
• Ambos: Rechazan la instalación de equipo en terminal de enfermería y quieren hacerlo en farmacia, a pesar de que la normativa lo prohíbe por condiciones de espacio, seguridad y trazabilidad.
• Dr. Equis, Luis y Daniel: Afirman que las enfermeras no necesitan computadoras.

2. Requisitos mínimos para operación del ECE

3. Solicitud operativa

Para evitar conflicto de intereses y simulación operativa, solicito:

• Indispensable: Que quienes tienen poder de decisión compren las computadoras. He invertido más de nueve horas en el plan del cibercafé y casi dos semanas en análisis de hardware. Si no tengo autoridad de compra, tampoco tengo responsabilidad sobre fallas futuras.
• Viabilidad del proyecto: El éxito del ECE depende de contar con computadoras que cumplan los requisitos. Revisar nuevas opciones nos hará perder 2 o 3 de los cinco días restantes antes del 15 de septiembre.
• Equipo funcional: Solicito un equipo con las características anteriores para continuar el desarrollo. Hoy traje una laptop personal con factura para trabajar conforme a la norma.
• Asignación operativa: Se deben definir los equipos para enfermería: Primer, segundo y tercer piso Sin esta asignación, se incumple la NOM-024-SSA3-2012 y se rompe la trazabilidad clínica exigida por COFEPRIS.
• Coordinación de compra: Daniel y Luis deben formalizar la decisión de compra y definir la cantidad de equipos. Sin cuatro computadoras reales para enfermería, el sistema no podrá operar.
• Reconocimiento del plan descartado: El plan de computadoras en préstamo fue descartado sin justificación técnica. Puede retomarse, pero requiere pago inmediato. Ya se afectó al proveedor y se perdieron horas de trabajo.

4. Riesgos normativos y operativos

• Laptops arrumbadas: Tres unidades sin cargador, sin trazabilidad, con 4 GB de RAM.
• Farmacia: Espacio de 1.5 × 1.5 m sin mueble ni extintor.
• Normativas aplicables:
  • NOM-016-SSA3-2012: Infraestructura informática en salud
  • NOM-002-STPS-2010: Prevención de incendios
  • NOM-004-SSA3-2012: Trazabilidad del expediente clínico

Instalar una laptop en farmacia o quirófano sin condiciones mínimas es una violación directa de estas normas. Si se me pide “decidir dónde ponerla”, reitero: eso lo define la norma, no yo.

5. Justificación técnica y normativa para equipos en enfermería

• Lógica operativa: Las enfermeras son el primer punto de contacto clínico. Ellas registran signos vitales, evolución del paciente y eventos críticos. Si no capturan directamente en el ECE, se rompe la cadena de trazabilidad.
• Normativa aplicable:
  • NOM-024-SSA3-2012, artículo 5.1.2: El expediente clínico electrónico debe ser accesible y registrable por el personal que atiende directamente al paciente.
  • COFEPRIS: Requiere trazabilidad de datos clínicos desde el origen, no solo desde el médico.
  • NOM-004-SSA3-2012: La responsabilidad del registro no puede delegarse informalmente; debe ser directa, segura y documentada.

Un sistema donde las enfermeras no capturan información rompe el principio de trazabilidad clínica, vulnera la normativa, y convierte el ECE en una simulación operativa.

6. Deslinde técnico

Dado que se han solicitado tres soluciones distintas (All-in-One, laptops, equipos armados), y se ha descartado mi propuesta validada, me deslindo de cualquier decisión de hardware que contradiga la normatividad vigente. El sistema no podrá usarse si no se cuenta con equipo funcional y asignación operativa clara.

7. Ejemplo de referencia

Hoy adquirí una laptop personal por menos de $10,000 MXN, con especificaciones adecuadas para desarrollo. Las laptops similares oscilan entre $8,000 y $9,000 si no son reconstruidas. Esta decisión fue tomada para poder continuar con el desarrollo del sistema, ante la falta de condiciones institucionales mínimas.

8. Documentación adjunta

Se adjunta la cotización técnica que iba a ser presentada el día 10 de septiembre, previamente autorizada por el Dr. John Doe, y que fue descartada por decisión de Daniel y Luis. Esta cotización incluye:

• Especificaciones técnicas de los equipos armados en préstamo
• Justificación operativa y normativa
• Comparativo de alternativas descartadas
• Condiciones de entrega, trazabilidad y opción a compra

Esta documentación forma parte del archivo maestro del proyecto ECE y se entrega como constancia de la solución técnica propuesta, validada en campo, y rechazada sin fundamento técnico.

9. Justificación contable y salvedades operativas

Conforme a los principios de información financiera (NIF A-5 y A-7), se advierte que el proyecto ECE enfrenta una salvedad operativa por falta de infraestructura mínima. La ausencia de equipo funcional impide el cumplimiento de la trazabilidad clínica exigida por COFEPRIS y la NOM-024-SSA3-2012, lo que afecta directamente la viabilidad del sistema como parte del negocio en marcha.

Asimismo, se establece que:

• Los equipos actualmente disponibles no cumplen con los criterios de reconocimiento contable como activos funcionales (NIF C-6).
• El equipo personal utilizado por el prestador de servicio social no representa adquisición institucional ni activo hospitalario.
• La decisión de compra y asignación de equipo corresponde exclusivamente a los responsables administrativos, y cualquier falla futura deberá ser evaluada conforme a las condiciones aquí documentadas.

10. Trazabilidad fiscal y razón social del equipo

• Algunos colaboradores han indicado que “no importa quién sea el dueño de las computadoras”. Sin embargo, conforme a los criterios de COFEPRIS y la NOM-016-SSA3-2012, esto representa una violación directa de trazabilidad operativa.
• Fundamento normativo: La NOM-016-SSA3-2012, en su apartado 5.3.1, establece que el establecimiento debe contar con infraestructura informática propia o contratada formalmente, con evidencia documental de propiedad, mantenimiento y soporte.
• Esto implica que la razón social del equipo debe estar definida, registrada y vinculada al responsable sanitario. El uso de equipos personales, prestados o sin documentación fiscal válida rompe la cadena de responsabilidad técnica y legal, y puede invalidar el sistema ante una auditoría.
• La razón social del equipo utilizado en el ECE debe estar registrada y documentada conforme a la NOM-016-SSA3-2012. El uso de computadoras sin trazabilidad fiscal, sin contrato de cesión o sin factura válida representa una violación normativa que compromete la legalidad del sistema. No es un tema de conveniencia operativa, sino de cumplimiento sanitario. ES UNA FALTA MAYOR E INMEDIATA ANTE COFEPRIS.

INCONSISTENCIAS DE FARMACIA/DANIEL:

Durante la reunión sostenida el 10 sep a las 16:00 Daniel ha mostrado una postura agresiva en sus afirmaciones sobre el manejo del expediente clínico, la facturación SAT y el control de farmacia. Sin embargo, su desconocimiento de las normativas aplicables —incluyendo COFEPRIS, SAT y los lineamientos de trazabilidad clínica— es evidente en múltiples puntos:

• Pide que enfermeras que no usan el sistema, pero usen el módulo de caja. No es el único ejemplo de pedir una cosa y la contraria, por lo que un 60-70% de lo que pide es contradictorio y un 30-40% ilegal.
• No distingue entre un sistema de facturación multiclínica y un ECE normativo.
• No tiene idea de los requisitos de caja de un sistema de facturación.
• No tiene idea de los requisitos legales de una farmacia. (ver norma NOM-197-SSA1-2000 citada mas abajo parte 6.9.1)
• Desconoce la necesidad de vincular receta, paciente y factura con trazabilidad fiscal y sanitaria.
• Afirma tener un software llamado “Nombre del Software” instalado en cientos de farmacias, sin presentar evidencia técnica ni comercial verificable.

Además, ha declarado que no se requiere enfermera para ele ECE, en farmacia y que debe utilizarse una laptop para operar (por lo que se las enfermeras ven Farmacia). Esta afirmación contradice completamente la realidad operativa de farmacias hospitalarias, donde se requiere personal capacitado para validar recetas, entregar medicamentos y garantizar la trazabilidad clínica. En este caso, la operación propuesta que pide implementar  requeriría una enfermera con siete manos:

1. una para sostener la laptop que el considera indispensable
2. otra para escribir en la laptop mencionada y mover el mouse
3. una tercera para escanear el código de barras o QR
4. una cuarta para entregar el ticket
5. una quinta para recibir la firma del paciente (credenciales de descuento)
6. Una secta para sostener la impresora y 7
7. una séptima para entregar el medicamento

Esto no concuerda con los flujos reales de farmacias que operan con sistemas como SAE o similares, donde la infraestructura está diseñada para eficiencia y trazabilidad, no para improvisación.

La propuesta de impresión de tickets con código QR presenta múltiples inconsistencias:

• No queda claro quién define el contenido del QR ni qué datos contiene.
• No se especifica si el QR está vinculado a receta, paciente, medicamento o factura.
• Si se imprime en caja, se requeriría una impresora de tickets con capacidad QR en caja, y otra en farmacia para entregar el recibo firmado al paciente.
• Esto no concuerda con los sistemas de farmacia existentes ni con el flujo operativo real.

Además, debe recordarse que la normativa vigente establece restricciones claras para la instalación de equipo en farmacias hospitalarias, incluyendo la presencia de extintores, condiciones de seguridad, y espacio físico compatible con la operación clínica.

En este caso, la farmacia cuenta con un área de 1.5 × 1.5 metros, lo cual imposibilita la operación simultánea de laptop, lector de códigos, impresora de tickets y firma de paciente. Esta limitación no es una opinión personal: la normativa define que no puede haber laptop en farmacia sin condiciones específicas de seguridad y trazabilidad, conforme a lo establecido en los criterios

La NOM-197-SSA1-2000 sigue vigente y es la norma aplicable para infraestructura y equipamiento de hospitales y consultorios de atención médica especializada. En su sección 6.9.1 sobre Farmacia, establece requisitos mínimos que sí aplican directamente al caso. La norma de expediente electrónico y la menciona lo contradicen, no es una afirmación arbitraria.

Aquí está el fragmento normativo validado:

6.9.1 Farmacia: Se ubicará de preferencia en el vestíbulo principal del establecimiento y debe contar con:

• Área de mostrador para entrega
• Anaqueles para guarda de medicamentos
• Área de almacén para estiba
• Alacena con cerradura para productos controlados
• Sistema de refrigeración

Sin perjuicio de cumplir con otras disposiciones aplicables

Esto implica que cualquier intento de instalar equipo (como laptop, impresora, lector de códigos) debe respetar las condiciones físicas, de seguridad y trazabilidad que exige esta norma. En su caso, el área de 1.5 × 1.5 metros claramente no cumple con los requisitos mínimos, ni permite operación simultánea de los dispositivos propuestos.

Además, la frase “sin perjuicio de otras disposiciones aplicables” abre la puerta a aplicar también la NOM-241-SSA1-2021 (para buenas prácticas de dispositivos médicos) y la NOM-004-SSA3-2012 (para expediente clínico), si el equipo se usa para trazabilidad o prescripción. Incluso puede argumentarse NOM-016-SSA3-2012

6.7.1 Farmacia, cuando ofrezca servicio al público en general, se podrá ubicar en el vestíbulo principal del establecimiento.

6.7.1.1 Debe contar con un área de mostrador o ventanilla de despacho, anaqueles para acomodo de medicamentos, un área de almacén para estiba, mueble con cerradura para guarda de medicamentos controlados y un equipo de refrigeración, sin perjuicio de cumplir con las demás disposiciones aplicables.

6.7.1.2 De acuerdo con las características de organización y funcionamiento de la institución o tipo de establecimiento de que se trate, la farmacia puede formar parte de los servicios auxiliares de diagnóstico y tratamiento.

Lo documento en este espacio a petición de Daniel, como constancia técnica y deslinde operativo. La instalación de equipo en condiciones no compatibles expondría al hospital a observaciones regulatorias y riesgos operativos.

Sería muy claro para todos si Daniel pudiera demostrar, en nuestra farmacia y con el equipo actualmente disponible que él ya conoce, cómo se ejecutan de manera simultánea los seis pasos operativos que su propuesta requiere. Sin embargo, con base en experiencia directa en farmacias reales, en condiciones reales de operación, se concluye que lo que él plantea es materialmente inviable, además  de contrario a la normativa.

ENTREGABLES DANIEL

Requerimientos mínimos para avanzar en el módulo de farmacia

De acuerdo con lo conversado el día de ayer, y en seguimiento al punto anterior sobre infraestructura y hardware, se establece que para poder avanzar en el desarrollo del módulo de farmacia, se requiere la entrega inmediata de los siguientes cinco elementos por parte del Sr. Daniel:

1. a) Catálogo de medicamentos Se solicita el catálogo completo de medicamentos que Daniel tiene implementado en su sistema, con el objetivo de evitar duplicidad de captura por parte del personal hospitalario. Este insumo es indispensable para garantizar compatibilidad operativa y trazabilidad clínica.
2. b) Modelo de impresora de tickets y lector de QR Debe indicarse con precisión el modelo de impresora de tickets y el lector de códigos QR que se utilizan en las farmacias donde su sistema está instalado. Esta información permitirá al tesorero, Luis, realizar la cotización y gestionar la orden de compra correspondiente sin mi intervención. Sin esta especificación, no se puede garantizar la interoperabilidad del sistema.
3. c) Definición del flujo QR Se requiere una explicación clara y verificable sobre quién genera el código QR, quién lo escanea, y en qué momento del flujo operativo ocurre cada paso. Esta definición es crítica para evitar simulación tecnológica y garantizar trazabilidad fiscal y sanitaria.
4. d) Ejemplo impreso de QR funcional Solicitamos un ejemplo impreso de un código QR funcional, con el fin de verificar su legibilidad, estructura de datos, y destino (es decir, a qué dirección de internet conduce). Dado el alto nivel de saturación de errores en códigos QR mal diseñados, contar con un ejemplo real permitirá validar el diseño y replicarlo de forma segura.
5. e) Demostración operativa en farmacia Se solicita fecha y hora para realizar una demostración completa del proceso en farmacia, utilizando el equipo actualmente disponible y el flujo que Daniel propone. Esta demostración permitirá verificar la viabilidad física, técnica y normativa de su propuesta.

Nota adicional: Sería ideal que el lector de QR propuesto también pudiera leer el código de barras de las Credenciales de Descuento. En caso contrario, las Credenciales de Descuento requerirían su propio lector, lo cual complica aún más la operación. Si, como se ha afirmado, las enfermeras no utilizan computadoras, entonces no queda claro quién escanearía las Credenciales de Descuento ni cómo se integraría ese paso al flujo operativo.

Conclusión: Sin estos cinco entregables, no es posible avanzar en el desarrollo del módulo de farmacia. La responsabilidad de definir estos elementos recae directamente en el Sr. Daniel, quien ha afirmado conocer el sistema y su operación. En caso de no entregarlos, su propuesta quedaría expuesta como materialmente inviable.

ENTREGABLES CONTRADICTORIOS

En la tercera parte de la junta, ante las contradicciones observadas en las propuestas del Sr. Daniel, pregunté directamente qué se espera exactamente del sistema. El Dr. John Doe respondió que, si es necesario, se puede traer más personal. En lo personal, no lo recomiendo: no solo no tenemos computadoras ni convenios de confidencialidad, sino que el proyecto carece de una definición de alcance clara y de un plan de ejecución formal, por lo que la adición de personal en esta etapa no acelera el proceso, sino que aumenta el riesgo de errores y de costos inesperados.

Con base en lo definido hoy por el Dr. John Doe, Luis y Daniel se establece que el entregable esperado incluye seis módulos operativos para dentro de cinco días:

• Credenciales de Descuento
• Expediente Clínico Electrónico Básico (ECE)
• Control de recetas
• Control de farmacia
• Caja (mencionado por primera vez hoy)
• Citas médicas

Para simplificar la operación, considerando que conozco personalmente a 17 personas en el hospital, y que son seis módulos distintos, agradeceré que se me indique quién tendrá acceso a cada módulo. Esto permitirá revisar con cada usuario cómo realiza su proceso y asignarles usuarios y permisos adecuados.

Notas:

• No puedo hablar con los 12 especialistas porque, que yo sepa, hay cinco. Me espero a sacar esto y después veo cómo manejan su hoja de consulta.
• Como les dije, por tiempo hacer un entregable de enlace con el sistema LIMS del laboratorio clínico, no es urgente (hacen cuatro o cinco estudios al mes), pero no tienen computadora para manejarlo.

NOTAS POR AREA

Nuevamente, es necesario el convenio de confidencialidad, tanto para proteger los datos personales de pacientes como para delimitar responsabilidades en el manejo de información clínica, financiera y operativa. Sin este convenio, no se puede avanzar en la asignación de usuarios ni en la validación de procesos.

Credenciales de Descuento

• Requiere clientes, control de consumibles, contrato de adhesión, verificación de folios impresos y creación de catálogos.
• Solicito que se me proporcione el contrato de las credenciales vigente para revisión, así como los nombres de los clientes que ya estén utilizando el sistema.
• Es importante destacar que un paciente no es un cliente, y el tratamiento de datos personales es distinto en cada caso.

Implicación Contable de las Credenciales de Descuento

• ¿Cómo se van a registrar contablemente? Las credenciales son una promesa e implican consumo en varios aspectos: número de consultas, medicamentos, tiempo. Por tanto, no representan una venta, sino un pasivo. Es responsabilidad del contador del hospital documentar la forma de registro de los datos de consumo pasivo, porque una credencial es una obligación de servicio nominativa, no un ingreso inmediato. El SAT exige el cumplimiento del registro bajo el principio de prudencia contable.
• Las Credenciales de Descuento (en este contexto) son un pasivo, no un ingreso al momento del cobro. Si el hospital las registra como ingresos al momento de cobrarlas, estaría violando las Normas de Información Financiera (NIF), específicamente:
  • NIF A-6: Reconocimiento de operaciones con sustancia económica
  • NIF D-1 y D-2: Ingresos por contratos con clientes y presentación en estados financieros
  • NIF B-1 y B-6: Presentación de estados financieros y posición financiera
• Riesgo Fiscal y Contable Registrar Credenciales de Descuento como ingresos sin reconocer el pasivo correspondiente puede constituir simulación de ingresos, lo cual es un delito fiscal. El SAT puede sancionar por omisión, simulación o presentación incorrecta de estados financieros2.
• Definición de Proceso El contador del hospital debe definir cómo se registra el consumo de este pasivo. Yo puedo indicar que se ha consumido o que se va a renovar, pero la obligación contable, mercantil y fiscal subsiste para los estados financieros. Esa información debe extraerse del sistema, porque si no aparece en el Balance General Anual, es causal de sanción.
• Responsabilidad del contador Corresponde al contador integrar el balance general con este rubro. Yo puedo hacer una aproximación por NIF, considerando las variables a mi alcance, pero por naturaleza será solamente una APROXIMACIÓN O ESTIMADO, no un dato firme.

Expediente Clínico Electrónico Básico (ECE)

• El módulo está prácticamente listo, solo requiere ajustes menores.
• No se han definido los formatos clínicos por especialidad, y no se cuenta con los 11 especialistas que justificarían dicha segmentación. Hasta donde sé, hay cinco.

Control de recetas

• Las recetas deben escanearse para tener valor probatorio, y deben entregarse físicamente en farmacia.
• Entregar medicamentos sin receta física representa un problema normativo.
• Consultaré las recetas de los últimos cinco meses y trabajaré en solicitar nombre completo, cédula y especialidad de cada médico.
• Me adapto a las recetas impresas existentes, pero una receta impresa solo tiene valor con la firma del médico.
• Nota: Se deben definir los errores normativos observados en las recetas del Dr. Equis.

Control de farmacia

• No puedo iniciar sin los entregables de Daniel.
• Asumo que se refiere al inventario, no a compras. Inventario y resurtido son procesos distintos.
• Un control de compras bien hecho, conforme a normativa COFEPRIS, requiere más de seis meses y acceso completo a XML emitidos y recibidos, además de catálogos contables, facturas, cotizaciones y órdenes de compra.
• Puedo emitir un aviso por inventario perpetuo, pero el control de compras es responsabilidad de ustedes.
• Me pidieron controlar el uso de ampolletas al abrir una caja, así como los kits de quirófano y lo que utiliza la instrumentista. Ella necesita computadora, y deben indicarme qué contiene cada kit.
• El uso de medicamentos requiere firma, que debe ser autógrafa y escaneada o fotografiada para trazabilidad.

Caja

• Mencionado por primera vez hoy. 10 de septiembre.
• Se solicita que las chicas del primer piso (Asumo que Berenice y Graciela) registren el cobro a clientes.
• Esto implica que sí se requiere computadora, lo cual contradice lo dicho por Daniel y el tesorero Luis (“las enfermeras no necesitan computadora”).
• Recibir dinero y registrarlo implica emisión automática de CFDI, mecanismos de devolución, y cumplimiento del artículo 29 y 29-A del Código Fiscal de la Federación.
• Si el pago es en efectivo o por transferencia electrónica, se requiere infraestructura adicional.
• Puedo implementar un control de dinero recibido, pero un sistema de punto de venta requiere equipo que no tienen, y una normativa completamente distinta que debe estar ligada a los productos facturados al paciente.
• No se puede vender a clientes que no sean pacientes, excepto en el caso de Credenciales de Descuento.
• Lo que mencioné anteriormente —lectores de códigos, terminales bancarias, reportes por cajero, comparativas de desviación, estadísticas— no puede ejecutarse sin infraestructura.
• Además, una aplicación web no puede abrir un cajón de dinero, lo cual expone al hospital a riesgos normativos en múltiples frentes.

Adicionalmente:

• Un sistema de caja como el que se describe puede hacerse, pero no es de facturación. Los controles de facturación CFDI y manejo de firmas digitales son un sistema cinco o seis veces más grande que un ECE. Requieren:
  • Actualización constante por cambios del SAT
  • Cambios de formatos
  • Capacitación formal a las enfermeras en requisitos de factura electrónica
  • Costo por timbre (actualmente consigo en $1.50)
  • Un costo mensual de iguala, por mantenimiento, timbrado, soporte y actualizaciones
  • Acceso directo al portal del SAT para validar qué facturas se han emitido, cancelado o rechazado
• Si se van a manejar pagos, se manejan pagos de adeudos también, lo cual implica llevar contabilidad de deudores diversos (cliente y paciente). Una enfermera no puede hacer esto sin llevar un saldo, y si no se lleva ese control, no sirve de nada en el contexto hospitalario, porque tendríamos operaciones que no se registran, lo cual constituye una falta grave ante SAT y COFEPRIS.
• Mi consejo es no hacer módulo de caja. Simplemente, el costo normativo, de equipo, de capacitación, y el hecho de que una caja que no facture es delito, hacen inviable esta propuesta. Como referencia, puedo desarrollar un sistema de facturación electrónica, pero tendría un costo mensual de iguala, costo de timbrado, y requeriría que la caja esté ligada al cliente y sus saldos. Tener una caja en un hospital que no liga al cliente es una violación completa a todas las normas contables y sanitarias.

⚖️ Normas que se violarían si se implementa un módulo de caja sin facturación, sin saldos, y sin vínculo al paciente:

SAT – Código Fiscal de la Federación

• Art. 29 y 29-A: Obligación de emitir CFDI por cada ingreso.
• Art. 83 y 84: Sanciones por omisión de registros contables o documentación falsa.
• Art. 111: Delitos fiscales por simulación de operaciones.

NIF – Normas de Información Financiera

• NIF A-6: Reconocimiento de operaciones con sustancia económica.
• NIF C-1: Registro de efectivo y equivalentes con trazabilidad y vínculo a entidad identificable.
• NIF D-1 y D-2: Ingresos por contratos con clientes y presentación de ingresos en estados financieros.

COFEPRIS – Normas Sanitarias

• NOM-004-SSA3-2012: Expediente clínico debe vincularse a atención médica y medicamentos.
• NOM-241-SSA1-2021: Buenas prácticas de fabricación y trazabilidad de insumos médicos.
• Ley General de Salud, Art. 416 y 417: Sanciones por incumplimiento normativo, incluyendo multas, clausura y arresto.

Nota final: En caso de que se insista en desarrollar un módulo de caja sin facturación, sin saldos, y sin vínculo directo al paciente, se recomienda verificar previamente con su contador para que firme un disclaimer fiscal, deslindando responsabilidades ante el SAT. Asimismo, se sugiere consultar al responsable sanitario para emitir un disclaimer de cumplimiento normativo ante COFEPRIS, dado que este tipo de operación puede violar los principios de trazabilidad clínica y contable establecidos en las normas oficiales mexicanas y en las NIF.

Apéndice – Software «nombre del software»

Durante la verificación técnica hace unos meses con una farmacia en Guadalajara para EQUIS, empresa del ramo médico, tuve una primer experiencia previa con el software Centroamericano NOMBRE DEL SOFTWARE. Actualicé y verifiqué hoy 10 de septiembre esta verificación me permitió corroborar que no existe software comercial de farmacias con ese nombre en el mercado mexicano.

La investigación reveló la existencia de diez a doce software similares llamados «NOMBRE DEL SOFTWARE» en diferentes países (Nicaragua, Colombia, España, Argentina, Perú, México), cada uno operando bajo diferentes marcos legales y normativos específicos de sus respectivas jurisdicciones.

Observaciones técnicas relevantes:

• Daniel demuestra desconocimiento de la normativa mexicana en tres áreas críticas: SAT, COFEPRIS y Expediente Electrónico
• Sus afirmaciones sobre operaciones farmacéuticas no coinciden con la realidad técnica del mercado
• El software NOMBRE DEL SOFTWARE en caso de existir comercialmente para farmacias en México, no opera vía internet según los estándares técnicos verificados
• Es altamente improbable que esté instalado en «cientos de farmacias» como se afirma, considerando la ausencia de evidencia comercial verificable

Conclusión: Las afirmaciones sobre el manejo operativo del software NOMBRE DEL SOFTWARE en el contexto farmacéutico mexicano carecen de sustento técnico y normativo verificable.

Este documento forma parte del archivo técnico del proyecto ECE y se entrega como constancia operativa ante decisiones institucionales que afectan la viabilidad del sistema.

1. DESLINDE DE RESPONSABILIDAD SOBRE HARDWARE

• Fecha: 11 de septiembre de 2025 por: X Dirigido a: Dirección / Tesorería.
• El día 10 de septiembre, los señores Luis el tesorero y Daniel invalidaron completamente lo acordado previamente con el Dr. John Doe respecto al plan de computadoras en préstamo. Daniel solicitó específicamente los requisitos técnicos de hardware para realizar la compra por su cuenta. Ambos expresaron que no desean que yo intervenga en el proceso de adquisición. Por petición expresa de Luis y Daniel, se entregan los siguientes requisitos mínimos de PC para USUARIO FINAL:

2. REQUISITOS ENTREGADOS POR SOLICITUD DIRECTA

• Daniel: Solicita laptops y afirma que él las comprará si se le entregan especificaciones. Luis: Solicita exclusivamente equipos All-in-One, incluyendo laptops con 4 GB de RAM que ya fueron descartadas por tres técnicos. Ambos: Rechazan el equipo armado previamente validado y entregado en préstamo. Rechazan la instalación de equipo en terminal de enfermería y quieren farmacia, a pesar de que la normativa lo prohibe por condiciones de espacio, seguridad y trazabilidad. Dr. Equis, Luis y Daniel: Afirman que las enfermeras no necesitan computadoras, lo cual contradice la NOM-024-SSA3-2012.
• Para evitar conflicto de intereses y simulación operativa, se establece lo siguiente:
• Si la elección y compra del hardware es responsabilidad exclusiva de Luis y Daniel, yo no tengo autoridad para sugerir compra, ni responsabilidad sobre fallas futuras. La viabilidad del proyecto ECE depende de contar con computadoras que cumplan los requisitos técnicos. Es posible que realice cotizaciones de recuperación de equipo antiguo.

En agosto 2025 intenté implementar un ECE en un hospital sin computadoras funcionales.

Ante la falta de infraestructura mínima (ni una computadora funcional), el proyecto fue inviable. Sin embargo, generé una serie de documentos técnicos que pueden servir como referencia para estudiantes, auditores o consultores enfrentando condiciones similares.

Comentario técnico: Tengo la impresión de que el doctor en cuestión interpreta erróneamente el artículo 32 del Reglamento de Insumos para la Salud, pensando solamente el contexto de hospitales públicos. Lo dicho por él carece de sentido en un hospital privado, y la norma permite incluso en hospitales públicos lo que él parece desconocer. Basta con leer el texto completo para entenderlo.

ARTÍCULO 32. La prescripción en las instituciones públicas se ajustará a lo que en cada una de ellas se señale, debiéndose utilizar en todos los casos únicamente las denominaciones genéricas de los medicamentos incluidos en el Cuadro Básico de Insumos para el primer nivel o en el Catálogo de Insumos para el segundo y tercer nivel. Por excepción, y con la autorización que corresponda, podrán prescribirse otros medicamentos.

Documento Técnico: Observación sobre Riesgos en Prescripción Médica y Trazabilidad Farmacológica

Autor:

Fecha: 10 sep 2025

Destinatarios: Direccion del hospital.

Base: Peticiones contra la norma COFEPRIS por parte de Dr. Equis (COFEPRIS) en recetas medicas.

1. Contexto de la observación

Durante la junta institucional celebrada a las 16:00 horas del día de hoy, se me solicitaron dos acciones que, en mi criterio técnico y normativo, violan directamente la legislación vigente en materia de prescripción médica y trazabilidad farmacológica.

Uno de los puntos fue planteado por el Dr. Equis, quien afirmó que la ley prohíbe incluir el nombre comercial del medicamento en la receta médica, y que únicamente debe anotarse el nombre genérico o principio activo. Según su declaración, incluir el nombre comercial sería una violación normativa e incluso ilegal.

Esta afirmación, aunque expresada como resultado de trabajo previo, no fue acompañada de fundamento legal específico. Tras revisión normativa, se confirma que no existe tal prohibición en la legislación vigente, y que el uso del nombre comercial está permitido cuando sea necesario para garantizar la eficacia terapéutica y la trazabilidad del tratamiento.

2. Aclaración normativa

Las normas que regulan la prescripción médica y la trazabilidad farmacológica son:

• Ley General de Salud, artículos 226 y 227
• Reglamento de Insumos para la Salud, artículos 28 y 29
• NOM-004-SSA3-2012 (expediente clínico)
• NOM-220-SSA1-2016 (farmacovigilancia)

En ninguna de estas disposiciones se prohíbe el uso del nombre comercial. Por el contrario, se reconoce que el médico puede incluirlo cuando lo considere necesario para garantizar la eficacia terapéutica, la seguridad del paciente y la trazabilidad del tratamiento.

3. Riesgos clínicos y trazabilidad por omitir el nombre comercial

Aunque no soy médico, como auditor técnico tengo la obligación de señalar que existen al menos tres casos clínicos claros que tengo presentes en los que prescribir únicamente el principio activo, sin especificar la marca comercial, puede tener consecuencias graves para el paciente y para la institución. La trazabilidad farmacológica no es un trámite administrativo. Es una exigencia clínica, legal y ética. Omitir el nombre comercial en medicamentos críticos puede derivar en eventos adversos, observaciones regulatorias y responsabilidad directa para el hospital. Documentar esta situación es parte de mi deber técnico y normativo.

Los siguientes ejemplos provienen de mi experiencia directa en entornos hospitalarios auditados por COFEPRIS. Los menciono como referencia técnica, pero deben ser verificados por un médico especialista, ya que corresponden a observaciones operativas y no a diagnóstico clínico:

1. a) Carbamazepina (para convulsiones y epilepsia entre otros)

• Formulaciones: liberación inmediata vs. prolongada.
• Riesgo: desestabilización neurológica si se cambia de marca sin control, incluso con la misma vía y dosificación.

1. b) Levotiroxina sódica (hipotiroidismo, frio, niebla mental) pero con contraindicaciones y salvedades

• Ventana terapéutica estrecha.
• Riesgo: variaciones entre fabricantes pueden alterar la biodisponibilidad y provocar síntomas por exceso o defecto hormonal.

1. c) Metamizol sódico (dipirona) (analgésico y antipirético)

• Variabilidad entre marcas en absorción y excipientes.
• Riesgo: percepción de ineficacia, duplicación de dosis, alteración del control del dolor.

En todos estos casos, se observan conflictos clínicos incluso cuando se mantiene el mismo principio activo, vía y dosificación, lo que demuestra que la marca comercial no es un accesorio, sino un componente trazable del tratamiento.

4. Responsabilidad institucional

Como consultor técnico, estoy obligado a: 1 ) Documentar cualquier instrucción que contradiga la normativa vigente. 2 ) Proteger la trazabilidad legal y clínica de los procesos institucionales. 3 ) Reportar cualquier práctica que exponga al hospital a riesgo sanitario o fiscal.

No eliminaré la opción de incluir el nombre comercial en los formatos de receta, ya que hacerlo sería una omisión deliberada que vulnera la norma vigente. Si el hospital o el médico deciden no usarlo, la responsabilidad recae en ellos, no en mí.

5. Solicitud formal

En caso de haberlo, Solicito que se me proporcione por escrito el fundamento legal específico que respalde la afirmación de que es ilegal incluir el nombre comercial en la receta médica. Este documento será necesario para justificar cualquier cambio ante COFEPRIS y para proteger la trazabilidad de mis entregables.

6. Disclaimer técnico

Los ejemplos clínicos mencionados en este documento provienen de mi experiencia operativa en entornos regulados por COFEPRIS. No constituyen diagnóstico médico ni sustituyen la evaluación de un especialista. Se presentan como indicadores técnicos de riesgo, y deben ser corroborados por personal médico autorizado. Mi función como auditor es señalar inconsistencias normativas y operativas, no emitir juicios clínicos.

En agosto 2025 intenté implementar un ECE en un hospital sin computadoras funcionales.

Ante la falta de infraestructura mínima (ni una computadora funcional), el proyecto fue inviable. Sin embargo, generé una serie de documentos técnicos que pueden servir como referencia para estudiantes, auditores o consultores enfrentando condiciones similares.

Contexto: Me pidieron revisar un chatbot para cerrar ventas, pero no tenían equipo mínimo. Muchas palabras bonitas, pero les comenté que el rango medio de un chatbot básico es de 10 a 40 mil, y que uno que cierre ventas es mas caro. Les dije que mi contacto si podía hacerlo por 120 mil. 30 Servidor, 40 de anticipo. A le le dije que si le hablaban no trabajara sin anticipo.

Nota: Este es el unico caso real que creo que ODOO puede ser util, pero por lo general a los que me piden una opinión les digo que ODOO como tal es igual de razonable que chocar su coche para no pagar gasolina.

Notas sobre Inteligencia Artificial Predictiva al 9 de septiembre 2025

Contexto: Me preguntaron acerca de un sistema de inteligencia artificial predictiva y operacional para el contexto del Hospital.

Tengo idea pero no me da tiempo de desarrollar lo que necesitan en poco tiempo; se suele cobrar el uso por tokens y eso es largo de explicar. Para una respuesta rápida, conozco un contacto, un profesional, les mando un demo y sus datos de contacto pero creo que él usa como software ERP para manejar los productos, que es necesario por ese tipo de software, un software libre llamado ODOO que tiene sus propios problemas. Sin embargo él es un profesional, con mucha experiencia adicional en Marketing Digital, pero al mismo tiempo no creo que IA predictiva sea adecuada.

En lugar de enfocarnos en la Inteligencia Artificial predictiva —que es compleja y no es la mejor solución para un entorno de este tamaño— la IA de Odoo está perfectamente alineada con la gestión comercial y la automatización de ventas que el hospital realmente necesita. Se enfoca en la captura de leads comerciales, la generación de tickets de soporte y la automatización de la comunicación para las ventas de membresías. Este enfoque no solo satisface su interés por la IA, sino que también utiliza la plataforma de manera eficiente y segura para lo que fue diseñada, sin poner en riesgo los datos clínicos de los pacientes.

Contacto *****

Link de Video *****

En lo personal, no creo que necesiten Inteligencia artificial predictiva por tres razones:

1. Estamos hablando de un hospital de 8 a 20 camas y no hay mucho que predecir, en todo caso un dashboard automatizado
2. Usar software predictivo, donde hay vida humana, puede llevar a complicaciones legales, por casos de urgencia y mala praxis y condiciones de membresía. Sirve para marketing y nada más.
3. Incompatibilidad con Normatividad Médica: Es inviable que un software de IA o un ERP comercial obtenga la certificación SIRES para el manejo de pacientes. Los datos de salud (Expediente Clínico Electrónico) y los datos comerciales (marketing, membresías, etc.) deben mantenerse en entornos completamente separados para cumplir con las regulaciones de la NOM-004-SSA3 y de COFEPRIS.

ODOO / ERP / LLM y cualquier dato de inteligencia artificial debe estar en un entorno diferente a donde están los pacientes, manejando exclusivamente el contacto de venta o lead, y las categorías de sus productos. Si no es un problema de privacidad de datos y de COFEPRIS.

Una vez entendido esto, ODOO o cualquier IA es una solución que no considero válida para un entorno de trabajo hospitalario que no sea el chat de cierre de ventas por las siguientes razones:

• Problema de garantías: Los partners o consultores abandonan los proyectos frecuentemente porque el negocio real es de IA/ODOO/el proveedor, no de ellos. He visto consultores buenos y con recursos que han dejado de trabajar con IA/ODOO, porque el esquema de ellos es cobro por horas, que es como justifican los Tokens usados. Literalmente es complicado calcular costos de tokens, o del uso de la IA, por eso comento que a futuro puedo hacer algo yo pero no da tiempo y de momento Carlos es la única opción que conozco, considerando esta limitación.
• Costos ocultos que explotan: El hospedaje IA parece barato hasta que necesitas cambios. Usando algo más que la IA Te cobran revisión por línea de código/tokens y sale carísimo. Si te adaptas al software, bien, pero cualquier customización cuesta una fortuna.
• Costos impredecibles por tokens: De igual manera, los servicios de IA cobran por consumo de «tokens», lo cual hace imposible estimar el gasto mensual. Es una bomba de tiempo financiera y por eso no aconsejo usar tarjeta de crédito que luego es casi imposible de cancelar.
  1. LES SUGIERO QUE CUALQUIER PAGO DE IA SE HAGA POR CHEQUE O TRANSFERENCIA ELECTRÓNICA, JAMÁS POR TARJETA DE CRÉDITO, POR PROBLEMAS SERIOS DE COBROS AUTOMÁTICOS.
• Cambios de versión sin compatibilidad: Los motores de IA hacen actualizaciones constantemente que no son compatibles entre versiones. El mecanismo es que no se hacen responsables del software community y «mejoran» a nueva versión para que pierdas garantía y tengas que contratar actualización. Y en el caso de las IA no están capacitadas para derecho o entorno médico, son un chat de ventas glorificado.
• No hay responsabilidad legal real: Los motores de IA se limpian las manos en cosas de medicina, cambiando el modelo y muchos ERP y modelos LLM se limpian de responsabilidades al cambiar versiones (eso lo hacen por cambios contables). Para fines prácticos toda garantía queda inválida casi de inmediato. Inclusive hay casos donde cambiaron de versión community para no responder demandas.
  • Lo veo como algo que no va a tener un Retorno de Inversión real medible, y que por eso deben hacer pago con cheque o transferencia, nunca por tarjeta.
• Consultores sin experiencia real: En cuanto a IA Lo que contratas son capturistas que cargan datos, no gente de sistemas. No encuentras personal con experiencia real en IA ODOO en bolsas de trabajo, y literalmente soluciones híbridas como Carlos son lo mejor. Se puede desarrollar interno (in house) algo, pero sale del alcance del servicio social y del tiempo disponible.

Disclaimer: De manera específica, ODOO es un buen software comercial, pero no lo recomiendo para el entorno hospitalario real debido a temas de compliance y separación de universos legales. Puede ser útil exclusivamente para marketing y gestión comercial. Adicionalmente, el hardware y configuraciones de los usuarios internos del hospital no sería compatible con ODOO, pero el hardware de los clientes/pacientes para interacciones comerciales sí podría serlo.

Recomendación Final: Si el Hospital insiste en implementar un sistema de inteligencia artificial, mi recomendación es que se limite exclusivamente al área comercial, como inventarios, citas y marketing, y que sea completamente separado de la gestión del expediente clínico electrónico y de los datos de los pacientes.

El análisis de viabilidad de sistemas de IA predictiva está alineado con la gestión de riesgos operativos y el cumplimiento normativo de la operación hospitalaria, enfocándose en la continuidad del negocio y no en aspectos de contabilidad financiera o marcos NIF/NIIF.»

En agosto 2025 intenté implementar un ECE en un hospital sin computadoras funcionales.

Ante la falta de infraestructura mínima (ni una computadora funcional), el proyecto fue inviable. Sin embargo, generé una serie de documentos técnicos que pueden servir como referencia para estudiantes, auditores o consultores enfrentando condiciones similares.

Este documento se entregó impreso a la a asistente del director, con un watermark rojo que decía «DESCARTADO POR DANIEL/LUIS”. A pesar de ello, se presentó formalmente como parte del proyecto de Expediente Clínico Electrónico (ECE). El contenido técnico se mantiene íntegro para fines de referencia y trazabilidad.

Incluso ya estaba funcionando la primera de las computadoras y la retiré el mismo día. Todo fue una autorización verbal del dueño con la asistente, Luis y yo y de repente Daniel sale que tienen que ser Laptops y que el las compra. Eso va a en documento aparte.

Los nombres y entidades específicas han sido anonimizados para proteger la privacidad institucional. Las referencias operativas se mantienen para fines técnicos y de trazabilidad.

9 sep Cotizacion de Equipo para ECE

Asunto: Cotización de Computadoras en Préstamo para Expediente Clínico Electrónico

Dirigido a: Dr. Equis Fecha: 9 de septiembre de 2025

1. Computadoras Armadas en Préstamo (30 días con opción a compra)

Justificación: Actualmente, no se cuenta con computadoras funcionales para el personal de enfermería, lo que es un impedimento para la implementación del proyecto de Expediente Clínico Electrónico programado para el 15 de septiembre. Por ello, se propone el uso temporal de equipos de cómputo que se adapten a las necesidades del proyecto.

Análisis y Descarte de Alternativas: Para llegar a la mejor solución, se evaluaron diversas opciones:

• a) Compra de All-in-One Lenovo (Walmart): Esta opción fue descartada debido a su alto costo ($5,700 MXN), el poco espacio de almacenamiento, la memoria limitada y su obsolescencia prevista en 2-3 años.
• b) Compra de laptops de gama baja: Se desestimó esta alternativa por el riesgo de robo, la limitada capacidad de disco duro y la experiencia previa con laptops inservibles y cargadores extraviados. La seguridad es una prioridad, y COFEPRIS valora la integridad de los datos.
• c) Computadoras de escritorio reconstruidas Dell: Se descartaron por la incertidumbre de su origen, sus componentes reconstruidos o de segunda mano, gabinetes no reutilizables y el uso de discos mecánicos, que son más lentos y propensos a fallas.
• d) Computadoras armadas con componentes de segunda mano: Aunque el precio es bajo ($3,000-$5,000 MXN), esta alternativa exige el pago inmediato y la calidad de los componentes es incierta.

Propuesta y Condiciones: Se propone el préstamo de computadoras armadas con componentes de primera calidad y de poco uso. Estas computadoras ofrecen una excelente relación calidad-precio y son reutilizables a largo plazo.

El precio estimado por equipo es de $4,200 – $5,200 MXN (IVA incluido). El costo aproximado por tres máquinas es de $13,600 MXN, mientras que por cuatro máquinas es de $17,800 MXN.

• Nota sobre rendimiento: Las memorias RAM y los discos SSD de estos equipos son de alta velocidad, lo que garantiza un rendimiento óptimo y un arranque y procesamiento de datos mucho más rápido en comparación con los discos mecánicos de la mayoría de las alternativas.
• Se sugiere adquirir tres equipos para el personal de enfermería (primer, segundo y tercer piso) y una unidad adicional para un servidor, recepcionista o para PROYECTO S.
• Condiciones del préstamo: En caso de no concretarse la compra, los equipos se retirarán en un plazo de 30 días naturales a partir de la fecha de entrega de la última unidad. Se emitirá la factura correspondiente previo al pago.

2. Especificaciones Técnicas de los Equipos

A continuación, se detalla una tabla con las características de los equipos que se pondrán a prueba para el proyecto:

Análisis Estratégico del Gabinete DeepCool CG530 4F (para CPU #3): Esta opción ha sido seleccionada por su alineación con los objetivos de funcionalidad y defensa institucional:

• Diseño funcional: El formato Mid Tower de doble cámara mejora el flujo de aire y la organización interna, crucial para un rendimiento constante.
• Trazabilidad y evidencia: Sus paneles de vidrio templado permiten la inspección visual de los componentes, facilitando la evidencia fotográfica que podría ser requerida por autoridades como COFEPRIS.
• Capacidad de almacenamiento: Cuenta con bahías para hasta tres discos duros, lo que permite configurar un sistema de respaldo de datos robusto y confiable, esencial para la seguridad del expediente clínico.
• Ventilación avanzada: Con cuatro ventiladores incluidos y soporte para más, garantiza un ambiente térmico ideal para operar como servidor temporal sin riesgo de sobrecalentamiento.

Nota adicional: Los equipos se revisarán entre el 10 y el 12 de septiembre. Las especificaciones finales podrían cambiar, ya que solo contamos físicamente con la computadora número uno, la cual ya está en funcionamiento en el hospital.

Nota de Trazabilidad Técnica: Cada equipo será entregado con ficha técnica, número de serie, evidencia fotográfica y minuta de recepción. Esta documentación forma parte del archivo maestro de servicio social y garantiza la trazabilidad operativa y fiscal.

3. Tarjeta de Red Externa AC 1300 Nano Wireless

Justificación: La red cableada del hospital no cubre los requisitos del Expediente Clínico Electrónico, ya que no tiene memoria técnica ni control de IPs, lo que podría afectar el correcto funcionamiento del sistema. Para asegurar una conectividad estable y confiable, es necesario que cada equipo se conecte a la red Wi-Fi.

• Ventaja clave: Las tarjetas de red propuestas son de alta velocidad. Se ha medido en el equipo ya instalado un rendimiento de 185.89 Mbps de bajada y 19 Mbps de subida, superando el rendimiento de casi todos los equipos y laptops que se revisan actualmente, que son 15 veces más lentos.

Propuesta y Costo: Se propone la adquisición de una tarjeta de red externa AC 1300 Nano Wireless para cada computadora y una adicional para el equipo que se está revisando.

El costo estimado por cada tarjeta es de $300 – $350 MXN (IVA incluido).

4. Cargadores para Laptops

Justificación: Se tienen disponibles cargadores para las laptops y equipos que no pueden usarse por carecer de uno. Se propone adquirir al menos dos cargadores para la Lenovo All-in-One LENOVO de proyecto S, con el fin de tener uno de respaldo debido a la importancia del software.

Propuesta y Costo: Se propone la compra de cargadores para laptops y equipos LENOVO, disponibles de un proveedor.

El costo por cada cargador es de $350 MXN. Cabe aclarar que, al tratarse de equipos descontinuados, no se cuenta con factura para estos artículos.

5. Condiciones de Compra

En caso de concretarse la compra, se emitirá un CFDI único, que incluirá el desglose técnico, evidencia de funcionalidad y una garantía limitada de 30 días en el hardware. La entrega se formalizará mediante una fotografía firmada por el usuario y el responsable del área, y el pago se realizará conforme al Complemento de Pago CFDI exigido por la ley.

6. Resumen de Costos Estimados

A continuación, se presenta un resumen del costo total estimado, incluyendo todos los artículos propuestos, en función de la cantidad de computadoras:

• Opción de 3 computadoras: $15,500 – $15,700 MXN
• Opción de 4 computadoras: $20,000 – $20,250 MXN

Nota: Estos montos son un estimado y pueden variar ligeramente dependiendo de las especificaciones finales y la cantidad exacta de equipos adquiridos.

En agosto 2025 intenté implementar un ECE en un hospital sin computadoras funcionales.

Ante la falta de infraestructura mínima (ni una computadora funcional), el proyecto fue inviable. Sin embargo, generé una serie de documentos técnicos que pueden servir como referencia para estudiantes, auditores o consultores enfrentando condiciones similares.

Este documento es borrador.  No lo entregué pero toma fragmentos que eran relevantes de informes de realidades contable de otros proyectos de control de riesgos. por eso puede cambiar un poco el formato ente ellos.

En agosto 2025 intenté implementar un ECE en un hospital sin computadoras funcionales.

Ante la falta de infraestructura mínima (ni una computadora funcional), el proyecto fue inviable. Sin embargo, generé una serie de documentos técnicos que pueden servir como referencia para estudiantes, auditores o consultores enfrentando condiciones similares.

Este documento no lo entregué pero es estándar cuando hago evaluación de riesgos, lo pongo por si le sivre a a laguien

Privado: Notas sobre conductores designados:
Por admin / 5 septiembre, 2025
Escenarios reales:

Coche de alta gama, chocado por el hijo del dueño.
En el caso de una gasera, conductor ocasional toma una pipa y va por una cinta métrica a la tlalpaleria y lo chocan.. pero da positivo al alcoholímetro.
Para un hospital privado, es una práctica recomendada y, en muchos casos, una obligación legal, llevar un registro detallado de los conductores permitidos para los vehículos de la institución. Este registro es crucial por varias razones, que incluyen la seguridad, la responsabilidad legal y la gestión eficiente de los recursos.

Aquí se detallan los elementos clave que un registro de este tipo debería incluir:

Identificación del Conductor: Nombre completo, número de empleado, y un identificador único.
Identificación del Vehículo: Marca, modelo, año, tarjeta de circulación , numero de motor, número de placa y cualquier otro dato relevante del vehículo que se le asigne al conductor.
Vigencia de Licencia de Conducir: Fecha de expedición y, lo más importante, la fecha de vencimiento. Esto asegura que el personal autorizado siempre posea un documento válido para conducir legalmente.
Tipo de Licencia: Se debe especificar si la licencia es para vehículos particulares, de carga, de pasajeros, etc., asegurando que el conductor esté debidamente calificado para el tipo de vehículo que se le asigna.
Verificación de Antecedentes: Es una práctica recomendable verificar el historial de conducción del empleado, incluyendo multas, accidentes y cualquier otra infracción, esto lo debe hacer el gestor que ver las verificaciones vehiculares.
Capacitación: Registro de cualquier capacitación especial recibida por el conductor, como manejo defensivo, manejo de vehículos de emergencia, etc.
Seguro y Póliza: Confirmación de que el conductor está cubierto por la póliza de seguro del hospital para el vehículo en cuestión.
Responsiva del Vehículo: Documento firmado por el empleado donde se le hace responsable del uso, cuidado y mantenimiento del vehículo mientras esté a su cargo. Esto delimita las responsabilidades en caso de daños o uso indebido.
¿Por qué es esto importante?

Responsabilidad Legal: En caso de un accidente, si el conductor no está debidamente autorizado o su licencia ha expirado, el hospital podría enfrentar serias consecuencias legales, incluyendo demandas y sanciones por parte de las autoridades.
Seguridad: Un registro actualizado y verificado reduce el riesgo de accidentes al asegurar que solo personal calificado y con licencia válida maneje los vehículos del hospital.
Aseguradoras: Las compañías de seguros suelen exigir que las empresas mantengan registros detallados de sus conductores para que las pólizas sean válidas en caso de siniestro.
Control y Eficiencia: Permite un mejor control sobre el uso de los vehículos, evitando el uso no autorizado y facilitando la gestión de la flota.
En resumen, sí, es fundamental que un hospital privado, o cualquier empresa que posea una flota de vehículos, mantenga un registro de conductores permitidos, incluyendo la vigencia de su licencia y un documento de responsiva. Esto no solo es una cuestión de cumplimiento legal, sino también una práctica de gestión de riesgos esencial para la protección de la institución y de sus empleados.

El primer escenario que describe, donde un vehículo de alta gama de la empresa es utilizado ocasionalmente por un familiar del dueño, es un punto crítico que requiere una gestión muy cuidadosa. La sugerencia de asignarlo al área de Relaciones Públicas y tener a una persona designada como conductor permitido, aunque no tenga un puesto definido, es una excelente manera de formalizar la situación y mitigar los riesgos.

Razonamiento de por qué la propuesta es sólida y los elementos que se deben considerar para su implementación:

1. Racionalización y Justificación de la Asignación

Imagen Corporativa y Relaciones Públicas: Un vehículo de alta gama es un activo que proyecta una imagen de éxito y solidez. Asignarlo a Relaciones Públicas justifica su uso como herramienta para eventos, transporte de personalidades importantes (inversionistas, socios, médicos invitados) o como vehículo de representación. Esto le da un propósito legítimo dentro de la estructura empresarial.
Asignación de “Conductor Designado”: Esta es la clave. La persona asignada como “conductor permitido” o “encargado del vehículo” se convierte en el eslabón formal entre la empresa y el vehículo. Aunque su puesto no esté directamente relacionado con la conducción, esta asignación le otorga la responsabilidad y las obligaciones legales.
2. Elementos Críticos a Formalizar

Para que esta propuesta funcione de manera efectiva y sin riesgos, es indispensable documentar y formalizar varios aspectos:

Carta Responsiva (o Resguardo): Este documento es fundamental. Debe ser firmado por la persona designada y detallar las responsabilidades sobre el vehículo, incluyendo:
Mantener la unidad en buenas condiciones (limpieza, mantenimiento).
Responder por cualquier daño o multa generada.
No permitir que el vehículo sea conducido por personas no autorizadas.
Informar de inmediato a la empresa sobre cualquier accidente, robo o daño.
Políticas de Uso: La empresa debe tener una política clara sobre el uso de vehículos corporativos, incluso si son para fines “personales” o fuera del horario laboral. En este caso, la política debería especificar que el vehículo, aunque esté asignado a una persona, se destina a fines de representación y que su uso por terceros debe ser ocasional y con autorización expresa del conductor asignado y/o de la dirección.
Contrato de Comodato o Similar: Dependiendo del nivel de formalidad que se quiera dar, se podría considerar un contrato de comodato o un acuerdo de uso, donde se establecen las condiciones en las que el conductor asignado puede permitir el uso del vehículo a terceros, como el hijo del dueño, o el dercho de pernocta en domicilio con o sin pago de pensión externa. Este documento debe especificar que el familiar del dueño solo puede usarlo si cumple con todos los requisitos de un conductor permitido (licencia vigente, etc.) y bajo la supervisión y responsiva del conductor asignado.
Seguro y Cobertura: Es vital que la póliza de seguro del vehículo cubra a todos los posibles conductores, incluyendo al conductor designado y, si es necesario, a otros usuarios como familiares del dueño. La póliza debe ser de cobertura amplia y considerar los riesgos asociados al uso del vehículo por diferentes personas.
Aspectos Fiscales: El uso de un vehículo de la empresa para fines personales por parte de un empleado o familiar del dueño puede tener implicaciones fiscales. En muchos países, esto se considera un “ingreso en especie” que debe ser reportado y gravado. Es importante que la empresa consulte a un experto fiscal para asegurarse de cumplir con todas las regulaciones pertinentes…. pero la preocupación principal es seguros y accidentes.
En Conclusión:

La experiencia me muestra que es la mejor manera de abordar una situación potencialmente riesgosa. Al formalizar el uso del vehículo a través de la asignación a una persona y un área específica (Relaciones Públicas), el hospital convierte una práctica informal en una operación legítima y controlada. Esto no solo protege a la institución de riesgos legales y financieros, sino que también establece un precedente de profesionalismo y transparencia en la gestión de sus activos.

r. Un accidente con un vehículo corporativo, especialmente si lo maneja un tercero no formalmente autorizado, puede tener consecuencias legales, financieras y de reputación devastadoras para el hospital.

La propuesta de formalización protege al hospital en ese escenario, y qué medidas adicionales se deben tomar para cubrir todos los ángulos.

La Responsabilidad Legal y el Riesgo de un Accidente

En un caso como el que se plantea, la pregunta clave sería: ¿quién es el responsable? La respuesta no es tan simple.

Responsabilidad Directa del Conductor: El hijo del dueño, como conductor, es la primera persona responsable del accidente, tanto penal como civilmente.
Responsabilidad del Propietario del Vehículo: El hospital, como propietario del vehículo, tiene una responsabilidad “solidaria”. Esto significa que si el conductor no puede pagar los daños, la persona o el seguro de la víctima puede demandar al hospital para cubrir los costos. Aquí es donde se vuelve crucial el control del uso del vehículo.
Responsabilidad por Negligencia: La parte más peligrosa para el hospital es que se le acuse de negligencia por permitir que una persona no autorizada (o sin un registro formal) use un vehículo de la empresa, especialmente si esta persona no tiene una licencia válida, antecedentes de manejo imprudente, o si el vehículo no tenía el mantenimiento adecuado, o como en el segundo caso si el conductor de la pipa da positivo a alcoholimetro.

Cómo la Propuesta Minimiza el Riesgo

Esta sugerencia de formalizar el uso del coche es la forma más efectiva de proteger al hospital. Al seguir estos pasos, se crea un rastro de documentación que demuestra la diligencia de la empresa:

Asignación de “Conductor Designado”: Al designar a una persona (digamos, el “encargado de Relaciones Públicas”) como el responsable principal del vehículo, se crea un punto de control. Esta persona asume la responsabilidad de quién lo usa y para qué.
Contrato o Responsiva Formal: El documento que esta persona firma debería ser explícito. Podría decir algo como: “El firmante se compromete a que el vehículo solo será usado por conductores con licencia vigente y para los fines corporativos de la empresa, salvo autorización expresa de la dirección”.
Permiso de Uso a Terceros: Si se va a permitir que un familiar del dueño lo use, esto debe ser una excepción formal, no una práctica informal. La persona asignada debe ser el dueño, que debe tener un permiso documentado para ceder el uso del vehículo, y este permiso debe especificar que conductores ocasionales deben contar con su propia licencia de conducir vigente y respetar las políticas de la empresa.

Medidas Adicionales Esenciales

Para cerrar cualquier brecha de riesgo, el hospital debe asegurarse de lo siguiente:

Póliza de Seguro Robusta: Habla con la compañía de seguros para asegurarte de que la póliza de vehículos corporativos cubra expresamente a “conductores ocasionales” o “conductores adicionales” que tengan permiso para manejar el vehículo, sin importar si son empleados o no. Es posible que el costo sea un poco mayor, pero es una inversión crucial.
Verificación de la Licencia de Conducir: Antes de que un familiar use el coche, se debe verificar y fotocopiar su licencia. Esta simple acción demuestra que el hospital no fue negligente y se aseguró de que el conductor estaba legalmente capacitado para manejar.
En resumen, no es suficiente con que el vehículo tenga un propósito corporativo. Lo que realmente te protege en caso de un accidente es la cadena de responsabilidad y el rastro documental que demuestra que el hospital tomó medidas razonables y formales para controlar quién usa sus activos.

La propuesta de formalización no solo le da un sentido práctico al uso del coche, sino que también es la estrategia más inteligente y segura para proteger al hospital de un escenario catastrófico.