[ad_1]
La autorización previa es un proceso sanitario crucial que implica autorizar tratamientos o procedimientos médicos antes de que se realicen. Este proceso es necesario para garantizar que los pacientes reciban la atención correcta y que los proveedores de atención médica sigan los procedimientos correctos. Sin embargo, la autorización previa puede ser un proceso complejo y que consume mucho tiempo y requiere mucho papeleo y comunicación entre los proveedores de atención médica, las compañías de seguros y los pacientes.
El proceso de aprobación previa de registros médicos electrónicos (EHR) consta de cinco pasos:
- Determinar si se requiere autorización previa.
- Reunir la información necesaria para respaldar la solicitud de autorización previa.
- Presentar la solicitud de autorización previa.
- Seguimiento de la solicitud de autorización previa para su resolución.
- Si es necesario, complemente la solicitud de autorización anterior con cualquier información adicional requerida (y continúe con el Paso 4).
El Proyecto Da Vinci de Reducción de la Carga ha resumido estos pasos de autorización previa en tres guías de implementación interconectadas centradas en reducir la carga para los médicos y los pagadores:
- Descubrimiento de requisitos de cobertura (CRD): proporciona apoyo a los proveedores para tomar decisiones al solicitar diagnósticos, especificar tratamientos, realizar derivaciones, programar citas, etc.
- Plantillas y reglas de documentación (DTR): esto permite a los proveedores descargar cuestionarios y reglas inteligentes, como: B. Lenguaje de calidad clínica (CQL) y proporciona una aplicación SMART on FHIR o una aplicación EHR que ejecuta cuestionarios y reglas para recopilar información relevante para una acción realizada o un servicio planificado. La ejecución de los cuestionarios y reglas también se puede realizar a través de una aplicación que forma parte de la HCE del proveedor.
- Soporte de autorización previa (PAS): esto permite que los sistemas de proveedores envíen solicitudes de autorización previa a través de FHIR (y reciban sistemas de pago) mientras cumplen con los requisitos reglamentarios para usar X12 278 para transportar la autorización previa cuando sea necesario, simplificando potencialmente el procesamiento de un socio de intercambio (o ambos). .
En esta publicación, nos centraremos en la guía de implementación de CRD para determinar los requisitos de autorización previa y explicar cómo CDS (Clinical Decision Support) Hooks utiliza AWS HealthLake para determinar si se requiere o no autorización previa.
Descripción general de la solución
CRD es un protocolo dentro del flujo de trabajo de autorización previa electrónica que facilita las llamadas entre los EHR y los pagadores que utilizan los servicios CDS. Cuando se utiliza, proporciona a los proveedores información sobre los requisitos de cobertura mientras toman decisiones sobre la atención del paciente. Esto permite que el personal del proveedor tome decisiones más informadas y satisfaga las necesidades de cobertura de seguro de sus pacientes. La interacción entre proveedores y pagadores se produce sin problemas a través de CDS Hooks.
CDS Hooks es una especificación Health Level Seven International (HL7). CDS Hooks proporciona una forma de incorporar funciones adicionales en el flujo de trabajo de EHR de un médico casi en tiempo real. Con CDS Hooks, las prácticas de acreditación, como la autorización previa, así como otros requisitos de certificación previa, como la participación en la red de médicos, se pueden optimizar adecuadamente. Esta función ayuda a los proveedores a tomar decisiones informadas brindándoles información sobre la condición de sus pacientes, las opciones de tratamiento y los formularios que deben completarse para facilitar su atención. El uso estratégico de CDS Hooks permite a los médicos desarrollar rápidamente planes de atención más centrados en el paciente y respaldar el proceso de autorización previa al revelar requisitos administrativos y clínicos críticos. Para obtener más información sobre CDS Hooks y sus especificaciones, visite el sitio web de CDS Hooks.
El siguiente diagrama ilustra cómo se automatiza el flujo de trabajo CRD utilizando HealthLake.
Los pasos del flujo de trabajo son los siguientes:
- Un empleado del proveedor inicia sesión en el sistema EHR para abrir el registro del paciente.
- El sistema EHR valida las credenciales del usuario y llama al enlace de visualización del paciente para recuperar información sobre el estado del paciente.
- Amazon API Gateway llama a la función AWS Lambda Patient View Hooks.
- La función Lambda valida y recupera la identificación del paciente de la solicitud y recupera la información del estado del paciente de HealthLake.
- Después de verificar la condición del paciente, el usuario llama al gancho de selección de pedidos para recuperar información sobre los requisitos de cobertura para el medicamento específico.
- API Gateway llama a la función Lambda de enlaces de requisitos de cobertura.
- La función Lambda recupera información de reclamos para el paciente, ejecuta reglas CQL basadas en los medicamentos enviados y la información de reclamos recuperada de HealthLake y determina si se requiere autorización previa.
La solución está disponible en Determinar el descubrimiento de requisitos de cobertura mediante CDS Hooks con el repositorio GitHub de AWS HealthLake.
requisitos
Esta publicación asume que está familiarizado con los siguientes servicios:
Implemente la aplicación mediante la CLI de AWS SAM
Puede implementar la plantilla mediante la Consola de administración de AWS o la CLI de AWS SAM. Para utilizar la CLI, siga estos pasos:
- Instale la CLI de AWS SAM.
- Descargue el código de muestra del repositorio de ejemplos de AWS a su sistema local:
git clone https://github.com/aws-samples/aws-crd-hooks-with-awshealthlake-api
cd aws-crd-hooks-with-awshealthlake-api/
- Cree la aplicación utilizando AWS SAM:
sam build
- Implemente la aplicación mediante el proceso guiado:
sam deploy --guided
# Replace MY_VALUE with proper resource names
Configuring SAM deploy
======================
Looking for config file [samconfig.toml] : Not found
Setting default arguments for 'sam deploy'
=========================================
Stack Name [sam-app]: aws-cds-hooks-with-healthlake
AWS Region [us-east-1]: us-east-2
#Shows you resources changes to be deployed and require a 'Y' to initiate deploy
Confirm changes before deploy [y/N]:
#SAM needs permission to be able to create roles to connect to the resources in your template
Allow SAM CLI IAM role creation [Y/n]:
#Preserves the state of previously provisioned resources when an operation fails
Disable rollback [y/N]:
cdsDemoServicesFunction has no authentication. Is this okay? [y/N]: y
cqlQueryFunction has no authentication. Is this okay? [y/N]: y
cqlQueryOrderFunction has no authentication. Is this okay? [y/N]: y
Save arguments to configuration file [Y/n]: y
SAM configuration file [samconfig.toml]:
SAM configuration environment [default]:
La implementación puede tardar 30 minutos o más mientras AWS crea un almacén de datos de HealthLake y los recursos asociados en su cuenta de AWS. Es posible que AWS SAM expire el tiempo de espera y lo regrese a la línea de comando. Este tiempo de espera impide que AWS SAM le muestre el progreso en la nube, pero no detiene la implementación en la nube. Si se agota el tiempo de espera, vaya a la consola de AWS CloudFormation y verifique el estado de implementación de la pila de CloudFormation. Integre CDS Hooks en su flujo de trabajo clínico una vez que se complete la implementación de la pila de CloudFormation.
Determinar los requisitos de cobertura para autorización previa.
La solución tiene dos ganchos, Vista del paciente y Selector de pedidos, para determinar si se requiere o no autorización previa según las reglas de autorización previa del pagador. CQL se utiliza para evaluar reglas de autorización anteriores.
Los ganchos CDS se pueden integrar en EHR que admita ganchos CDS. Alternativamente, si no tiene un EHR disponible para probar, puede usar el entorno limitado disponible públicamente como se describe en el repositorio de GitHub. Tenga en cuenta que el entorno limitado de CDS Hooks se utiliza únicamente con fines de prueba.
Una vez que sus ganchos se integran en EHR y un usuario navega al flujo de trabajo clínico, el gancho de Vista del paciente se ejecuta para el paciente configurado. Tenga en cuenta que la identificación del paciente del flujo de trabajo clínico debe existir en HealthLake. Las tarjetas devueltas por la API indican que el paciente sufre una infección de los senos nasales y es posible que el médico deba solicitar una receta.
Puedes navegar a vista RX Pestaña para solicitar una receta. Como médico, seleccione el medicamento relevante e ingrese otros detalles como se muestra en la captura de pantalla a continuación.
El gancho de selección de pedido se devuelve con la tarjeta de autorización para autorización previa.
El siguiente paso es presentar una autorización previa a través de la aplicación SMART u otros mecanismos disponibles para el proveedor.
Limpiar
Si ya no necesita los recursos de AWS que creó al ejecutar este ejemplo, puede eliminarlos eliminando la pila de CloudFormation que implementó:
sam delete --stack-name <<your-stack-name>>
Diploma
En esta publicación, demostramos cómo HealthLake puede usar CDS Hooks para ayudar a reducir la carga de los proveedores y mejorar la experiencia de los miembros al identificar los requisitos de cobertura de autorización previa como parte del flujo de trabajo de prescripción clínica. CDS Hooks y HealthLake pueden ayudar a los proveedores a solicitar diagnósticos, programar tratamientos, hacer derivaciones y programar citas.
Si está interesado en implementar la determinación de necesidades de cobertura en AWS utilizando esta solución o desea obtener más información sobre cómo implementar la autorización previa en AWS, puede comunicarse con un representante de AWS.
Sobre los autores
Manish Patel, arquitecto de soluciones de socios globales que respalda la atención médica y las ciencias biológicas en AWS. Tiene más de 20 años de experiencia desarrollando soluciones para clientes de Medicare, Medicaid, pagadores, proveedores y ciencias biológicas. Impulsa estrategias de comercialización con socios para acelerar el desarrollo de soluciones en áreas como registros médicos electrónicos, imágenes médicas, soluciones de datos multimodelo e inteligencia artificial generativa. Le apasiona utilizar la tecnología para transformar la industria de la salud y lograr mejores resultados en la atención al paciente.
Shravan Vurputoor es arquitecto senior de soluciones en AWS. Como defensor confiable del cliente, ayuda a las organizaciones a comprender las mejores prácticas en torno a arquitecturas avanzadas basadas en la nube y asesora sobre estrategias para ayudar a lograr resultados comerciales exitosos en una amplia gama de clientes empresariales a través de su pasión por la capacitación, la educación, el diseño y la creación de soluciones en la nube.
[ad_2]