MHMDA de Washington para SaaS de Salud Mental: Cumplimiento Fuera de HIPAA
Si opera una aplicación de terapia, un rastreador de estado de ánimo, un producto de diario, una plataforma de uso de sustancias, una comunidad de apoyo entre pares, un chatbot de salud mental con IA, o cualquier SaaS de salud conductual que toque a consumidores de Washington, el Chapter 19.373 RCW probablemente lo alcanza, y HIPAA normalmente no. La mayoría de los SaaS de salud mental están totalmente fuera de HIPAA porque el operador no es ni un Covered Entity ni un Business Associate. La My Health, My Data Act (MHMDA) de Washington llena el vacío y trata el estado de salud mental, el ánimo, los síntomas, el diagnóstico, la búsqueda de tratamiento, las entradas de diario y las inferencias como Consumer Health Data. Una infracción es una violación per se de la Consumer Protection Act bajo RCW 19.373.090. Este hub recorre la superficie de cumplimiento real para productos de salud conductual.
Por qué el SaaS de salud mental es la categoría MHMDA de mayor riesgo
La MHMDA define Consumer Health Data en RCW 19.373.010 como información personal vinculada o razonablemente vinculable a un consumidor que identifica el estado de salud física o mental pasado, presente o futuro, incluyendo inferencias. La salud mental se nombra expresamente. La definición alcanza las categorías obvias (diagnóstico, tratamiento, síntomas, medicación) y también alcanza las entradas y salidas de la mayoría de los productos SaaS de salud mental: registros de ánimo, entradas de diario, marcadores de sueño y estrés, resultados de cuestionarios PHQ-9 / GAD-7 / PCL-5, banderas de lenguaje de crisis y cualquier inferencia de IA derivada de entradas no clínicas.
Tres razones por las que esta categoría conlleva más exposición que un SaaS de bienestar común. Primero, la mayoría de los productos de salud mental invitan explícitamente al usuario a divulgar el estado de salud mental, lo que elimina cualquier argumento de "nunca recopilamos datos de salud". Segundo, los SDK de terceros (analíticas, session replay, píxeles de atribución, CRM, APIs de IA, herramientas de atención al cliente) comúnmente reciben contenido que es Consumer Health Data, lo que convierte píxeles de marketing y llamadas a APIs de IA en eventos de sharing bajo la MHMDA. Tercero, el puente per se a la CPA en RCW 19.373.090 significa que el demandante no tiene que probar el impacto de interés público bajo Hangman Ridge; un derecho privado de acción con triplicación discrecional limitada a $25,000 y honorarios unidireccionales se adhiere automáticamente.
La MHMDA puede aplicar cuando HIPAA no aplica
HIPAA alcanza a Covered Entities (planes de salud, healthcare clearinghouses, healthcare providers que transmiten información de salud electrónicamente en transacciones HIPAA) y sus Business Associates. Un SaaS de salud mental orientado al consumidor sin una relación con un proveedor normalmente no es ninguno. Los chatbots de terapia direct-to-consumer, las aplicaciones de diario, los rastreadores de estado de ánimo, las aplicaciones de apoyo entre pares y los asistentes de salud mental con IA típicamente están fuera de HIPAA. La exención en RCW 19.373.100 es específica a los datos, no general a la entidad: incluso una aplicación que tiene algunas relaciones cubiertas por HIPAA todavía debe cumplir con los deberes de la MHMDA sobre cualquier Consumer Health Data que no sea PHI en una transacción cubierta.
Para un análisis lado a lado de superposición, exenciones y la postura práctica para productos híbridos, consulte mi HIPAA vs MHMDA para SaaS de Salud Mental.
La pila de cumplimiento para SaaS de salud conductual
- Consumer Health Data Privacy Policy separada bajo RCW 19.373.020. Documento independiente, vinculado de forma prominente desde la página principal, distinto de la política de privacidad general. Cinco divulgaciones sustantivas incluyendo la lista específica de afiliados. Agrupar las divulgaciones de la MHMDA en una política de privacidad general es el patrón de falla más común.
- Consentimiento de dos capas bajo RCW 19.373.030. Consentimiento afirmativo para la recopilación más un consentimiento separado y distinto para el sharing. Desagrupado de la aceptación de los términos generales. Una sola casilla de "Acepto la política de privacidad" es insuficiente.
- Derechos operativos y flujo de trabajo de eliminación bajo RCW 19.373.040. Confirmación, acceso con la lista de destinatarios terceros, retirada, eliminación (incluida la notificación aguas abajo a procesadores y terceros), y un proceso de apelación con una decisión por escrito dentro de 45 días. Esto debe ser operativo, no solo texto de política. Una solicitud de eliminación que no se pueda ejecutar efectivamente contra el AI vector store, el almacén de analíticas y el CRM es una infracción en la práctica.
- Seguridad de reasonable-care bajo RCW 19.373.050. Restringir el acceso solo a los empleados, procesadores y contratistas para quienes el acceso es necesario para los fines consentidos. Controles administrativos, técnicos y físicos al nivel o por encima del baseline de la industria.
- Contratos de procesador conformes a la MHMDA bajo RCW 19.373.060. Instrucciones vinculantes, fines permitidos delimitados, obligación de reasonable assistance. Los DPAs estándar de GDPR y los acuerdos de proveedor de servicios de CCPA normalmente necesitan un addendum de Washington. Un procesador que se aparta de las instrucciones se convierte en una entidad regulada para los datos en cuestión.
- Prohibición de geofence bajo RCW 19.373.080. Prohibición absoluta de geofencing dentro de los 2,000 pies de una instalación de healthcare presencial para identificar o rastrear consumidores, recopilar datos de salud o enviar notificaciones. Los productos de salud conductual con anuncios basados en ubicación o disparadores push deben auditar las configuraciones de la plataforma de anuncios contra las direcciones de instalaciones psiquiátricas, centros de tratamiento y clínicas de metadona.
- Puente per se a la CPA bajo RCW 19.373.090. Cualquier infracción es automáticamente una violación de la Washington Consumer Protection Act. El elemento de interés público se da por declaración; el demandante todavía debe alegar perjuicio y causación.
Subcategorías de SaaS de salud mental
El perfil de exposición difiere por subcategoría. Mantengo una página de problemas para cada una para que el análisis de brechas siga siendo específico a su producto.
- Cumplimiento MHMDA para aplicación de terapia: directorios de proveedores con licencia, mensajería asíncrona, sesiones de video y el análisis de superposición HIPAA-MHMDA para modelos híbridos.
- Cumplimiento MHMDA para rastreador de estado de ánimo: registros de ánimo, marcadores de sueño / estrés, motores de inferencia y evaluaciones estilo PHQ-9 fuera de cualquier relación clínica.
- Cumplimiento MHMDA para aplicación de diario: entradas de diario en texto libre como la categoría de entrada de mayor sensibilidad, riesgo de resumen por IA y mapeo de procesadores para funciones de IA.
- Cumplimiento MHMDA para aplicación de uso de sustancias: rastreadores de sobriedad, aplicaciones de comunidad de recuperación y el carve-out de 42 CFR Part 2 en RCW 19.373.100.
- Privacidad del chatbot de salud mental con IA: APIs de modelo de IA, postura sobre training data, ventanas de retención, transmisión de banderas de crisis y la línea de marca de profesional con licencia.
- Revisión de privacidad de SaaS de salud conductual: productos B2B y orientados a proveedores clínicos, portales de proveedores y análisis de HIPAA Business Associate superpuesto sobre la MHMDA.
- HIPAA vs MHMDA para SaaS de salud mental: cobertura lado a lado, mecánica de exención y la postura práctica para productos híbridos.
Nota práctica de Sergei
La categoría de SaaS de salud mental es donde la MHMDA realmente cambia el comportamiento en la práctica. El producto invita al usuario a divulgar el estado de salud mental; la plataforma se integra con analíticas, atribución, una API de modelo de IA, un CRM y un widget de soporte; y casi nada de eso ha sido mapeado contra el estatuto de Washington. La solución no es texto de política aspiracional. Es un mapa de proveedores, contratos de procesador conformes a la MHMDA bajo RCW 19.373.060, un flujo de trabajo de eliminación operativo que realmente alcance el AI vector store y el almacén de analíticas, una Consumer Health Data Privacy Policy separada bajo RCW 19.373.020, y consentimiento de dos capas al registrarse. Reviso productos SaaS de salud mental bajo licencia de California. Esto es trabajo de asesoría regulatoria, no representación en Washington.
Qué enviar para una revisión por escrito
- URL de la política de privacidad actual más una captura con fecha; la política de Consumer Health Data si la publica por separado.
- Captura de pantalla de la página principal en escritorio y móvil que muestra el enlace a la política.
- Capturas de pantalla del UX de consentimiento: registro, banners de consentimiento dentro de la aplicación, toggles de sharing, divulgaciones de funciones de IA, mecanismo de retirada.
- Inventario de datos de las categorías de Consumer Health Data (registros de ánimo, entradas de diario, resultados de evaluación, contenido de chat, categorías inferidas).
- Mapa de proveedores: analíticas, session replay, atribución, píxeles de anuncios, CRM, APIs de modelo de IA, widgets de soporte, procesadores en la nube, sub-procesadores, más la plantilla de DPA actual.
- Postura HIPAA: ¿es Covered Entity, Business Associate o ninguno, y qué campos de datos, si los hay, están dentro de una relación cubierta por HIPAA?
- Descripción breve del producto: qué hace el producto, qué datos recopila, qué usuarios de Washington toca, qué funciones de IA incorpora.
Qué reviso y qué cubren los niveles
El trabajo se divide en un memo de alcance, un memo más correcciones de procesador y consentimiento, y un memo más una Consumer Health Data Privacy Policy redactada. Para productos de salud conductual con múltiples integraciones, el paquete SaaS incluye el mapa de proveedores, el lenguaje de procesador, la política y el flujo de consentimiento bajo licencia de California. Para el paquete SaaS más grande, escríbame para confirmar disponibilidad actual y alcance.
Fuentes primarias
Fuentes estatutarias recuperadas el 2026-05-19 desde app.leg.wa.gov: RCW 19.373.010, .020, .030, .040, .050, .060, .080, .090, .100.
Recurso educativo. Sergei Tokmakov es abogado de California (CA Bar #279869) actualmente solicitando admisión al Washington State Bar. Nada en esta página crea una relación abogado-cliente ni constituye asesoría legal de Washington. Un abogado admitido en Washington debe verificar el texto operativo del estatuto antes de basarse en él en un asunto activo.