AI Empresas de voz y flujos de trabajo en el sector sanitario: un marco de diligencia debida para inversores de crecimiento

1. Definir la tesis de inversión en torno a una tarea acotada que debe resolverse

Las empresas de voz y flujos de trabajo de AI para la salud deberían evaluarse para inversión en torno a una tarea acotada que debe resolverse. El inversor debe indicar qué usuario realiza qué tarea, en qué entorno asistencial, con qué datos de entrada, produciendo qué salida, con qué obligación de revisión y qué resultado económico medible. «AI para la salud» es demasiado amplio para sustentar la diligencia debida. La documentación clínica ambiental para clínicos de consulta externa, las llamadas autónomas a pacientes, los resúmenes de traspaso de pacientes hospitalizados, las sugerencias de codificación y la preparación de autorizaciones previas ocupan posiciones clínicas, regulatorias y económicas distintas.

El perímetro del producto debe distinguir captura, transcripción, extracción, síntesis, recomendación, preparación de acciones y ejecución de acciones. La captura registra o transmite voz en flujo continuo. La transcripción convierte audio en texto. La extracción identifica hechos especificados. La síntesis comprime la información. La recomendación propone un juicio o un paso siguiente. La preparación de acciones crea una orden, un mensaje, una reclamación o una tarea para su revisión. La ejecución de acciones modifica un registro, inicia una comunicación o afecta la atención. El riesgo aumenta a medida que el producto pasa de la representación al juicio y la ejecución.

La tesis debe identificar al comprador, el presupuesto, el beneficiario y el titular del veto. Un director de información médica puede patrocinar el caso clínico. Operaciones puede ser responsable del despliegue. Los equipos de seguridad y privacidad pueden aprobar los flujos de datos. Finanzas puede exigir un caso de productividad o retención. Los clínicos y los pacientes determinan la adopción práctica. Compras puede imponer condiciones de integración, de seguro y contractuales. Una empresa puede tener usuarios entusiastas y una venta corporativa bloqueada cuando estos roles no están alineados.

La pregunta de diligencia debida es, por tanto, causal: ¿el producto genera una mejora repetible en un flujo de trabajo de alto valor, bajo los controles exigidos por los clientes, con un coste de despliegue y soporte que permita una economía unitaria duradera? La respuesta debe contrastarse mediante evidencia de flujos de trabajo, rendimiento en producción, derechos, datos de cohortes y referencias de clientes. El entusiasmo del mercado, la calidad de las demostraciones y la sofisticación del modelo siguen siendo contexto de apoyo.

Tabla 1. Mapa de perímetro del producto y uso previsto

La clasificación y las obligaciones requieren asesoramiento jurídico y regulatorio específico para la jurisdicción.

2. Mapear el flujo de trabajo completo antes de evaluar el modelo

La precisión del modelo solo tiene sentido dentro de un flujo de trabajo. La diligencia debida debe comenzar con observación directa, evidencia de pantalla, registros del sistema y entrevistas a usuarios que reconstruyan el proceso actual y el propuesto. El mapa comienza antes de que el modelo reciba datos y termina después de la acción final del usuario, la conciliación posterior y la gestión de excepciones. Debe mostrar identidades, sistemas, colas, traspasos, puntos de revisión, estados de espera y recuperación ante fallos.

Para la documentación clínica en segundo plano, el flujo de trabajo puede incluir la notificación o el consentimiento del paciente, la selección del micrófono, el inicio de la sesión, la separación de hablantes, la transmisión de audio, la transcripción, la extracción estructurada, la generación de notas, la revisión por el clínico, la edición, la atestación, la codificación, la escritura de vuelta en el registro y la eliminación o conservación. Cada etapa puede fallar de forma independiente. Una transcripción sólida todavía puede generar una nota deficiente. Una buena nota todavía puede aumentar el trabajo cuando la navegación por la historia clínica electrónica, la selección de plantillas, la atribución o la firma resultan engorrosas.

El mapa debe registrar el tiempo y la calidad tanto del proceso antiguo como del nuevo. El tiempo ahorrado durante el dictado puede verse compensado por la edición, la búsqueda, las interrupciones del flujo de trabajo o las correcciones fuera del horario laboral. Un producto puede trasladar trabajo de los clínicos a los asistentes médicos, codificadores, equipos de soporte o personal de implantación. El inversor debe cuantificar el trabajo total del sistema e identificar quién lo absorbe.

La adecuación del flujo de trabajo también varía según la especialidad y el encuentro clínico. Una visita breve de atención primaria, una consulta pediátrica con varios interlocutores, una consulta de salud mental, una visita al servicio de urgencias y una conversación de consentimiento quirúrgico tienen vocabulario, turnos de palabra, privacidad y estructuras de documentación diferentes. La muestra de diligencia debida debe representar el plan de expansión comercial, no el caso de uso actual más sencillo.

El mapa identifica la cadena de control completa; los flujos de trabajo reales varían según el producto, el entorno asistencial y la jurisdicción.

3. Construir la sala de evidencias en torno a la realidad de producción

La sala de diligencia debida debe organizarse en torno a las afirmaciones que importan a clientes e inversores. Para cada afirmación, la empresa debe proporcionar la definición, la población de medición, el periodo, el comparador, el sistema de origen, las exclusiones, el método estadístico, el responsable y el resultado reproducible. La evidencia debe distinguir entre pruebas internas, pilotos con clientes, despliegues en producción, estudios revisados por pares y estimaciones de marketing.

Los materiales principales incluyen especificaciones del producto, declaraciones de uso previsto, fichas de modelo, planes de validación, conjuntos de datos de prueba, historiales de lanzamientos, registros de incidentes, expedientes de seguridad clínica, evaluaciones de privacidad, informes de seguridad, diagramas de arquitectura, mapas de flujo de datos, contratos con clientes, acuerdos de asociado comercial, listas de subencargados del tratamiento, planes de implementación, tickets de soporte, registros de disponibilidad, evidencia de integración con la historia clínica electrónica (EHR), ingresos por cohorte, facturas, facturas de servicios en la nube y permisos de referencia de clientes. La lista de solicitudes debe vincular cada documento con una pregunta de inversión.

Los registros de producción merecen especial atención. Pueden mostrar intentos de encuentro, capturas exitosas, abandono, latencia, generación de resultados, tiempo de revisión, distancia de edición, aceptación, escritura de vuelta, error, anulación y eventos de soporte. El investigador debe conciliar las definiciones de eventos entre versiones. Una métrica puede mejorar porque un encuentro fallido o difícil desapareció del denominador. Una versión del producto puede cambiar el registro de eventos antes de cambiar el rendimiento.

El repositorio de evidencia debe preservar la evidencia negativa. Los pilotos fallidos, las cohortes de baja adopción, las preocupaciones de seguridad, las restricciones de derechos de datos, las integraciones no rentables y la pérdida de clientes pueden revelar los límites de la repetibilidad. La dirección debe explicar si el problema surgió de la capacidad del producto, el diseño del flujo de trabajo, la preparación del cliente, los precios, la implementación, la gobernanza o la competencia. El inversor puede entonces comprobar si el plan actual aborda la causa.

Tabla 2. Inventario de evidencia para la diligencia debida de inversores de crecimiento

La profundidad requerida debe reflejar el uso previsto del producto, la huella de clientes y la materialidad de la transacción.

4. Crear un registro de derechos sobre los datos para cada finalidad de tratamiento

Una empresa AI de atención sanitaria puede poseer datos sin contar con todos los derechos que exigen su producto y su plan de crecimiento. La diligencia debida debe separar el derecho a recibir datos del derecho a tratarlos para una finalidad concreta. La grabación, la transcripción, la generación de notas, el almacenamiento, la garantía de calidad, el soporte, la evaluación de modelos, la mejora de productos, el entrenamiento de modelos, la evaluación comparativa y la exportación de clientes pueden requerir análisis contractuales, de privacidad, de consentimiento y regulatorios diferentes.

El registro debe identificar la categoría de datos, el interesado, la fuente, el responsable del tratamiento o la entidad cubierta, el encargado del tratamiento o socio comercial, el subencargado del tratamiento, la ubicación, la finalidad, la base legal o contractual, la conservación, la eliminación, la exportación, el uso para entrenamiento, el derecho de auditoría y la responsabilidad en caso de incidente. El audio merece un tratamiento separado de la transcripción y del texto generado. El audio puede contener voces de pacientes, familiares, profesionales clínicos y personas presentes. Las características derivadas, los embeddings, las etiquetas y la retroalimentación de modelos pueden conservar su carácter sensible o restricciones contractuales.

HHS señala que las entidades cubiertas que utilizan socios comerciales requieren acuerdos escritos que especifiquen las funciones permitidas y las salvaguardas para la información de salud protegida.[7] La guía de la nube de HHS también hace relevante un acuerdo con el socio comercial cuando un servicio en la nube crea, recibe, mantiene o transmite información de salud protegida electrónica en nombre de una entidad cubierta o de un socio comercial.[8] Los productos fuera del perímetro de entidad cubierta y socio comercial de HIPAA pueden seguir enfrentándose a otras obligaciones de privacidad y de brechas. La Regla de Notificación de Brechas de Salud de la FTC es un ejemplo estadounidense para proveedores cubiertos de registros de salud personal y entidades relacionadas.[19]

Los derechos deben someterse a prueba mediante la terminación y el cambio de control. El inversor debe determinar si un cliente puede revocar los derechos de mejora, exigir la eliminación, prohibir el entrenamiento de modelos, restringir el tratamiento transfronterizo o solicitar asistencia para la migración. La empresa debe demostrar cómo el linaje de los datos respalda esas obligaciones. El texto contractual y la capacidad del sistema deben ser coherentes.

Cada finalidad de tratamiento requiere su propia evidencia; la cifra no determina una base jurídica.

5. Comprender el modelo y la cadena de suministro de software

El producto puede combinar reconocimiento de voz, diarización de hablantes, detección de idioma, vocabularios especializados, recuperación, modelos de lenguaje grandes, reglas, plantillas, motores de codificación y orquestación de flujos de trabajo. La diligencia debida debería identificar qué componentes son propietarios, licenciados, de código abierto, específicos del cliente o proporcionados por un tercero. La arquitectura debería mostrar dónde se ejecuta cada componente, qué datos recibe y qué salida controla.

El análisis de dependencias debería cubrir los términos de los modelos fundacionales, los términos de los modelos de voz, la concentración del alojamiento, los límites de velocidad, la disponibilidad regional, los cambios de precio, la obsolescencia, los filtros de seguridad y los derechos sobre la salida generada. Una empresa puede ser propietaria de la interfaz y de la lógica del flujo de trabajo mientras depende de un número reducido de proveedores upstream para la inferencia central. Esto puede seguir siendo un modelo atractivo, pero el inversor debería valorar el coste de sustitución y el poder de negociación.

El registro de modelos debería recoger la finalidad, la versión, la entrada, la salida, el método de entrenamiento o adaptación, la población de evaluación, las limitaciones conocidas, el uso aprobado, el seguimiento y la autoridad de liberación. Las reglas deterministas, los modelos estadísticos y los sistemas generativos deberían permanecer distintos porque sus errores y métodos de prueba difieren. Una única versión de producto puede contener varias versiones de modelos y configuraciones de prompts o de recuperación.

El control de cambios es fundamental. La guía de la FDA sobre los planes de control de cambios predeterminados y la gestión del ciclo de vida muestra por qué las modificaciones planificadas, la validación y el seguimiento importan para las funciones de dispositivos habilitadas por AI.[4][5] La aplicación regulatoria precisa depende del uso previsto y de la jurisdicción. Incluso cuando el software queda fuera de la regulación de dispositivos, los clientes siguen necesitando evidencia de que los cambios materiales se evalúan antes de la liberación y de que las regresiones pueden detectarse, contenerse y revertirse.

El inversor debería probar la vía de sustitución de emergencia. ¿Puede la empresa cambiar un modelo upstream sin perder funcionalidad, derechos, latencia, cobertura geográfica o economía unitaria? ¿Dispone de pruebas de regresión y de normas de notificación a los clientes? La opcionalidad de la arquitectura solo es valiosa cuando se ha ejercitado o evidenciado.

6. Evaluar el rendimiento en la unidad de decisión del flujo de trabajo

La precisión agregada de la transcripción es una medida incompleta. El inversor debería probar la unidad que afecta al flujo de trabajo y a la atención: un medicamento, una alergia, un síntoma, un diagnóstico, una duración, una negación, la atribución de hablante, una tarea, un código, un elemento de pedido, una clasificación de urgencia o una instrucción al paciente. Una nota puede leerse con fluidez mientras omite un hecho clínicamente material o lo atribuye al hablante equivocado.

El plan de evaluación debería definir el uso previsto, la población, el entorno, el estándar de referencia, la adjudicación, las métricas, los umbrales y la respuesta ante fallos. Debería incluir positivos conocidos, negativos conocidos, casos límite difíciles y condiciones fuera de distribución. Las muestras deberían cubrir especialidades, tipos de encuentro, acentos, idiomas, ruido, telesalud, interrupciones, varios hablantes y grupos de pacientes relevantes. La hoja de ruta comercial debería determinar la matriz de pruebas.

Las dimensiones de rendimiento incluyen la exhaustividad fáctica, la corrección fáctica, el contenido no respaldado, la negación, la temporalidad, la atribución de hablante, la estructura, la extracción de acciones, la latencia y la abstención. Las dimensiones del flujo de trabajo incluyen el tiempo de revisión, la distancia de edición, la aceptación, la anulación, el abandono, el uso de soporte y la corrección posterior. Las dimensiones de seguridad se centran en los errores clínicamente materiales y en si los controles los detectan antes de actuar.

La empresa debería conservar resultados versionados. Una puntuación global puede mejorar mientras un subgrupo material empeora. Por tanto, los umbrales deberían fijarse por caso de uso y por daño, no por comodidad comercial. Los datos de evaluación deberían ser suficientemente independientes de los datos de desarrollo, y el ajuste específico del cliente debería separarse del rendimiento del producto principal.

Tabla 3. Diseño de evaluación de modelos por unidad de decisión

Las métricas y los umbrales requieren un diseño clínico y estadístico específico para cada producto.

Las puntuaciones son dimensiones ilustrativas; los inversores deben utilizar métricas y umbrales específicos para cada producto.

7. Probar la seguridad clínica y la supervisión humana como sistemas operativos

La supervisión humana debe especificarse como un control operativo. «Human in the loop» no explica quién revisa, qué ve, cuánto tiempo tiene, qué errores puede detectar, qué ocurre bajo presión de carga de trabajo ni cómo responde el sistema cuando falla la revisión. La diligencia debida debe mapear el rol responsable, la interfaz de revisión, la ruta de escalado y la evidencia conservada para cada resultado relevante.

El diseño de la revisión debe exponer el contexto de origen y la incertidumbre cuando sea útil. Es posible que el usuario necesite el fragmento relevante de la transcripción, el hablante, la marca temporal, la confianza, el registro de respaldo y el motivo de la acción sugerida. Un borrador largo y fluido puede dificultar la detección de errores. Por tanto, el diseño de la interfaz, la carga de alertas y la presión de tiempo afectan la fiabilidad práctica de la supervisión humana.

La guía de la OMS sobre modelos multimodales grandes destaca riesgos como resultados inexactos, sesgo, sesgo de automatización, privacidad y ciberseguridad.[2] La norma DCB0129 del NHS exige gestión del riesgo clínico para los fabricantes de TI sanitaria, mientras que la DCB0160 aborda el despliegue y el uso por parte de las organizaciones de atención.[12] Estas normas ilustran la responsabilidad compartida entre el producto y el adoptante. La empresa debe mostrar un registro de peligros, un caso de seguridad clínica o un expediente de riesgos equivalente adecuado a sus mercados y uso.

La gestión de incidentes debe conectar la telemetría del producto, los informes de clientes, la revisión clínica, la investigación de ingeniería y los derechos de decisión de la dirección. Las definiciones de gravedad deben recoger el daño potencial y los cuasiincidentes, no solo las lesiones confirmadas. Los incidentes significativos deben activar la contención, la comunicación con el cliente, el análisis de la causa raíz, la acción correctiva, las pruebas de regresión y la monitorización.

El inversor debe probar el modo degradado. Si fallan la transcripción, la inferencia, la conectividad con el EHR o la resolución de identidad, ¿puede el usuario seguir prestando atención de forma segura? El flujo de trabajo necesita un estado claro, ninguna escritura de vuelta silenciosa, reglas de reintento y una ruta manual. Una ruta de fallo segura puede importar más que el rendimiento medio del modelo.

8. Examinar el desempeño por subgrupos, el idioma y la accesibilidad

Los productos de voz operan con distintos acentos, idiomas, alternancia de códigos, trastornos del habla, grupos de edad, calidades de micrófono y entornos clínicos. Un resultado agregado puede ocultar un desempeño deficiente en poblaciones comercialmente importantes o vulnerables. La diligencia debida debería alinear las pruebas por subgrupos con la huella desplegada y el plan de expansión de la empresa.

La empresa debería explicar cómo define los grupos, obtiene datos de evaluación lícitos, establece la verdad de referencia y evita conclusiones inestables a partir de muestras pequeñas. Las diferencias de desempeño deberían evaluarse en unidades clínica y operativamente significativas. Una diferencia modesta en la tasa de error de palabras puede volverse material cuando afecta nombres de medicamentos, negaciones, números o síntomas urgentes.

La cobertura lingüística debería distinguir entre traducción de la interfaz de usuario, reconocimiento del habla, vocabulario clínico, generación de notas y ejecución de flujos de trabajo. Un producto puede reconocer el habla conversacional en un idioma y, al mismo tiempo, carecer de términos especializados validados, plantillas o campos posteriores de la historia clínica electrónica (EHR). Los encuentros con varios idiomas requieren evidencia separada. Las etiquetas de marketing, como multilingüe, deberían descomponerse en funciones y configuraciones probadas.

La accesibilidad incluye necesidades auditivas, del habla, cognitivas, visuales y motoras, así como alfabetización digital. Los agentes de voz orientados al paciente deberían gestionar repeticiones, interrupciones, incertidumbre, participación de intérpretes y transferencia a una persona. Deberían evitar crear una barrera para quienes no pueden o no desean usar la automatización por voz.

Los principios de gobernanza más amplios de la OMS en materia de AI sitúan la inclusión y la equidad junto a la autonomía, la seguridad, la transparencia, la responsabilidad y la sostenibilidad.[1] El inversor debería traducir esos principios en evaluación por subgrupos versionada, criterios de despliegue para clientes, supervisión y remediación. El modelo comercial debería incluir el coste de atender a las poblaciones a las que promete servir.

9. Auditar la privacidad, el consentimiento, la seguridad y la resiliencia

El mapa de flujo de datos debería seguir el audio, la transcripción, el contenido generado, los identificadores, los metadatos, los registros, el acceso del soporte, las copias de seguridad y la retroalimentación del modelo a través de dispositivos, redes, nubes, subencargados y sistemas de clientes. Cada transferencia necesita un responsable, una finalidad, una protección, una regla de retención y una vía de incidentes. Los certificados de seguridad y las pruebas de penetración son evidencia útil, pero no sustituyen un modelo de amenazas específico de la arquitectura.

La voz crea riesgos particulares. La captura permanente o ambiental puede incluir a hablantes no previstos y conversaciones sensibles. Los controles de inicio y fin de sesión, el estado visible, el consentimiento o aviso, los permisos de micrófono, el almacenamiento en búfer local y el comportamiento de eliminación requieren pruebas. El producto debería impedir que el contenido de un paciente entre en el registro de otro y debería poner de manifiesto la incertidumbre de identidad antes de la escritura de retorno.

La diligencia debida en seguridad debería abarcar autenticación, acceso por roles, mínimo privilegio, cifrado, gestión de claves, secretos, aislamiento de inquilinos, cadena de suministro de software, gestión de vulnerabilidades, desarrollo seguro, registro de eventos, detección de anomalías, copias de seguridad, recuperación y notificación a clientes. Los sistemas generativos añaden inyección de prompts, fuga de datos, contenido malicioso, envenenamiento de la recuperación y dependencia del servicio de modelos. El RMF de AI de NIST y el Perfil generativo de AI proporcionan una referencia estructurada de gestión de riesgos.[13]

Para las funciones reguladas de dispositivos, la guía de ciberseguridad de la FDA de 2026 aborda consideraciones de diseño, sistema de calidad y presentación.[5] Su aplicación vuelve a depender del producto y del uso previsto. Todas las empresas deberían demostrar resiliencia mediante objetivos de recuperación probados, fallos de dependencias y ejercicios de incidentes.

Las promesas contractuales deberían conciliarse con las operaciones. Si el acuerdo promete procesamiento regional, eliminación rápida, notificación sobre subencargados u objetivo de recuperación, la empresa debería mostrar evidencia del sistema. Una brecha entre el discurso comercial y la capacidad de producción puede convertirse en un riesgo de renovación, responsabilidad y valoración.

10. Clasificar la exposición regulatoria por función y jurisdicción

La clasificación regulatoria sigue el uso previsto y la función, no la categoría preferida por la empresa. Una herramienta de documentación que registra y redacta una nota puede ocupar una posición distinta de la de un software que recomienda diagnósticos, prioriza síntomas urgentes o ejecuta una orden. Por lo tanto, los módulos de producto y las declaraciones deberían clasificarse por separado.

En Estados Unidos, la guía de apoyo a la decisión clínica de la FDA de enero de 2026 explica los criterios para ciertas funciones de CDS que no son dispositivos y ofrece ejemplos que distinguen el software que no es dispositivo del que sí lo es.[3] Otras guías de salud digital de la FDA abordan el software de dispositivos habilitado por AI, el control de cambios y la ciberseguridad.[4][5] La regla HTI-1 de la ONC añade requisitos de transparencia algorítmica para el apoyo a la decisión predictiva suministrado a través de TI sanitarias certificadas.[6] El equipo de diligencia debida debería determinar si la empresa es un desarrollador certificado de TI sanitarias, se integra con uno o suministra funcionalidades que activan el arrastre contractual de obligaciones.

En la Unión Europea, la Ley AI crea obligaciones basadas en el rol del sistema y la clasificación de riesgo, incluidas las categorías de alto riesgo vinculadas a productos regulados y usos especificados.[9] El Espacio Europeo de Datos Sanitarios añade requisitos escalonados para los datos sanitarios electrónicos y los sistemas de historia clínica electrónica (EHR), al tiempo que preserva la aplicación de GDPR, las normas sobre productos sanitarios y AI.[10] Las fechas de entrada en vigor y el impacto en el producto exigen un análisis actual específico de la jurisdicción.

En el Reino Unido, la guía de la MHRA y su programa de software y AI como producto sanitario enmarcan la clasificación de productos y las expectativas del ciclo de vida.[11] Los despliegues del NHS también pueden exigir evidencia sobre riesgo clínico, protección de datos, seguridad técnica, interoperabilidad y usabilidad mediante estándares DCB y criterios de evaluación.[12]

La matriz regulatoria debe registrar el módulo, la declaración, el usuario, la acción, la jurisdicción, la visión de clasificación, la evidencia, el registro o la certificación, las obligaciones poscomercialización y la consecuencia del cambio. La conclusión de la dirección debe estar respaldada por asesoramiento cualificado cuando sea relevante. Una etiqueta como software administrativo no resuelve el análisis.

11. Validar la arquitectura de integración y la interoperabilidad

La integración forma parte del producto. El valor de empresa puede depender de una identidad fiable, el inicio de contexto, la coincidencia de encuentros, el acceso a agendas, la escritura de documentación, el enrutamiento de tareas, la codificación, el consentimiento, la auditoría y la analítica en los sistemas del cliente. Un proveedor con modelos sólidos y una integración frágil puede enfrentarse a ciclos de venta largos, altos costes de servicios y resultados variables.

La revisión de la arquitectura debe identificar cada interfaz, protocolo, método de autenticación, objeto de datos, permiso de escritura, mecanismo de sondeo o de eventos, latencia, reintento, cola de errores, observabilidad y responsable de soporte. Estándares como HL7 FHIR pueden mejorar la portabilidad, pero la implementación del cliente, las versiones, los perfiles y las limitaciones propietarias siguen importando.[20] Una integración declarada debe demostrarse en producción, no inferirse de una especificación API.

El inversor debe distinguir los conectores reutilizables del trabajo específico para el cliente. La configuración reutilizable puede favorecer la escala. Las transformaciones a medida, el mapeo de plantillas, el rediseño de flujos de trabajo, la revisión de seguridad y las pruebas pueden generar trabajo recurrente incluso cuando la interfaz técnica es estándar. Los datos de implementación deben mostrar horas por rol, tiempo transcurrido, esperas por dependencias, defectos y soporte posterior a la puesta en marcha.

La escritura de retorno merece una vía de control separada. El sistema debe confirmar el paciente, el encuentro, el tipo de documento, el autor, la versión y la aprobación final. Debe impedir escrituras duplicadas u obsoletas y preservar una pista de auditoría. Las escrituras fallidas necesitan una cola visible y una recuperación con responsabilidad asignada. El contenido clínico no debe desaparecer en un registro de integración genérico.

El modelo de diligencia debida debe valorar la interoperabilidad mediante evidencia: menor tiempo hasta la puesta en producción, menor coste de implementación, menos defectos, mayor adopción, menor carga de soporte y una expansión más sencilla. El número de conectores por sí solo puede exagerar la preparación cuando las integraciones son antiguas, poco utilizadas o se mantienen manualmente.

12. Convertir la carga de implementación en un coste total hasta la puesta en marcha

Los clientes compran un cambio que funciona, no un modelo aislado. El coste total hasta la puesta en marcha incluye la revisión de seguridad y legal, el gobierno clínico, la adquisición, la integración, la configuración, el diseño de flujos de trabajo, la formación, las comunicaciones, el soporte, la medición y la ejecución en paralelo. Estos costes pueden recaer en el proveedor, el cliente, el socio de implementación o el proveedor de historia clínica electrónica (EHR). El inversor debe capturar el coste completo del sistema e identificar quién paga.

La implementación debe descomponerse en etapas repetibles: cualificación, contratación, aprobación de datos y seguridad, construcción técnica, configuración, revisión de seguridad clínica, piloto, formación, puesta en marcha, monitorización y escalado. Para cada etapa, la empresa debe proporcionar la mediana y la distribución del tiempo transcurrido, las horas internas, las horas del cliente, los bloqueos, el retrabajo y el abandono. Los promedios pueden ocultar una cola larga que consume caja y atención de la dirección.

La curva de costes debe separar la inversión fija en la plataforma, el trabajo de producto reutilizable y la mano de obra específica para el cliente. Las primeras cohortes pueden ser costosas mientras la empresa aprende. Las cohortes posteriores deben mostrar evidencia de un esfuerzo decreciente para una complejidad comparable. El crecimiento creado añadiendo personal de implementación al mismo ritmo que los ingresos tiene una economía distinta de la repetibilidad impulsada por el producto.

La carga para el cliente afecta a la adopción y la renovación incluso cuando no aparece en el coste de ingresos del proveedor. Los clínicos pueden dedicar tiempo a revisar, corregir y aprender. Los equipos de informática clínica pueden mantener plantillas y gobierno. Los equipos de TI pueden operar interfaces. La referencia del cliente debe comprobar si el beneficio materializado supera esta carga.

Los valores son hipotéticos; la diligencia debida en curso exige evidencia de horas por cliente, costes en efectivo y tiempo transcurrido.

Tabla 4. Matriz de responsabilidad y costes de integración

La matriz debe completarse para cada segmento de cliente relevante y entorno de EHR.

13. Reconstruir la economía del cliente a partir de cohortes y uso

El valor anual contratado no demuestra fundamentos económicos duraderos. El inversor debería construir cohortes por periodo de inicio, segmento, producto, geografía, EHR, complejidad de despliegue y tipo de contrato. Cada cohorte debería mostrar valor contratado, valor activo, uso, expansión, contracción, churn, coste de implementación, coste de soporte, coste de nube y modelos, margen bruto, cobros y concentración de clientes.

El puente comienza con usuarios o encuentros elegibles, usuarios activados, uso activo, finalización exitosa del flujo de trabajo, resultado revisado y uso sostenido. Las licencias por asiento pueden sobrestimar el valor cuando el uso es bajo. El precio por encuentro puede sobrestimar la previsibilidad cuando cambian el volumen o la mezcla de especialidades. El precio empresarial puede ocultar usuarios intensivos no rentables. El modelo comercial debería conciliar la unidad de precio con los generadores de valor y coste.

La retención debería medirse sobre varias bases. La retención de logos captura la continuidad de la relación. La retención bruta de ingresos excluye la expansión. La retención neta de ingresos incluye expansión y contracción. La retención de uso muestra si el producto sigue integrado. La retención de margen comprueba si los ingresos renovados siguen siendo económicos tras inferencia, soporte e integración. Las definiciones y el tratamiento de divisas deberían ser coherentes.

La expansión exige evidencia causal. Un cliente puede añadir clínicos porque el piloto funcionó, porque se abrió un presupuesto separado o porque el proveedor aplicó un descuento a una conversión empresarial. La expansión hacia codificación, bandeja de entrada o voz del paciente puede tener un comprador, una revisión de riesgos y un modelo de soporte diferentes. El inversor debería separar la escala del mismo producto de las ventas cruzadas de productos.

Las referencias de clientes deberían poner a prueba el comportamiento contrafactual. ¿Renovaría el cliente al precio actual? ¿Qué flujo de trabajo medible cambió? ¿Qué usuarios se benefician y cuáles no? ¿Qué carga persiste? ¿Qué fallo del producto provocaría su retirada? El entusiasmo de las referencias debería conciliarse con las facturas, el uso y las decisiones de renovación.

14. Poner a prueba la calidad de los ingresos, el poder de fijación de precios y el margen bruto

La calidad de los ingresos depende de contratos exigibles, estado de despliegue, aceptación, uso, renovación, cobro y coste de entrega. Las contrataciones pueden incluir pilotos, derechos de cancelación, módulos futuros o volúmenes contingentes. La diligencia debida debería conciliar los contratos firmados con los ingresos reconocidos, las facturas, el efectivo y la utilización activa por cliente.

La fijación de precios debería reflejar la unidad de valor del cliente y, al mismo tiempo, seguir siendo observable y gobernable. El precio por clínico es sencillo, pero puede desvincularse del volumen de encuentros. El precio por encuentro alinea el uso, pero genera variabilidad de volumen. El precio empresarial favorece la previsibilidad presupuestaria, aunque exige controles para el uso intensivo. El precio vinculado a resultados puede resultar atractivo cuando la medida, la línea base y la atribución son creíbles. Las estructuras híbridas pueden encajar en distintos flujos de trabajo.

El poder de fijación de precios debería ponerse a prueba mediante el historial de renovaciones, los descuentos, las sustituciones por competidores, las concesiones en compras y la disposición a ampliar. Un precio de tarifa alto con créditos de implementación extensos, pilotos gratuitos o módulos incluidos en el paquete puede dar lugar a un precio neto más débil. El inversor debería calcular el precio efectivo después de incentivos y compromisos de servicio.

El margen bruto debería incluir voz, modelo fundacional, almacenamiento, observabilidad, tarifas de EHR, soporte, operaciones clínicas, implementación, éxito del cliente y royalties de terceros cuando sean atribuibles a la entrega. El desarrollo capitalizado y la política de asignación deberían entenderse por separado. Las reducciones de precios de inferencia de los proveedores pueden mejorar el margen, mientras que el crecimiento del uso, un contexto mayor, resultados más ricos o la redundancia pueden compensar el beneficio.

La compañía debería demostrar margen por cohorte y producto. Los clientes maduros deberían revelar el perfil de soporte y cómputo en estado estacionario. Los productos nuevos pueden tener un margen inferior mientras maduran la evidencia y el flujo de trabajo. El modelo de valoración debería reflejar el tiempo y la inversión necesarios para alcanzar el margen objetivo, en lugar de aplicar una referencia de software por etiqueta.

Los valores son unidades de índice hipotéticas y no representan una referencia de mercado ni una previsión.

15. Separar la evidencia clínica de las afirmaciones de marketing

La solidez de la evidencia depende del diseño. Un caso práctico de un proveedor puede establecer viabilidad y experiencia del cliente. Un estudio antes-después puede describir el cambio, pero sigue expuesto a selección, momento e iniciativas concurrentes. Un estudio observacional emparejado puede mejorar la comparación, aunque sigue sujeto a confusión. Un ensayo aleatorizado puede reforzar la inferencia causal para su producto, usuarios, periodo y resultados probados. Ningún estudio individual demuestra todas las especialidades, clientes o versiones de producto.

El inversor debe construir una matriz de correspondencia entre afirmaciones y evidencia. Cada afirmación clínica, de flujo de trabajo y económica recibe una población objetivo, un criterio de valoración, un diseño de estudio, una versión, un comparador, un resultado, una limitación y una redacción comercial autorizada. La evidencia sobre el tiempo de documentación no demuestra automáticamente una reducción del agotamiento profesional, una mayor capacidad para atender pacientes, una mejor calidad de las notas ni una mejora de los ingresos.

La revisión rápida de 2025 de los escribas ambientales AI encontró solo seis estudios del mundo real elegibles de un conjunto de búsqueda mucho mayor y reportó evidencia escasa, estandarización heterogénea y efectos limitados en la productividad.[15] Una revisión sistemática posterior identificó igualmente beneficios de implementación junto con variación en la precisión, ediciones manuales y lagunas de evaluación.[18] Estas revisiones respaldan una recopilación disciplinada de evidencia, no una conclusión para toda la categoría.

Un ensayo aleatorizado pragmático con 238 médicos ambulatorios probó dos aplicaciones de escriba ambiental frente a la atención habitual y reportó resultados específicos de cada aplicación.[16] Otra comparación en el servicio de urgencias encontró una calidad de las notas similar o inferior y una mayor contribución del clínico en las notas generadas por AI frente a escribas humanos en ese entorno.[17] Estos estudios muestran por qué importan el comparador, el entorno, el usuario y la métrica.

La empresa debe mantener evidencia posterior al despliegue. Los cambios de versión, las nuevas especialidades, los idiomas, los sistemas de HCE y las acciones del flujo de trabajo pueden alterar el rendimiento. El monitoreo debe incluir adopción, ediciones, errores, incidentes, subgrupos, soporte y resultados de clientes. Las afirmaciones comerciales deben ajustarse al conjunto de evidencia aprobado.

16. Examinar la propiedad intelectual, la ventaja en datos y la defensibilidad

La defensibilidad puede surgir del diseño del flujo de trabajo, la distribución, las integraciones, los sistemas de evaluación, los derechos sobre datos propietarios, la confianza clínica, la capacidad regulatoria y la evidencia operativa. Un modelo por sí solo puede ser replicable u obtenerse de un proveedor upstream. El inversor debe identificar qué activos siguen siendo valiosos si un modelo fundacional mejora, los precios caen o los clientes obtienen funcionalidades similares de una plataforma establecida.

La revisión de PI debe abarcar la cesión de empleados y contratistas, la PI preexistente, el software de código abierto, las licencias de modelos y conjuntos de datos, los comentarios de clientes, las patentes, las marcas, los nombres de dominio, la procedencia del código y las restricciones en alianzas comerciales. El código y el contenido generados deben evaluarse conforme a la ley y el contrato aplicables. Los componentes materiales deben tener un propietario claro y un uso comercial permitido.

Una ventaja en datos exige datos lícitos, contractualmente permitidos y técnicamente utilizables. Un gran volumen es insuficiente cuando los derechos prohíben el entrenamiento, las etiquetas son débiles, las poblaciones son estrechas o las versiones no pueden vincularse con los resultados. La empresa debe explicar cómo los datos mejoran una capacidad definida y cómo se mide esa mejora. Los datos específicos de un cliente pueden generar costes de cambio sin sustentar un modelo transferible.

La infraestructura de evaluación puede ser un activo duradero. Los conjuntos de pruebas curados, las taxonomías de errores, la adjudicación clínica, el análisis de subgrupos, el monitoreo en producción y los controles de liberación pueden acelerar una mejora segura. Su valor depende de la representatividad, los derechos, la actualidad y la reproducibilidad.

El inversor debe realizar una prueba de sustitución. Si cambiara el modelo de voz o de lenguaje upstream, ¿qué queda? Si un proveedor de HCE lanzara una funcionalidad competidora, ¿qué ventaja de flujo de trabajo, evidencia, integración o distribución protegería la renovación? La defensibilidad debe describirse como un mecanismo económico probado.

17. Evaluar la organización, la gobernanza y la capacidad de despliegue

La organización debe ajustarse al riesgo y al modelo operativo del producto. Las capacidades relevantes pueden incluir aprendizaje automático, ingeniería de voz, informática clínica, gestión de producto, seguridad, privacidad, asuntos regulatorios, seguridad clínica, integraciones, implementación, éxito del cliente y experiencia en el ciclo de ingresos. La combinación necesaria depende del uso previsto y del segmento de clientes.

El análisis de personas clave debe identificar quién es responsable de la arquitectura del modelo, el juicio clínico, los sistemas de calidad regulados, las integraciones principales, las relaciones con clientes y la respuesta a incidentes. El conocimiento debe evidenciarse en la documentación, los procesos de revisión y la sucesión, en lugar de concentrarse en un fundador o en unos pocos ingenieros. Los planes de remuneración, retención y contratación deben alinearse con el caso de expansión.

La gobernanza debe conectar el lanzamiento de productos, la seguridad clínica, la privacidad, la seguridad y las afirmaciones comerciales. Un comité de lanzamiento puede exigir una evaluación completada, revisión de peligros, pruebas de seguridad, documentación, preparación del soporte y comunicación al cliente. Las excepciones deben tener un aprobador designado, una justificación, una fecha de caducidad y un plan de seguimiento.

Los incentivos de ventas requieren revisión. Los equipos pueden ser recompensados por valor contratado antes de la aprobación de seguridad, la puesta en producción o el uso sostenido. Las afirmaciones sobre el producto pueden superar a la evidencia cuando la presión competitiva es alta. La retribución y los hitos de aprobación deben respaldar ingresos que cumplan los requisitos y un despliegue seguro.

La información al consejo debe combinar rendimiento del producto, incidentes, derechos, situación regulatoria, despliegue en clientes, retención, margen y riesgo de la hoja de ruta. Un consejo de crecimiento necesita indicadores de alerta temprana: implementaciones estancadas, bajo uso activo, aumento de ediciones, regresiones en subgrupos, concentración del soporte, cambios en el coste de inferencia y exposición a la renovación. La gobernanza se convierte en un activo cuando produce decisiones oportunas y evidencia creíble para los clientes.

18. Traducir los hallazgos en valoración y financiación

Cada hallazgo confirmado debe cambiar el flujo de caja, los plazos, el riesgo, la opcionalidad o la estructura de la transacción. Una curva de implementación más lenta retrasa los ingresos y consume capacidad de servicios. Una mayor carga de revisión puede debilitar la adopción. Unos derechos de datos restringidos pueden limitar la mejora del modelo o el alcance geográfico. La concentración de proveedores upstream puede afectar el margen bruto y la resiliencia. Una reclasificación regulatoria puede exigir evidencia, sistemas de calidad y ciclos de venta más largos.

El modelo de valoración debe conectar el pipeline, el valor contratado, la puesta en producción, el uso activo, la retención, la expansión y el margen de contribución. Las variables de escenario deben incluir el ciclo de seguridad y compras, la capacidad de implementación, el coste de inferencia, la concentración de clientes, la renovación, el precio, la mezcla de productos y la inversión en evidencia. El caso base de la dirección debe conciliarse con el comportamiento histórico de las cohortes.

Debe evitarse la doble contabilización. Una puesta en producción más lenta ya puede reducir los ingresos y la caja. El mismo problema no debería recibir un descuento adicional en el múltiplo salvo que persista una incertidumbre residual. Un mayor coste de soporte ya puede reducir el margen. Los revisores de finanzas y de producto deben aprobar juntos el puente causal.

Las necesidades de financiación pueden aumentar por retrasos en el cobro, mano de obra de implementación, estudios clínicos, remediación de seguridad, sistemas de calidad regulados, alianzas con EHR y expansión geográfica. El modelo de fuentes y usos debe incluir estas inversiones. Una ronda de capital privado de crecimiento dimensionada solo para la contratación de ventas puede infrafinanciar la evidencia y la capacidad de despliegue.

Los comparables de valoración requieren una normalización cuidadosa. Las empresas de software sanitario difieren en su condición regulatoria, contenido de servicios, concentración de clientes, crecimiento, margen bruto, retención y consumo de caja. Un múltiplo de ingresos titular puede ocultar la calidad del producto y de las cohortes. El comité de inversiones debe recibir un puente transparente desde la evidencia hasta los supuestos y el valor.

19. Convertir la diligencia debida en protecciones de la transacción y el plan de titularidad

La protección de la transacción debe seguir al riesgo causal. Una condición de cierre puede exigir la entrega de un consentimiento de cliente, la remediación de seguridad, un contrato clave, una presentación regulatoria o una versión validada. El precio y los importes obtenidos pueden reflejar una brecha medible de ingresos, caja o pasivos. El depósito en garantía, la retención, la garantía, la indemnización o el covenant pueden asignar una exposición residual definida, con sujeción a la legislación aplicable y al asesoramiento cualificado.

Las declaraciones y garantías deben abordar la propiedad, las licencias, los derechos sobre datos, la privacidad, la seguridad, la situación regulatoria, el código abierto, los contratos con clientes, las dependencias del modelo, los incidentes y las reclamaciones. Su alcance debe corresponder a la evidencia y al modelo de negocio. Una garantía genérica de cumplimiento puede ser más débil que un anexo de finalidades de tratamiento, subencargados, incidentes y limitaciones conocidos.

El plan de titularidad debe existir antes de la firma. Las prioridades iniciales pueden incluir congelar las versiones de producto y de modelo, preservar datos y registros, confirmar las obligaciones con clientes, asegurar la continuidad del personal clave, validar la monitorización, revisar flujos de trabajo de alto riesgo, conciliar la economía de las cohortes y cerrar brechas de evidencia. La integración con una plataforma matriz debe avanzar mediante hitos de aprobación clínicos, de seguridad y de clientes.

El consejo debe distinguir el riesgo aceptado de la diligencia debida inconclusa. Cada elemento aceptado recibe un responsable, presupuesto, hito, evidencia y derecho de decisión. Los elementos materiales no resueltos pueden requerir diligencia adicional, una condición, un cambio de valoración o rechazo.

Tabla 5. Hitos de aprobación del comité de inversiones y respuestas ante fallos

El diseño de las puertas debería reflejar la materialidad de la transacción, el uso previsto y la autoridad delegada.

20. Establecer puertas de rechazo y un sistema de diligencia debida repetible

Algunos hallazgos deberían detener o acotar la inversión. Entre los ejemplos se incluyen la imposibilidad de establecer derechos para una finalidad de tratamiento esencial, errores clínicamente materiales sin una vía de detección eficaz, declaraciones reguladas no respaldadas, separación de inquilinos no resuelta, cotejo de identidad no fiable, evaluación no reproducible, concentración de clientes sin evidencia creíble de retención o una economía unitaria que siga siendo negativa en despliegues comparables maduros.

Las puertas de rechazo deberían ser explícitas antes de la presentación al equipo directivo. Esto reduce el sesgo de confirmación y evita que la presión del calendario convierta la evidencia faltante en una comodidad asumida. Una puerta fallida puede dar lugar a un rechazo, a un perímetro de producto más reducido, a una valoración inferior, a una inversión por etapas, a una condición o a un plan de remediación financiado. La respuesta debería reflejar control y materialidad.

El sistema de diligencia debida debería conservar un registro de preguntas, un índice de evidencia, un registro de derechos sobre datos, un registro de modelos, resultados de evaluación, mapas de flujo de trabajo, un modelo de cohortes, un registro de hallazgos y un registro de decisiones. Cada hallazgo debería incluir fuente, versión, causalidad, materialidad, responsable, revisor, efecto económico y respuesta en la transacción. Los resultados deberían seguir siendo trazables hasta la evidencia.

Tras la inversión, el tiempo real de puesta en marcha, la adopción, las ediciones, los incidentes, la retención, la expansión, el margen bruto y la caja pueden compararse con los supuestos de diligencia debida. Esta retroalimentación revela qué indicadores predijeron el rendimiento y qué controles eran débiles. El aprendizaje de la cartera debería conservar el tipo de producto, el entorno asistencial, el comprador, el EHR, el riesgo de flujo de trabajo, la geografía y la versión, de modo que la evidencia no se generalice más allá de su contexto.

Las lagunas de investigación siguen siendo sustanciales. Los trabajos futuros deberían examinar los resultados a largo plazo para pacientes y clínicos, el rendimiento por subgrupos, los efectos posteriores en la codificación y las reclamaciones, la autonomía segura, el despliegue multilingüe, la deriva del modelo, el cambio de clientes y la economía de la competencia nativa de EHR. Los inversores de crecimiento pueden contribuir exigiendo una evaluación transparente y apoyando la infraestructura de evidencia como parte del plan de creación de valor.

La prueba de decisión es sencilla: ¿puede el inversor reproducir cómo el producto convierte datos autorizados en una mejora controlada del flujo de trabajo, cómo esa mejora se transforma en valor retenido para el cliente y cómo la empresa obtiene un margen sostenible mientras cumple sus responsabilidades clínicas y regulatorias? La evidencia que supera esta cadena respalda una tesis de inversión. Las rupturas en la cadena identifican la siguiente pregunta de diligencia debida o el motivo para detenerse.

Referencias

1. Organización Mundial de la Salud, Ética y gobernanza de la inteligencia artificial para la salud, 28 de junio de 2021, https://www.who.int/publications/i/item/9789240029200
2. Organización Mundial de la Salud, Ética y gobernanza de la inteligencia artificial para la salud: Orientación sobre grandes modelos multimodales, 25 de marzo de 2025, https://www.who.int/publications/i/item/9789240084759
3. Administración de Alimentos y Medicamentos de los EE. UU., Software de apoyo a la decisión clínica, Orientación final, enero de 2026, https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
4. Administración de Alimentos y Medicamentos de los EE. UU., Orientaciones con contenido sobre salud digital, https://www.fda.gov/medical-devices/digital-health-center-excellence/guidances-digital-health-content
5. Administración de Alimentos y Medicamentos de los EE. UU., Ciberseguridad en dispositivos médicos: consideraciones del sistema de gestión de la calidad y contenido de las presentaciones previas a la comercialización, febrero de 2026, https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket
6. Oficina del Coordinador Nacional de Tecnología de la Información en Salud, Regla final HTI-1, https://healthit.gov/regulations/hti-rules/hti-1-final-rule/
7. Departamento de Salud y Servicios Humanos de los EE. UU., Entidades cubiertas y socios comerciales, https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html
8. Departamento de Salud y Servicios Humanos de los EE. UU., Computación en la nube e información de salud electrónica protegida, https://www.hhs.gov/hipaa/for-professionals/faq/2075/may-a-hipaa-covered-entity-or-business-associate-use-cloud-service-to-store-or-process-ephi/index.html
9. Unión Europea, Reglamento (UE) 2024/1689 por el que se establecen normas armonizadas sobre inteligencia artificial, https://eur-lex.europa.eu/eli/reg/2024/1689/oj
10. Unión Europea, Reglamento (UE) 2025/327 sobre el Espacio Europeo de Datos Sanitarios, https://eur-lex.europa.eu/eli/reg/2025/327/oj/
11. Agencia Reguladora de Medicamentos y Productos Sanitarios del Reino Unido, software e inteligencia artificial como producto sanitario, https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
12. NHS England, estándares de gestión del riesgo clínico DCB0129 y DCB0160, https://digital.nhs.uk/data-and-information/information-standards/governance/latest-activity/standards-and-collections/dcb0129-clinical-risk-management-its-application-in-the-manufacture-of-health-it-systems
13. Instituto Nacional de Estándares y Tecnología, Marco de Gestión de Riesgos de Inteligencia Artificial y Perfil de AI generativa, https://www.nist.gov/itl/ai-risk-management-framework
14. Foro Internacional de Reguladores de Dispositivos Médicos, software como dispositivo médico: evaluación clínica, 21 de septiembre de 2017, https://www.imdrf.org/documents/software-medical-device-samd-clinical-evaluation
15. Kanaparthy NS et al., Síntesis de evidencia del mundo real sobre asistentes digitales de documentación que utilizan escucha ambiental e inteligencia artificial generativa para flujos de trabajo de documentación clínica: revisión rápida, JMIR AI, 2025, https://pubmed.ncbi.nlm.nih.gov/41071988/
16. Shah SJ et al., Asistentes de documentación con AI ambiental en la práctica clínica: ensayo aleatorizado, 2025, https://pubmed.ncbi.nlm.nih.gov/41497288/
17. Morey J et al., Inteligencia artificial ambiental frente a asistentes de documentación humanos en el servicio de urgencias, Annals of Emergency Medicine, 2025, https://pubmed.ncbi.nlm.nih.gov/41251650/
18. Implementación clínica de asistentes de documentación con inteligencia artificial en la atención sanitaria: revisión sistemática, 2025, https://pubmed.ncbi.nlm.nih.gov/40306686/
19. Comisión Federal de Comercio de EE. UU., Regla de notificación de violaciones de datos de salud, regla final, 30 de mayo de 2024, https://www.ftc.gov/legal-library/browse/rules/health-breach-notification-rule
20. HL7 International, descripción general de FHIR, https://www.hl7.org/fhir/overview.html