Logotipo de Zephyrnet

Navegando por el panorama regulatorio: autorización de la FDA y protección de patentes para software como dispositivo médico – Knobbe Medical

Fecha:

El software se usa cada vez más como un dispositivo médico, transformando la industria de la salud con el objetivo de mejorar los resultados de los pacientes. Sin embargo, desarrollar software como dispositivo médico implica navegar marcos regulatorios complejos y en evolución. Los marcos regulatorios pueden complicar el ya complejo problema de la innovación en software y, a menudo, pueden pasar por alto las distinciones entre software, inteligencia artificial, aprendizaje automático y aprendizaje profundo. Se sabe que el desarrollo en cada una de estas áreas avanza a pasos agigantados y puede ocurrir en cualquier punto, desde la recopilación de datos hasta la prueba, el diseño, el desarrollo o la implementación. Sin embargo, como la participación humana genera oportunidades para mejoras tecnológicas, los puntos de contacto humanos también pueden generar errores y sesgos. Si alguna vez fue el caso de que las decisiones sobre la protección de la propiedad intelectual (PI) y/o la debida diligencia pudieran tomarse de manera intermitente o retrasada, este no es el caso hoy en día en el campo de los dispositivos médicos basados ​​en software.

Foto del Instituto Nacional del Cáncer en Unsplash

Este artículo proporciona una actualización sobre cómo la FDA regula el software como dispositivo médico y explora las estrategias de propiedad intelectual disponibles para proteger los dispositivos médicos basados ​​en software. El conocimiento de los cambios en la FDA y cómo estos cambios pueden influir en su enfoque hacia la Oficina de Patentes son importantes para asegurar una ventaja competitiva para su negocio, pero también para lograr el objetivo declarado de mejorar los resultados de los pacientes. Se pueden introducir errores y sesgos en cada punto de contacto humano, desde la recopilación de datos hasta la implementación del algoritmo. El sesgo puede traducirse en malos resultados para los pacientes, y la FDA y las empresas que implementan las mejores prácticas buscarán internamente eliminar o reducir dicho sesgo. De manera análoga, una invención que funciona para eliminar el sesgo también puede merecer la protección de una patente y debe identificarse con anticipación para que se pueda obtener la protección adecuada. La evaluación continua de la investigación y el desarrollo de la PI y el sesgo es la ola del futuro.

Regulación de la FDA de software como dispositivo médico

La FDA clasifica los dispositivos médicos según los riesgos asociados en una de tres clases. Los dispositivos de Clase III de alto riesgo necesitan una Solicitud de aprobación previa a la comercialización (PMA) autorizada según la Sección 515 de la FFDCA antes de ser comercializados, mientras que otros dispositivos pueden ser autorizados según la Sección 510 de la FFDCA (tenga en cuenta que, a diferencia de la Sección 515, las patentes sobre los productos que reciben autorización de la Sección 510 no son elegibles para la extensión del plazo de la patente).

El software como dispositivo médico (SaMD) se define como "software destinado a ser utilizado para uno o más fines médicos que realizan estos fines sin ser parte de un dispositivo médico de hardware".[ 1 ] El software como dispositivo médico generalmente cae bajo 510k, pero determinar si un producto individual es “software como dispositivo médico” y es apropiado para una designación 510k se determina caso por caso y está fuera del alcance de este artículo. La FDA utiliza "atributos clave" para identificar un SaMD, incluido el nivel de dependencia o confianza de un usuario en la información de salida del dispositivo médico. Sin embargo, tenga en cuenta que la FDA gestiona una lista pública de dispositivos médicos que utilizan tecnologías de IA/ML aprobadas por el Centro de Dispositivos y Salud Radiológica de la FDA. La lista incluye actualmente más de 520 dispositivos, y una gran mayoría aprobados bajo la designación 510k. La FDA también hace una distinción entre software como dispositivo médico (SaMD), software en un dispositivo médico (SiMD) y software utilizado en la fabricación o mantenimiento de un dispositivo médico.

En parte debido a los desafíos para el desarrollo de IA mencionados anteriormente, la FDA está adaptando y probando programas piloto para adaptarse a los riesgos y cambios rápidos característicos de la industria. Una comisión reciente de IA recomendó un enfoque basado en el riesgo para la regulación de la IA, en el que las regulaciones "según sea necesario" se aplicarían a las aplicaciones de IA con un riesgo insignificante para la privacidad, la salud, la seguridad o los derechos fundamentales.[ 2 ] El programa piloto de precertificación de software (Pre-Cert) de la FDA es un programa diseñado para agilizar el proceso regulatorio para los desarrolladores de software como dispositivo médico (SaMD). El programa se basa en la idea de que el enfoque regulatorio debe centrarse en el proceso de desarrollo, más que en los productos individuales. Según el programa, los desarrolladores de SaMD pueden solicitar una certificación previa, lo que les permitiría llevar sus productos al mercado sin pasar por el proceso tradicional de revisión de la FDA. En lugar de revisar un dispositivo médico completo, la FDA evaluaría el proceso de desarrollo de software del desarrollador y determinaría si cumple con ciertos criterios de calidad y seguridad. Si se autoriza, al desarrollador se le otorgaría una certificación previa, lo que le permitiría llevar sus productos SaMD al mercado más rápido y con menos carga regulatoria. El programa piloto está actualmente en curso y varios desarrolladores de SaMD participan en el programa.

Participar en dicho programa podría afectar sus decisiones estratégicas con respecto a su propiedad intelectual. Por ejemplo, ¿cómo se identificará una idea valiosa y cuándo se presentará una solicitud de patente? Es posible que no sea apropiado retrasar estas decisiones hasta una presentación 510K. Además, una innovación que uno preferiría mantener como secreto comercial puede revelarse inevitablemente como parte de la debida diligencia en curso. Para proteger las innovaciones de software, las empresas que diseñan SaMD a menudo se enfrentan a la decisión de confiar en los secretos comerciales o en la protección de patentes. Ambos enfoques tienen sus ventajas y desventajas, y lograr el equilibrio adecuado entre ellos puede ser crucial.

Protección de la propiedad intelectual del software como dispositivo médico

En esta sección, exploraremos la protección de propiedad intelectual disponible para el software como dispositivo médico. SaMD puede estar cubierto tanto por patentes de utilidad como por patentes de diseño (que cubren la interfaz de usuario o la apariencia del software). La ley de patentes de EE. UU. que rodea la protección del software se ha ganado la reputación de ser más estricta en cuanto a la elegibilidad para las patentes de software, especialmente desde la decisión de Alice.[ 3 ] Sin embargo, AI ahora aparece en el 18% de todas las solicitudes de patentes de utilidad que recibe la USPTO. De hecho, hay muchas características de SaMD que aún son patentables, como métodos novedosos para mejorar la precisión o confiabilidad de los diagnósticos médicos o planes de tratamiento, y plataformas de software adaptables que se pueden adaptar a las necesidades específicas de los pacientes o contextos médicos.

El año pasado, en respuesta a una Orden Ejecutiva sobre competencia de precios de medicamentos, los examinadores de patentes de la USPTO realizaron una capacitación cruzada con la FDA para buscar toda la información que la FDA pone a disposición sobre productos farmacéuticos y dispositivos médicos. Se plantearon algunas preocupaciones a ambas agencias de que las empresas estaban haciendo declaraciones inconsistentes acerca de que sus productos constituían cambios modestos en la FDA mientras afirmaban innovaciones significativas en la USPTO. Sin embargo, observamos que pueden surgir declaraciones aparentemente inconsistentes simplemente porque algo puede no ser obvio según los estándares de la USPTO, pero aún así calificar como predecible y seguro para la FDA. El impacto de cualquier capacitación cruzada aún está por verse, y los examinadores actualmente revisan las listas del Libro Naranja y otra información disponible públicamente en las bases de datos de la FDA. La coordinación entre las declaraciones a la FDA y la USPTO destaca la importancia de un proceso riguroso de evaluación de propiedad intelectual durante todo el ciclo de vida del desarrollo de SaMD, desde la concepción hasta la aprobación de la FDA, y es necesario para proteger mejor las innovaciones de SaMD.

Como alternativa a la protección de patentes, las empresas que diseñan software como dispositivo médico pueden buscar secretos comerciales dirigidos, por ejemplo, a algoritmos utilizados para analizar datos médicos, código de software patentado y otra información confidencial. Los secretos comerciales se refieren a la información confidencial que una empresa mantiene en secreto para obtener una ventaja competitiva. La ruta del secreto comercial podría evitar los costos asociados con la presentación de una solicitud de patente, pero las empresas deberán memorizar y proteger los secretos comerciales de la divulgación, lo que incluye contar con procedimientos detallados para protegerse contra la divulgación de los secretos comerciales. Este proceso proactivo de identificación de su propiedad intelectual y registro de secretos comerciales, incluso si se excluye de la protección de patentes, es particularmente útil cuando un empleado deja la empresa y surge una disputa sobre la propiedad de la tecnología. El recurso legal por apropiación indebida de un secreto comercial está disponible if se toman medidas razonables para proteger los secretos comerciales, lo que incluye informar a los empleados que existen secretos comerciales en la organización y obtener el acuerdo de los empleados de que mantendrán cualquier información confidencial, incluidos los secretos comerciales, en estricta confidencialidad. Por lo general, estas restricciones se incluyen en los manuales de los empleados y los acuerdos laborales.

Estrategias para navegar el panorama regulatorio

En esta última sección, proporcionaremos una estrategia potencial para los desarrolladores que buscan navegar el complejo panorama legal y normativo que rodea al software como dispositivo médico. Como se mencionó anteriormente, recomendamos identificar proactivamente su propiedad intelectual, lo que puede implicar la presentación de solicitudes de patentes de manera temprana y frecuente. Una idea puede considerarse madura para ser patentada cuando cumple con los requisitos legales para la patentabilidad (como novedad y no obviedad) y está suficientemente desarrollado para ser descrito en una solicitud de patente; sin embargo, la madurez puede ser una determinación difícil.

Un enfoque valioso para abordar esta incertidumbre es presentar una solicitud de patente provisional que incluya toda la divulgación disponible en ese momento y actualizar la presentación durante el año de prioridad a medida que la invención evoluciona o se producen más datos de apoyo, un proceso denominado "provisional móvil". ” Una solicitud provisional permanece sin publicar durante un año, momento en el que puede convertirse en una solicitud de patente de utilidad o en una solicitud internacional (PCT). Al utilizar el enfoque provisional continuo, la solicitud provisional presentada originalmente se actualiza con los nuevos datos y divulgación y luego la nueva solicitud se presenta como una segunda solicitud provisional. Este proceso puede repetirse a lo largo del año de prioridad a medida que se disponga de más datos y divulgación, presentando sucesivas solicitudes provisionales. Tras la conversión de la primera solicitud provisional presentada en solicitud de utilidad o solicitud internacional, la solicitud de utilidad o solicitud internacional reivindicará prioridad sobre todas las solicitudes provisionales relacionadas presentadas sucesivamente y, de esta manera, se podrán proteger las realizaciones en evolución desarrolladas durante el año de prioridad. Debido a que las solicitudes provisionales no se publican, la presentación de una solicitud provisional también se puede utilizar para recordar la fecha de concepción de una invención o para recordar un secreto comercial. Por ejemplo, se puede conmemorar un secreto comercial en una solicitud provisional y abandonarla expresamente o permitir que caduque al no convertirla en una solicitud de utilidad o una solicitud internacional. Mediante este enfoque, la solicitud que tiene el secreto comercial no se publicará, pero se formalizará un registro del secreto comercial en la oficina de patentes. Finalmente, las mejores prácticas incluyen compartimentar las ideas que desea mantener como secreto comercial. Sin embargo, si se encuentra en un programa de precertificación de la FDA, por ejemplo, y sin querer divulga un secreto comercial, existe un período de gracia de un año para divulgaciones públicas durante el cual aún puede presentar solicitudes de patentes en los EE. UU. (aunque este período de gracia no es válido). aplicable en la mayoría de los países fuera de los EE. UU.).

En conclusión, el desarrollo de software como dispositivo médico es un proceso complejo que requiere una cuidadosa atención a los marcos normativos de la FDA y la USPTO. Sin embargo, al comprender cómo la FDA regula el software como dispositivo médico y la protección de patentes disponible, los desarrolladores pueden crear soluciones innovadoras que mejoren los resultados de los pacientes mientras protegen su propiedad intelectual.

[ 1 ] https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd

[ 2 ] https://www.uschamber.com/technology/u-s-chambers-ai-commission-report-highlights-the-promise-of-ai-while-calling-for-a-risk-based-regulatory-framework

[ 3 ] Alice Corp. Pty. Ltd. v. CLS Bank Int'l – 573 US 208, 134 S. Ct. 2347 (2014)

punto_img

Información más reciente

punto_img