El desarrollo de aplicaciones de salud en Argentina dejó de ser un terreno reservado a grandes prestadores o laboratorios, y hoy es habitual que un profesional médico con un equipo de desarrollo externo, un grupo de investigación o una startup tecnológica lancen plataformas de turnos, teleconsulta, registro clínico, seguimiento de pacientes o recolección de datos para estudios. Sobre cada uno de esos productos se superponen la Ley 26.529 de derechos del paciente, la Ley 27.706 de historia clínica electrónica, el régimen de recetas electrónicas y teleasistencia de la Ley 27.553, las reglas de la ANMAT sobre software con finalidad médica y la Ley 25.326 de protección de datos personales, cada una con su propia autoridad de aplicación y su propia lógica de cumplimiento.
Ninguna de esas normas fue pensada para una aplicación determinada, y por esa razón el encuadre se define a partir de las funcionalidades concretas que ofrece cada producto. Una plataforma puede quedar fuera de un registro sanitario en su primera versión y quedar alcanzada cuando incorpora la emisión de recetas, un módulo de evolución clínica o un algoritmo que sugiere diagnósticos, de modo que el análisis jurídico de las aplicaciones de salud conviene hacerlo funcionalidad por funcionalidad y repetirlo antes de cada lanzamiento relevante.
Qué exige la Ley 26.529 a las aplicaciones de salud que registran información clínica
La Ley 26.529 define la historia clínica como el documento obligatorio, cronológico, foliado y completo en el que consta toda actuación realizada al paciente por profesionales y auxiliares de la salud (art. 12), y admite su confección en soporte informático siempre que se aseguren la integridad, autenticidad, inalterabilidad, perdurabilidad y recuperabilidad de los datos mediante accesos restringidos con claves de identificación, medios no reescribibles o control de modificación de campos (art. 13). La misma ley reconoce al paciente como titular de la historia clínica (art. 14) y asigna a los establecimientos y profesionales que la custodian el carácter de depositarios, con obligación de conservarla durante un plazo mínimo de diez años contados desde la última actuación registrada (art. 18).
Para quien desarrolla el software, la consecuencia de este régimen llega de manera indirecta, porque la obligación de custodia recae sobre el profesional o el establecimiento, aunque en la práctica ese profesional la cumple a través de la plataforma que contrata. Los requisitos del artículo 13 se convierten así en especificaciones técnicas del producto, como el registro inalterable de cada modificación, la trazabilidad de los accesos y la posibilidad de exportar la historia completa, mientras que el plazo del artículo 18 termina convertido en una cláusula contractual.
El choque entre el plazo de conservación y la baja del servicio
Desde nuestra experiencia en Estudio Lexar, el punto que con más frecuencia aparece sin resolver en los términos y condiciones de estas plataformas es el destino de las historias clínicas cuando el profesional deja de pagar la suscripción o da de baja su cuenta. Cuando la aplicación trata esos datos por cuenta del profesional, el artículo 25 de la Ley 25.326 ordena destruirlos una vez cumplida la prestación y solo admite conservarlos, con autorización expresa, por un máximo de dos años cuando se presuma la posibilidad de nuevos encargos, mientras que el artículo 18 de la Ley 26.529 obliga al profesional a preservar la historia clínica durante diez años. La diferencia entre ambos plazos muestra que la autorización prevista en la ley de datos no alcanza para cubrir el deber de custodia, y que la eliminación automática habitual en cualquier servicio SaaS deja al profesional en incumplimiento. Por eso el contrato tiene que prever la devolución o exportación íntegra en un formato utilizable antes de la baja, o bien un servicio específico de archivo que preserve la historia durante todo el plazo legal, y definir con precisión quién actúa como responsable y quién como encargado del tratamiento es el paso previo para redactar esa cláusula.
Dos consentimientos con objetos distintos
La Ley 26.529 exige el consentimiento informado del paciente para toda actuación profesional (arts. 5 y 6), mientras que la Ley 25.326 exige un consentimiento libre, expreso e informado para el tratamiento de datos personales, con un régimen reforzado para los datos de salud, que la ley califica como sensibles (arts. 2, 5 y 7). Se trata de manifestaciones de voluntad con objetos diferentes, y en muchas aplicaciones de salud aparecen fusionadas en una única casilla de aceptación de términos y condiciones, lo que debilita la prueba de ambos consentimientos. El problema se agrava cuando la plataforma recolecta información de salud mental o datos de participantes de estudios de investigación, supuestos en los que el diseño del flujo de aceptación forma parte del cumplimiento.
Ley 27.706 y la exigencia creciente de interoperabilidad
La Ley 27.706 creó el Programa Federal Único de Informatización y Digitalización de las Historias Clínicas con el objetivo de instaurar en forma progresiva un Sistema Único de Registro de Historias Clínicas Electrónicas, y su reglamentación por el Decreto 393/2023 designó al Ministerio de Salud como autoridad de aplicación. La reglamentación pone a cargo de los establecimientos asistenciales públicos y privados y de los profesionales titulares de consultorios el registro de toda intervención en la historia clínica electrónica, su custodia, su disponibilidad y la restricción del acceso de terceros, reitera que el paciente es el titular de los datos y admite que la historia se refrende con firma digital o electrónica en los términos de la Ley 25.506.
El Decreto 393/2023 no fija un calendario de adecuación para los sistemas privados ni prevé sanciones específicas, pero sí incluye una exigencia dirigida al software. Al definir los sistemas de historia clínica electrónica, su artículo 1 establece que deben estar inscriptos en el Registro de Dominios de Interoperabilidad en Salud creado por la Resolución 115/2019, que organiza la Red Nacional de Interoperabilidad en Salud y adopta HL7 FHIR y SNOMED CT como estándares de intercambio y terminología. La Resolución 2214/2025 siguió la misma línea para las prescripciones electrónicas (Anexo III). Para las aplicaciones de salud que ofrecen historia clínica, la consecuencia práctica es que la interoperabilidad deja de ser una funcionalidad opcional, aun cuando la falta de plazos y de un régimen sancionatorio propio mantenga abierta la pregunta sobre su exigibilidad concreta.
Cuándo una funcionalidad queda alcanzada por el ReNaPDiS
La Ley 27.553, reglamentada por el Decreto 98/2023 y modificada por el DNU 70/2023, establece en su texto vigente que la prescripción y dispensación de medicamentos, y toda otra prescripción, sólo pueden redactarse y firmarse a través de plataformas electrónicas habilitadas. La Resolución 1959/2024 del Ministerio de Salud creó el Registro Nacional de Plataformas Digitales Sanitarias (ReNaPDiS) y, dentro de él, el Registro de Recetarios Electrónicos, cuya inscripción se tramita por la plataforma de Trámites a Distancia y da lugar a un identificador que integra la Clave Única de Identificación de Receta. Desde el 1° de enero de 2025 la receta electrónica es la única modalidad válida para prescribir medicamentos en las jurisdicciones alcanzadas, y la Resolución 2214/2025 extendió el concepto a la prescripción de dispositivos, estudios complementarios, prácticas y procedimientos, dispuso que todas estas prescripciones se emitan exclusivamente a través de plataformas registradas y obligó a los repositorios a conservar durante al menos tres años las recetas de expendio bajo receta archivada y de expendio legalmente restringido.
La diferencia entre el registro posible y el registro obligatorio
El artículo 3 de la Resolución 1959/2024 dispone que el ReNaPDiS “podrá” registrar plataformas de prescripción, repositorios, diccionarios de medicamentos, sistemas de teleasistencia, sistemas de validación y de administración de farmacia y cualquier otro sistema vinculado con la salud digital, y el artículo 4 agrega que los responsables de esas plataformas “se inscribirán” conforme a los requerimientos técnicos que emita la Dirección Nacional de Sistemas de Información Sanitaria. La lectura conjunta de ambos artículos indica un deber de inscripción que alcanza también a la teleasistencia, aunque hasta ahora el procedimiento por Trámites a Distancia y los requisitos técnicos se desarrollaron solo para recetarios electrónicos y repositorios. Una plataforma de teleconsulta que se limita a conectar profesional y paciente por videollamada queda así en una zona gris, con una obligación enunciada y sin un canal operativo para cumplirla, y el punto de inflexión práctico llega cuando la plataforma permite al profesional emitir una receta, una orden de estudios o un certificado.
Los certificados de reposo después de la reforma laboral
La reforma laboral de 2026 agregó un supuesto que muchas plataformas de telemedicina todavía no incorporaron a su análisis. La Ley 27.802 reescribió el artículo 210 de la Ley de Contrato de Trabajo, que ahora exige que los certificados médicos que justifican inasistencias por enfermedad contengan diagnóstico, tratamiento y días de reposo, y que se firmen digitalmente a través de las plataformas autorizadas por la Ley 27.553. El Decreto 407/2026 precisó que esas plataformas deben estar registradas en el ReNaPDiS y que el profesional debe estar habilitado en la Red Federal de Registros de Profesionales de la Salud (REFEPS), con la sola excepción del certificado en papel ante fallas de conectividad o contingencias técnicas acreditadas. El perímetro del registro sanitario se amplió así por la vía de una norma laboral, y cualquier aplicación de teleconsulta que entregue certificados a trabajadores en relación de dependencia quedó alcanzada por esa exigencia, emita o no recetas.
Inscribirse como recetario o integrar uno ya registrado
Frente a estas exigencias, muchas startups que desarrollan aplicaciones de salud optan por integrar mediante API un recetario electrónico ya inscripto en lugar de tramitar su propia inscripción, que supone cumplir los lineamientos técnicos, los estándares de interoperabilidad y las obligaciones de envío de información al repositorio centralizado. Esa alternativa es razonable desde el punto de vista operativo, pero traslada el problema al contrato con un tercero que recibe datos sensibles de los pacientes y del cual depende la continuidad de una funcionalidad crítica. Los riesgos propios de la dependencia de servicios de terceros se agravan en este caso, porque una suspensión del recetario en el registro deja a los profesionales sin poder prescribir desde la aplicación. Conviene verificar la inscripción del proveedor en el listado oficial de plataformas aprobadas por el Ministerio de Salud, revisar las cláusulas de acceso del proveedor a la información que circula por la integración y asignar con claridad la responsabilidad frente a profesionales y pacientes.
Cuándo las aplicaciones de salud se consideran software médico ante la ANMAT
La Disposición ANMAT 64/2025 incorporó al ordenamiento nacional la Resolución GMC 25/21, que aprobó el Reglamento Técnico Mercosur de Registro de Productos Médicos y derogó el régimen anterior de la Disposición 2318/02. El reglamento define al software como producto médico (Software as a Medical Device, SaMD) como el producto o aplicación informática que su fabricante destina a una o más de las finalidades previstas en la definición de producto médico y que cumple esa función sin formar parte del hardware de otro producto médico, aun cuando se ejecute sobre plataformas de uso general como un teléfono móvil. Una aplicación que encuadra en esa definición queda sujeta al régimen general de productos médicos, que comprende la clasificación por riesgo en cuatro clases, el registro del producto ante la ANMAT, la habilitación de la empresa fabricante o importadora y las obligaciones de tecnovigilancia posteriores a la comercialización. Para las clases I y II, la Disposición ANMAT 8799/2025 habilitó un trámite simplificado de habilitación de la empresa mediante declaración jurada, lo que reduce la carga inicial sin alterar el encuadre.
La finalidad declarada por el fabricante como criterio de encuadre
La definición gira alrededor de la finalidad que el fabricante asigna al producto, y esa elección del reglamento tiene una consecuencia que pocas veces se advierte en el diseño de las aplicaciones de salud, porque la calificación regulatoria se construye en buena medida con las propias declaraciones de la empresa, como la descripción en las tiendas de aplicaciones, la página de presentación, los términos y condiciones y las presentaciones a inversores. Una aplicación que permite al usuario registrar sus valores de presión arterial y compartirlos con su médico se ubica en un lugar distinto del de otra que, con un código muy similar, promete detectar hipertensión o sugerir ajustes en la medicación. Lo mismo ocurre con los verificadores de síntomas y los sistemas de triage basados en inteligencia artificial, cuya calificación depende de si los resultados se presentan como información general o como una indicación diagnóstica o terapéutica para un paciente determinado.
Antes del lanzamiento, producto, marketing y asesoría legal deberían acordar por escrito una declaración de finalidad prevista coherente con lo que efectivamente hace el software, y dejar documentado el análisis de encuadre con referencia a los criterios del International Medical Device Regulators Forum (IMDRF), foro en el que la ANMAT participa como observador. Cuando la funcionalidad incorpora modelos de inteligencia artificial, a los riesgos legales de integrar inteligencia artificial en cualquier producto digital se suma un vacío propio de este régimen, que todavía no prevé un mecanismo específico para autorizar de antemano las actualizaciones de un modelo que se reentrena.
Datos de salud, seguridad y proveedores
La Ley 25.326 califica a la información referida a la salud como dato sensible (art. 2), y su artículo 8 habilita a los establecimientos sanitarios y a los profesionales de la salud a tratar los datos de sus pacientes respetando el secreto profesional. Esa habilitación alcanza al profesional y al establecimiento, de modo que la empresa que explota la aplicación necesita una base propia cada vez que usa los datos para fines que exceden la prestación del servicio, como el análisis de uso, la mejora del producto o el entrenamiento de modelos. Para esos fines el camino habitual es el consentimiento expreso y separado del titular, o bien una anonimización efectiva que impida identificarlo, supuesto que el artículo 7 admite para finalidades estadísticas o científicas.
El resto del cumplimiento sigue las reglas generales del régimen de protección de datos personales, aunque con un estándar más alto por la naturaleza de la información. Corresponde inscribir las bases de datos ante la Agencia de Acceso a la Información Pública, adoptar medidas de seguridad acordes al carácter sensible de los datos (art. 9), formalizar contratos de tratamiento por cuenta de terceros con los proveedores de hosting, mensajería e inteligencia artificial y evaluar la transferencia internacional de datos cuando la infraestructura se aloja fuera del país. Como la cadena de proveedores es uno de los puntos de mayor exposición frente a incidentes de seguridad, la revisión de los contratos con proveedores tecnológicos tiene en las aplicaciones de salud un peso particular.
Qué revisar en el lanzamiento de aplicaciones de salud
En los encargos recientes vinculados con aplicaciones de salud que acompañamos, que fueron desde desarrollos impulsados por profesionales médicos con equipos externos hasta plataformas de investigación y servicios integrados con sistemas de prescripción de terceros, el alcance de trabajo terminó ordenándose alrededor de un mismo conjunto de cuestiones, con independencia del tamaño del proyecto.
- Mapa de funcionalidades y encuadre regulatorio. Identificar qué funciones registran información clínica en los términos de la Ley 26.529, cuáles emiten recetas, órdenes o certificados alcanzados por el ReNaPDiS y cuáles podrían calificar como software médico ante la ANMAT.
- Contrato con los desarrolladores. Asegurar la cesión de los derechos sobre el código, las obligaciones de seguridad y la entrega de documentación técnica, que son los primeros puntos que examina un inversor en una auditoría tecnológica.
- Términos y condiciones diferenciados. Redactar condiciones separadas para profesionales y pacientes, con reglas claras sobre conservación, exportación y destino de las historias clínicas al finalizar el servicio.
- Consentimientos separados. Distinguir el consentimiento informado para el acto profesional del consentimiento para el tratamiento de datos sensibles, y diseñar un flujo de aceptación que deje prueba de ambos.
- Roles y proveedores. Definir cuándo la aplicación actúa por cuenta del profesional y cuándo trata datos para fines propios, y formalizar los contratos con hosting, recetarios integrados y servicios de inteligencia artificial.
- Inscribir las bases ante la AAIP y, cuando corresponda, tramitar la inscripción en el ReNaPDiS, en el Registro de Dominios de Interoperabilidad en Salud o el registro del producto ante la ANMAT.
- Protocolo de incidentes. Prever la detección, la notificación y la comunicación a profesionales y pacientes ante una filtración de datos de salud.
Cuestiones que la normativa todavía no resuelve
El marco descripto deja abiertos varios puntos que conviene tener presentes al diseñar las aplicaciones de salud. El primero es la situación de las plataformas de teleasistencia que no prescriben ni certifican, a las que la Resolución 1959/2024 alcanza en su enunciado sin que exista todavía un procedimiento técnico de inscripción equivalente al de los recetarios.
El segundo es la heterogeneidad federal, porque la obligatoriedad de la receta electrónica opera a nivel nacional en la medida en que las jurisdicciones locales adhieren y algunas, entre ellas la provincia y la Ciudad de Buenos Aires, cuentan con regímenes propios, lo que obliga a verificar la normativa de cada jurisdicción donde ejercen los profesionales usuarios.
El tercero es la articulación entre el deber de destrucción del artículo 25 de la Ley 25.326 y el deber de conservación del artículo 18 de la Ley 26.529, que ninguna norma resuelve de manera expresa y que hoy depende enteramente de lo que pacten profesional y plataforma. El cuarto es la exigibilidad concreta de la inscripción de los sistemas privados de historia clínica en el Registro de Dominios de Interoperabilidad, que el Decreto 393/2023 impone sin plazos ni sanciones propias.
Preguntas frecuentes sobre aplicaciones de salud
¿Una aplicación de turnos o teleconsulta tiene que inscribirse en el ReNaPDiS?
Una plataforma que solo gestiona turnos o conecta profesional y paciente por videollamada figura entre los sistemas que deben inscribirse en el ReNaPDiS, aunque todavía no existe un procedimiento técnico para hacerlo. La situación cambia cuando permite emitir recetas, órdenes de estudios o prácticas, que deben generarse exclusivamente en plataformas registradas según la Resolución 2214/2025, o certificados de reposo laboral, alcanzados por el nuevo artículo 210 de la Ley de Contrato de Trabajo. En esos casos la aplicación puede inscribirse como recetario o integrar uno ya registrado.
¿Cuándo una app de salud necesita registro ante la ANMAT?
Una app necesita registro cuando su fabricante la destina a finalidades propias de un producto médico, como el diagnóstico, la prevención, el monitoreo o el tratamiento de enfermedades, en los términos del Reglamento Técnico Mercosur incorporado por la Disposición ANMAT 64/2025. Las aplicaciones de salud orientadas al bienestar general o a la gestión administrativa quedan, en principio, fuera de ese régimen, aunque la descripción comercial del producto puede alterar ese encuadre.
¿La aplicación o el médico es responsable de la historia clínica?
La Ley 26.529 asigna la condición de depositario al establecimiento o al profesional que custodia la historia clínica, y reconoce al paciente como su titular. La aplicación actúa en general como encargada del tratamiento por cuenta del profesional, con obligaciones propias de seguridad y confidencialidad, y asume responsabilidad directa cuando usa los datos para fines que exceden ese encargo.
¿Se pueden usar los datos de los pacientes para entrenar modelos de inteligencia artificial?
Los datos de salud son sensibles bajo la Ley 25.326, y la habilitación que la ley otorga a profesionales y establecimientos sanitarios no se extiende a los usos propios de la empresa que explota la aplicación. Para entrenar modelos hace falta consentimiento expreso y específico del titular o una anonimización que impida su identificación, y en ambos casos conviene documentar el análisis antes de iniciar el tratamiento.
¿Cuánto tiempo hay que conservar las historias clínicas y las recetas?
Las historias clínicas deben conservarse por un plazo mínimo de diez años contados desde la última actuación registrada (art. 18 de la Ley 26.529), mientras que los repositorios de recetas inscriptos en el ReNaPDiS deben resguardar durante al menos tres años las prescripciones de medicamentos de expendio bajo receta archivada y de expendio legalmente restringido, según la Resolución 2214/2025.
En Estudio Lexar acompañamos a profesionales de la salud, equipos de investigación y empresas tecnológicas en el encuadre regulatorio de sus plataformas, en la redacción de términos y condiciones, políticas de privacidad y consentimientos, en la revisión de contratos con desarrolladores y proveedores y en los trámites de inscripción ante los organismos competentes, como parte de nuestra práctica de asesoramiento en derecho informático.
