¡Esta es una revisión vieja del documento!
Recomendaciones de Arquitectura
Servicios de Facturación y Débitos
Introducción
La información presentada a continuación, intenta ser una guía con recomendaciones de arquitectura, para implementar los medios interoperables, consensuados por el Proyecto MAIS, para establecer un modelo único de transacción para los ítems de facturación y débitos, entre Prestadores y Financiadores.
Consideraciones
- Todas las definiciones se fundamentan en lo consensuado por el Proyecto MAIS.
- El formato seleccionado para la transferencia de los ítems de facturación y débitos están basados en los recursos FHIR (https://www.hl7.org/fhir/)
- Los servicios definidos, fueron consensuados bajo el contexto de transferencia entre Prestadores y Financiadores.
Arquitectura
Servicios Definidos
Los servicios definidos y que se deben implementar para respetar lo establecido son:
- Login: Servicio de autenticación de Prestadores en el servidor del Financiador.
- Facturación: Recibe los ítems de facturación enviados por los Prestadores para su posterior validación por parte del Financiador.
- Débitos: Retorna el resultado de la validación de los ítems de facturación que fueron enviados con anterioridad a través del servicio de Facturación.
- Documentación de Respaldo: Servicio para transferir la documentación digitalizada que será referenciada en los trámites de facturación.
Todos los servicios pueden trabajar con JSON o XML (según definición de FHIR), por defecto utiliza JSON, ya que con esta implementación, la información que se transmite es menor. Para seleccionar un formato u otro se debe definir el HEADER HTTP “Accept” en “application/xml” o “application/json”.
Además están securizados con oAuth2, con excepción del endpoint de Autenticación.
Endpoints Implementados
Autenticación:
POST /<context>/auth
- Se debe enviar el usuario y la password. La gestión del usuario lo realiza el Financiador.
- Retorna token para utilizar en los endpoints restantes. El token tiene una validez establecida.
Este servicio permite a las aplicaciones que deseen enviar información a un Financiador conectarse, autenticarse y obtener un token que habilita el acceso a los otros servicios. Ver bibliotecas que permiten la implementación de oAuth2 en http://oauth.net/2/
La secuencia es la siguiente:
- El Cliente FHIR (CF) envía el pedido de token al servicio de autenticación (SA) con un usuario y password asignado por la organización que controla al servicio.
- El servicio verifica el usuario y la password, devuelve al CF un token con una validez o vencimiento.
- Mientras el token sea válido, el CF puede utilizar este token para acceder a los servicios de documentos, facturación, débitos, de acuerdo a sus roles asignados. El token se incluye en el header HTTPS de la solicitud al los diferentes servicios, según lo establecido por oAuth.
- En caso que el usuario/password no sea válido, el servidor de autenticación devolverá error HTTP 401 (Unauthorized Access) .
- Si el token no es válido o expiró, cualquiera de los servidores devolverá error HTTP 401.
Ejemplos xml o json con parametros definidos en formato Raw: https://www.dropbox.com/home/MAIS_COMPLETO/SERVICIO%20MODELO/Raws/1
-
Auth