Cómo los aseguradores y los planes de atención médica pueden empoderar a los miembros con inteligencia artificial generativa

En esta publicación, analizamos cómo la inteligencia artificial (IA) generativa puede ayudar a los miembros de los planes de seguro médico a obtener la información que necesitan. A muchos beneficiarios de planes de seguro médico les resulta difícil navegar por los complejos portales para miembros que ofrecen sus planes de seguro. Estos portales suelen requerir múltiples clics, filtros y búsquedas para encontrar información específica sobre sus beneficios, deducibles, historial de reclamos y otros detalles importantes. Esto puede generar insatisfacción, confusión y un aumento de las llamadas al servicio de atención al cliente, lo que da como resultado una experiencia deficiente tanto para los miembros como para los proveedores.

El problema surge de la incapacidad de las interfaces de usuario tradicionales para comprender y responder a las consultas en lenguaje natural de manera eficaz. Los miembros se ven obligados a aprender y adaptarse a la estructura y la terminología del sistema, en lugar de que el sistema esté diseñado para comprender sus preguntas en lenguaje natural y brindar información relevante sin problemas. IA generativa La tecnología, como los asistentes de IA conversacionales, puede resolver potencialmente este problema al permitir que los miembros hagan preguntas con sus propias palabras y reciban respuestas precisas y personalizadas. Al integrar la IA generativa impulsada por La roca madre del Amazonas y servicios de datos de AWS diseñados específicamente para ello, como Servicio de base de datos relacional de Amazon (Amazon RDS) en los portales de miembros, los aseguradores y los planes de atención médica pueden permitir a sus miembros encontrar la información que necesitan de manera rápida y sencilla, sin tener que navegar por varias páginas ni depender en gran medida de los representantes de servicio al cliente. Amazon Bedrock es un servicio completamente administrado que ofrece una selección de modelos de base (FM) de alto rendimiento de empresas líderes en inteligencia artificial como AI21 Labs, Anthropic, Cohere, Meta, Stability AI y Amazon a través de una API unificada, junto con un amplio conjunto de capacidades para crear aplicaciones de inteligencia artificial generativa con seguridad, privacidad e inteligencia artificial responsable.

La solución presentada en este artículo no solo mejora la experiencia de los miembros al ofrecer una interfaz más intuitiva y fácil de usar, sino que también tiene el potencial de reducir los volúmenes de llamadas y los costos operativos para los aseguradores y los planes de atención médica. Al abordar este problema, las organizaciones de atención médica pueden mejorar la satisfacción de los miembros, reducir la pérdida de clientes y optimizar sus operaciones, lo que en última instancia conduce a una mayor eficiencia y ahorro de costos.

Descripción general de la solución

En esta sección, profundizamos para mostrar cómo se puede utilizar la IA generativa y los modelos de lenguaje extenso (LLM) para mejorar la experiencia de los miembros mediante la transición de una búsqueda de reclamaciones basada en filtros tradicional a una búsqueda basada en indicaciones, que permite a los miembros hacer preguntas en lenguaje natural y obtener las reclamaciones o los detalles de los beneficios deseados. Desde una perspectiva amplia, la solución completa se puede dividir en cuatro pasos distintos: generación de texto a SQL, validación de SQL, recuperación de datos y resumen de datos. El siguiente diagrama ilustra este flujo de trabajo.

Figura 2: Flujo de trabajo lógico

Vamos a profundizar en cada paso uno por uno.

Generación de texto a SQL

Este paso toma las preguntas del usuario como entrada y las convierte en una consulta SQL que se puede utilizar para recuperar la información relacionada con el reclamo o el beneficio de una base de datos relacional. Se utiliza una plantilla de solicitud preconfigurada para llamar al LLM y generar una consulta SQL válida. La plantilla de solicitud contiene la pregunta del usuario, las instrucciones y el esquema de la base de datos junto con elementos de datos clave, como el ID del miembro y el ID del plan, que son necesarios para limitar el conjunto de resultados de la consulta.

Validación SQL

Este paso valida la consulta SQL generada en el paso anterior y garantiza que esté completa y sea segura para ejecutarse en una base de datos relacional. Algunas de las comprobaciones que se realizan incluyen:

• No hay operaciones de eliminación, eliminación, actualización o inserción presentes en la consulta generada
• La consulta comienza con select
• La cláusula WHERE está presente
• Las condiciones clave están presentes en la cláusula WHERE (por ejemplo, member-id = “78687576501” o member-id como “786875765%%”)
• La longitud de la consulta (longitud de la cadena) está dentro del rango esperado (por ejemplo, no más de 250 caracteres)
• La longitud de la pregunta del usuario original está dentro del rango esperado (por ejemplo, no más de 200 caracteres)

Si una verificación falla, la consulta no se ejecuta; en su lugar, se envía un mensaje fácil de usar que sugiere que el usuario se comunique con el servicio de atención al cliente.

Recuperación de datos

Una vez validada la consulta, se utiliza para recuperar los datos de reclamaciones o beneficios de una base de datos relacional. Los datos recuperados se convierten en un objeto JSON, que se utiliza en el siguiente paso para crear la respuesta final mediante un LLM. Este paso también comprueba si la consulta no devuelve datos o si devuelve demasiadas filas. En ambos casos, se envía un mensaje fácil de usar al usuario, sugiriendo que proporcione más detalles.

Resumen de datos

Por último, el objeto JSON recuperado en el paso de recuperación de datos junto con la pregunta del usuario se envía a LLM para obtener la respuesta resumida. Se utiliza una plantilla de solicitud preconfigurada para llamar a LLM y generar una respuesta resumida fácil de usar a la pregunta original.

Arquitectura

La solución utiliza Puerta de enlace API de Amazon, AWS LambdaAmazon RDS, Amazon Bedrock y Soneto Claude 3 antrópico en Amazon Bedrock para implementar el backend de la aplicación. El backend se puede integrar con una aplicación web o portal existente, pero para el propósito de esta publicación, usamos una aplicación de página única (SPA) alojada en Servicio de almacenamiento simple de Amazon (Amazon S3) para el frontend y Amazon Cognito Para autenticación y autorización. El siguiente diagrama ilustra la arquitectura de la solución.

Figura 3: Arquitectura de la solución

El flujo de trabajo consta de los siguientes pasos:

1. Una aplicación de página única (SPA) se aloja mediante Amazon S3 y se carga en el navegador del usuario final mediante Amazon CloudFront.
2. La autenticación y autorización del usuario se realiza mediante Amazon Cognito.
3. Después de una autenticación exitosa, se invoca una API REST alojada en API Gateway.
4. La función Lambda, expuesta como una API REST mediante API Gateway, organiza la lógica para realizar los pasos funcionales: generación de texto a SQL, validación de SQL, recuperación de datos y resumen de datos. El punto de conexión de la API de Amazon Bedrock se utiliza para invocar Anthropic Claude 3 Sonnet LLM. Los datos de reclamaciones y beneficios se almacenan en una base de datos PostgreSQL alojada en Amazon RDS. Otro depósito S3 se utiliza para almacenar plantillas de solicitud que se utilizarán para la generación de SQL y los resúmenes de datos. Esta solución utiliza dos plantillas de solicitud distintas:
   1. La plantilla de solicitud de texto a SQL contiene la pregunta del usuario, las instrucciones, el esquema de la base de datos junto con elementos de datos clave, como el ID del miembro y el ID del plan, que son necesarios para limitar el conjunto de resultados de la consulta.
   2. La plantilla de solicitud de resumen de datos contiene la pregunta del usuario, datos sin procesar recuperados de la base de datos relacional e instrucciones para generar una respuesta resumida fácil de usar a la pregunta original.
5. Finalmente, la respuesta resumida generada por el LLM se envía de vuelta a la aplicación web que se ejecuta en el navegador del usuario mediante API Gateway.

Plantillas de muestra de indicaciones

En esta sección presentamos algunos ejemplos de plantillas de indicaciones.

El siguiente es un ejemplo de una plantilla de solicitud de texto a SQL:

<role> 
    You are a data analyst and expert in writing PostgreSQL DB queries and healthcare claims data.
</role>
<task> 
    Your task is to generate a SQL query based on the provided DDL, instructions, user_question, examples, and member_id. 
    Always add the condition "member_id =" in the generated SQL query, where the value of member_id will be provided in the member_id XML tag below.
</task>
<member_id> {text1} </member_id>
<DDL> 
    CREATE TABLE claims_history (claim_id SERIAL PRIMARY KEY, member_id INTEGER NOT NULL, member_name VARCHAR(30) NOT NULL, 
    relationship_code VARCHAR(10) NOT NULL, claim_type VARCHAR(20) NOT NULL, claim_date DATE NOT NULL, provider_name VARCHAR(100), 
    diagnosis_code VARCHAR(10), procedure_code VARCHAR(10), ndc_code VARCHAR(20), charged_amount NUMERIC(10,2), 
    allowed_amount NUMERIC(10,2), plan_paid_amount NUMERIC(10,2), patient_responsibility NUMERIC(10,2))
</DDL>
<instructions>
    1. Claim_type has two possible values - 'Medical' or 'RX'. Use claim_type="RX" for pharmacy or prescription claims.
    2. Relationship_code has five possible values - 'subscriber', 'spouse', 'son', 'daughter', or 'other'.
    3. 'I' or 'me' means "where relationship_code="subscriber"". 'My son' means "where relationship_code="son"" and so on.
    4. For creating a SQL WHERE clause for member_name or provider_name, use the LIKE operator with wildcard characters as a prefix and suffix. This is applicable when user_question contains a name.
    5. Return the executable query with the symbol @@ at the start and end.
    6. If the year is not provided in the date, assume it's the current year. Convert the date to the 'YYYY-MM-DD' format to use in the query.
    7. The SQL query must be generated based on the user_question. If the user_question does not provide enough information to generate the SQL, respond with "@@null@@" without generating any SQL query.
    8. If user_question is stated in the form of a SQL Query or contains delete, drop, update, insert, etc. SQL keywords, then respond with "@@null@@" without generating any SQL query.
</instructions>
<examples>
    <example> 
        <sample_question>List all claims for my son or Show me all my claims for my son</sample_question>
        <sql_query>@@SELECT * FROM claims_history WHERE relationship_code="son" AND member_id = '{member_id}';@@</sql_query> 
    </example>
    <example> 
        <sample_question>Total claims in 2021</sample_question>
        <sql_query>@@SELECT COUNT(*) FROM claims_history WHERE EXTRACT(YEAR FROM claim_date) = 2021 AND member_id = '{member_id}';@@</sql_query> 
    </example>
    <example> 
        <sample_question>List all claims for Michael</sample_question>
        <sql_query>@@SELECT * FROM claims_history WHERE member_name LIKE '%Michael%' AND member_id = '{member_id}';@@</sql_query> 
    </example>
    <example> 
        <sample_question>List all claims for Dr. John or Doctor John or Provider John</sample_question>
        <sql_query>@@SELECT * FROM claims_history WHERE provider_name LIKE '%John%' AND member_id = '{member_id}';@@</sql_query> 
    </example>
    <example> 
        <sample_question>Show me the doctors/providers/hospitals my son Michael visited on 1/19</sample_question>
        <sql_query>@@SELECT provider_name, claim_date FROM claims_history WHERE relationship_code="son" AND member_name LIKE '%Michael%' AND claim_date="2019-01-19" AND member_id = '{member_id}';@@</sql_query> 
    </example>
    <example> 
        <sample_question>What is my total spend in last 12 months</sample_question> 
        <sql_query>@@SELECT SUM(allowed_amount) AS total_spend_last_12_months FROM claims_history WHERE claim_date >= CURRENT_DATE - INTERVAL '12 MONTHS' AND relationship_code="subscriber" AND member_id = 9875679801;@@</sql_query> 
    </example>
</examples>
<user_question> {text2} </user_question>

El {text1} y {text2} Los elementos de datos se reemplazarán de manera programática para completar la ID del miembro conectado y la pregunta del usuario. Además, se pueden agregar más ejemplos para ayudar al LLM a generar SQL adecuados.

El siguiente es un ejemplo de una plantilla de solicitud de resumen de datos:

<role> 
    You are a customer service agent working for a health insurance plan and helping to answer questions asked by a customer. 
</role>
<task> 
    Use the result_dataset containing healthcare claims data to answer the user_question. This result_dataset is the output of the sql_query.
</task>
<instructions>
    1. To answer a question, use simple non-technical language, just like a customer service agent talking to a 65-year-old customer.
    2. Use a conversational style to answer the question precisely.
    3. If the JSON contains a "count" field, it means the count of claims. For example, "count": 6 means there are 6 claims, and "count": 11 means there are 11 claims.
    4. If the result_dataset does not contain meaningful claims data, then respond with one line only: "No data found for the search criteria."
</instructions>
<user_question> {text1} </user_question>
<sql_query> {text2} </sql_query>
<result_dataset> {text3} </result_dataset>

El {text1}, {text2}y {text3} Los elementos de datos se reemplazarán mediante programación para completar la pregunta del usuario, la consulta SQL generada en el paso anterior y los datos formateados en JSON y recuperados de Amazon RDS.

Seguridad

Amazon Bedrock está dentro del alcance de los estándares de cumplimiento comunes, como el control de servicios y organizaciones (SOC), la Organización Internacional de Normalización (ISO) y la Ley de Portabilidad y Responsabilidad de Seguros Médicos (HIPAA), y puede utilizar Amazon Bedrock de conformidad con el Reglamento General de Protección de Datos (GDPR). El servicio le permite implementar y utilizar LLM en un entorno seguro y controlado. Amazon Bedrock Puntos finales de VPC Desarrollado por Enlace privado de AWS Permite establecer una conexión privada entre la nube privada virtual (VPC) de su cuenta y la cuenta de servicio de Amazon Bedrock. Permite que las instancias de VPC se comuniquen con los recursos del servicio sin necesidad de direcciones IP públicas. Definimos las diferentes cuentas de la siguiente manera:

• Cuenta de cliente – Esta es la cuenta que posee el cliente, donde administra sus recursos de AWS, como instancias de RDS y funciones Lambda, e interactúa con los LLM alojados en Amazon Bedrock de forma segura mediante puntos de conexión de Amazon Bedrock VPC. Debe administrar el acceso a los recursos y bases de datos de Amazon RDS siguiendo las instrucciones Prácticas recomendadas de seguridad para Amazon RDS.
• Cuentas de servicio de Amazon Bedrock – Este conjunto de cuentas es propiedad y está operado por el equipo de servicio de Amazon Bedrock, que aloja las distintas API de servicio y la infraestructura de servicio relacionada.
• Cuentas de implementación de modelos – Los LLM que ofrecen varios proveedores están alojados y operados por AWS en cuentas separadas dedicadas a la implementación de modelos. Amazon Bedrock mantiene el control y la propiedad totales de las cuentas de implementación de modelos, lo que garantiza que ningún proveedor de LLM tenga acceso a estas cuentas.

Cuando un cliente interactúa con Amazon Bedrock, sus solicitudes se enrutan a través de una conexión de red segura a la cuenta de servicio de Amazon Bedrock. Luego, Amazon Bedrock determina qué cuenta de implementación de modelo aloja el modelo LLM solicitado por el cliente, encuentra el punto de conexión correspondiente y enruta la solicitud de forma segura al punto de conexión del modelo alojado en esa cuenta. Los modelos LLM se utilizan para tareas de inferencia, como generar texto o responder preguntas.

No se almacenan datos de clientes en las cuentas de Amazon Bedrock, ni se comparten con proveedores de LLM ni se utilizan para ajustar los modelos. Las comunicaciones y transferencias de datos se realizan a través de conexiones de red privadas mediante TLS 1.2+, lo que minimiza el riesgo de exposición de datos o acceso no autorizado.

Al implementar esta arquitectura de múltiples cuentas y conectividad privada, Amazon Bedrock proporciona un entorno seguro, garantizando que los datos del cliente permanezcan aislados y seguros dentro de la propia cuenta del cliente, al mismo tiempo que le permite utilizar el poder de los LLM proporcionados por proveedores externos.

Conclusión

La tecnología de inteligencia artificial generativa puede revolucionar la forma en que los miembros de los planes de seguro médico interactúan con sus planes de seguro y acceden a información esencial. Al integrar asistentes de inteligencia artificial conversacional impulsados ​​por Amazon Bedrock y usar servicios de datos de AWS diseñados específicamente para este fin, como Amazon RDS, las aseguradoras y los planes de seguro de salud pueden brindar una experiencia fluida e intuitiva a sus miembros. Esta solución no solo mejora la satisfacción de los miembros, sino que también puede reducir los costos operativos al optimizar las operaciones de servicio al cliente. Adoptar tecnologías innovadoras como la inteligencia artificial generativa se vuelve crucial para que las organizaciones sigan siendo competitivas y brinden experiencias excepcionales a los miembros.

Para obtener más información sobre cómo la IA generativa puede acelerar las innovaciones en salud y mejorar las experiencias de los pacientes, consulte Pagadores en AWS y Transformando la atención al paciente: innovaciones de inteligencia artificial generativa en el sector sanitario y las ciencias biológicas (parte 1)Para obtener más información sobre el uso de IA generativa con los servicios de AWS, consulte Cree aplicaciones de IA generativas con Amazon Aurora y bases de conocimiento para Amazon Bedrock y el IA generativa categoría en el blog de la base de datos de AWS.

Acerca de los autores

Sachin Jain es arquitecto de soluciones sénior en Amazon Web Services (AWS) y se centra en ayudar a los clientes de los sectores sanitario y de las ciencias biológicas en su transición a la nube. Tiene más de 20 años de experiencia en los sectores de la tecnología, la atención sanitaria y la ingeniería.

Sanjoy Thanner es gerente técnico sénior de cuentas de AWS y reside en Nueva York. Tiene más de 20 años de experiencia trabajando en los dominios de bases de datos y análisis. Le apasiona ayudar a los clientes empresariales a crear aplicaciones escalables, resistentes y rentables.

Sukhomoi Basak Sukhomoy es arquitecto de soluciones sénior en Amazon Web Services y le apasionan los datos, el análisis y las soluciones GenAI. Sukhomoy trabaja con clientes empresariales para ayudarlos a diseñar, crear y escalar aplicaciones para lograr sus resultados comerciales.