Homologar
La información en esta página está orientada a desarrolladores que desean realizar la tarea técnica de integración con PuntoSalud. La integración u homologación aquí referida, es la implementación de funcionalidades para que los usuarios puedan desde su misma aplicación de gestión realizar la obtención de autorizaciones sin necesidad de salir de su entorno de trabajo. De esta manera no solo se evita la doble carga de información que se realiza en otras alternativas como en la solicitud de autorizaciones vía POS o por IVR, si no que se agiliza la operación al prestador permitiéndole interactuar con su sistema, y su nomencladores y pudiendo procesar las respuestas obtenidas instantáneamente evitando así gastos administrativos.
Para permitir la integración se ofrece una serie de herramientas o posibilidades entre las cuales el desarrollador puede optar libremente de acuerdo a sus necesidades y experiencia.
En esta sección encontrará los enlaces a cada uno de los Recursos y Manuales requeridos, guías para seleccionar la versión a utilizar de acuerdo a su tecnología y el tipo de usuario al que apunta su aplicación. En caso de tener alguna duda puede informarla a la Mesa de Ayuda y contactar directamente al soporte para desarrolladores vía mail.
Empezar!
¿Por qué encarar una integración?
Integrar u homologar su aplicación permitirá que los usuarios, sus clientes, puedan aprovechar las ventajas de tener una autorización de quien finalmente pagará los servicios médicos que está prestando ANTES de que se produzca el gasto médico, evitando así todo tipo de débitos por motivos administrativos. Simplificando y agilizando la presentación de la facturación por tener ya pre-auditadas las prestaciones realizadas y medicamentos dispensados. Asegurando que las prestaciones son facturadas adecuadamente de acuerdo a la condición de IVA de cada paciente atendido al tomar de la respuesta este entre otros datos y evitando refacturaciones y demoras. Permitiéndole a los pacientes que acuden los centros donde es usado su sistema, puedan acceder a la cobertura que ellos pactaron con los financiadores sin necesidad de realizar trámites previos.
En definitiva eliminando toda la incertidumbre que genera usualmente la utilización de una cobertura médica, haciendo a su vez más eficiente la operación administrativa de los prestadores médicos y financiadores y más simple el acceso para los pacientes.
¿Qué significa hacer una transacción?
El intercambio de datos entre los prestadores de salud, y los entes financiadores para realizar la validación de los consumos prestacionales en tiempo real se realiza mediante una transacción. Una transacción es un proceso indivisible en el cuál el prestador envía cierta información al ente financiador y tras ser procesada, éste devuelve una respuesta.
| Operación | Requerimiento (Información enviada) | Respuesta (Información recibida) |
|---|---|---|
| Consultar estado de un beneficiario | Identificación del prestador, identificación del beneficiario, fechas, otros datos auxiliares | Estado del beneficiario (habilitado, inhabilitado, etc.) |
| Informar que se realizará una prestación a un beneficiario | Identificación del prestador, identificación del beneficiario, código de la prestación, fechas, otros datos auxiliares | Autorizado (número de autorización) o Rechazado (Motivo del rechazo) |
Para simplificar la realización de transacciones entre el prestador y el ente financiador, SITEL (una herramienta de ITC) se encarga del intercambio de información entre las dos partes independizándolas de los problemas tecnológicos que implica la interconexión de dos sistemas informáticos heterogéneos y distantes. SITEL es básicamente una plataforma Cliente/Servidor. SITEL Cliente se encuentra instalado en el prestador y SITEL Servidor es el encargado de interactuar con el ente financiador.
¿Cómo seleccionar un método y formato?
Los pasos básicos serán:
- Seleccionar el formato adecuado para su producto
- Realizar las modificaciones necesarias
- Probar la integración
- Pedirle a su cliente que solicita las altas a las prepagas y obras sociales con las que desea realizar la operación en línea
- Coordinar con ITC la instalación de aplicativos de comunicaciones si fuese necesario
- Actualizar su aplicación
- Verificar si utiliza nomencladores propios
- Comunicar a los usuarios contactos con la Mesa de Ayuda
- Finalmente puede poner a disposición de nuestra Mesa de Ayuda documentación para que podamos guiar a los usuarios de su aplicación cuando se comuniquen con nosotros.
1. Seleccionar el formato adecuado para su producto
Esta es una guía simplificada para guiarlo en su elección.
2. Realizar las modificaciones necesarias
Es muy importante que la transacción sea realizada antes de que se produzca el gasto médico.
Así por ejemplo si tiene un sistema de farmacia, debería obtener la respuesta antes de emitir el ticket fiscal de esta manera obtiene del financiador, las cantidades, precios de los medicamentos y coberturas asignadas al afiliado, pudiendo corregir los montos del ticket fiscal antes de facturarle al cliente el neto.
En el caso de un prestador médico (ya sea un consultorio u hospital) hay diferentes puntos donde se puede realizar un control efectivo y capitalizar las ventajas, a saber:
- Al momento de asignar un turno: la Verificación del Afiliado o Afiliado y Prestación, le permite al prestador asignar un turno solo a pacientes con cobertura, o por lo menos aquellos que no la tengan que lo sepan de antemano antes de concurrir el centro médico. Evitando que quede un turno vacío para el prestador y permitiéndolo también al paciente que solucione su problema de afiliación antes de concurrir a la consulta.
- Al momento de la atención: a diferencia del caso anterior en lugar de Verificar aquí se realiza una transacción similar que Informa los servicios solicitados. La diferencia radica que en caso de ser Aprobada esta última, los servicios solicitados quedan acreditados en una cuenta corriente del prestador, en cambio la Verificación no. En los casos necesarios el prestador obtendrá también el copago que debe cobrarle al paciente además de los datos usuales.
- Al momento de la facturación: en muchos casos, el prestador realizar un control administrativo posterior a la atención para verificar que se han seguido todos los procedimientos requeridos por el financiador con el objeto de evitar débitos. En estos casos será necesario que el personal de administración pueda realizar Anulaciones e Informar Prestaciones. Las autorizaciones obtenidas no pueden modificarse, se precisa realizar un cambio debe anular la transacción dado que se encuentra acreditada y volverla a informar.
3. Probar la integración
Una vez terminal la homologación comuníquese con ITC para obtener un alta de prueba en el o los financiadores que desee testear. La homologación es única para todos los financiadores. ITC actúa como un gateway de procesamiento que realiza las conversiones de semántica (del contenido del mensaje) y de sintaxis (del formato) para que pueda ser interpretado por cada financiador.
4. Altas en Financiadores
Normalmente el prestador debe solicitar un alta en cada financiador. Este es necesario dado que el financiador no solo es quien cubre los costos de la validación pero principalmente porque muchas de las validaciones requieren que se encuentre cargada las condiciones de contratación pactadas entre prestador y financiador. Generalmente esta alta se inicia a través de ITC que intenta agilizar los contactos con cada financiador.
5. Instalación y Actualización de Aplicativo
De acuerdo al mecanismo usado es normalmente necesaria la instalación de una aplicación de comunicaciones dentro del prestador médico. Esta aplicación, es provista por ITC, y es necesaria para tomar el mensaje, encriptarlo, establecer el vínculo con ITC y transmitirlo. Normalmente el funcionamiento de esta aplicación es transparente o invisible al usuario de la aplicación de gestión.
Aplicaciones ya homologadas con Formatos de Terceros
La política de ITC es intentar aceptar distintos formatos que prestadores puedan tener ya implementados, permitiendo así la reutilización de una homologación existente para poder interactuar con los financiadores atendidos por ITC. Existen en la actualidad una cantidad de formatos funcionando y otros en desarrollo. Si usted posee un sistema de gestión homologado y su formato no se encuentra disponible aquí comuníquese con nosotros para que podamos analizar su implementación.
Entre los formatos disponibles para centros médicos:
- HL7 versión 2.6. Esperando la aprobación de HL7 Argentina
- HL7 V2.3
- HL7 V2.3.1
- HL7 V2.4 Implementación Prepagas
Entre los formatos disponibles para farmacia están:
Aplicaciones comerciales homologadas
El listado aquí no constituye un apoyo al uso de una aplicación determinada, si no es información provista para que usted pueda realizar su propia evaluación. Corresponde solo a aplicaciones comerciales y desarrollos propios que se encuentran a disposición:
| Mercado | Aplicación |
| Sistemas de Farmacia | |
| Gestión de Hospitales | |
| Laboratorios de Análisis Clínicos | |
| Odontología |
Si su aplicación no aparece aquí y desea incluirla contáctese con nosotros.
Temas relacionados con Credenciales
Manejo de Credenciales Digitales
La gran mayoría de los financiadores utiliza credenciales digitales, pero solo algunos de ellos poseen mecanismos de seguridad, entre ellos:
- SmartCred: encripta el número de credencial, para la aplicación esto significa que el dato leido solo debe enviarse tal cual se captura, ya sea a través de la lectura de un código QR o la transferencia de vía NFC. Los datos se envían en como si fuese una lectura de la banda magnética, y el resultado contendrá todos los datos del afiliado:
| HL7 | PID-3.1: Identificador del Afiliado o Número de Credencial. |
| Formato XML tipo Adesfa | Nodo <Credencial> Tag <Track> |
Esta credencial encriptada solo tiene una sola posibilidad de uso, su almacenamiento/guarda es inutil.
- Código de Seguridad temporales u OTP: hay credenciales, como por ejemplo OSDE#Credencial_Digital genera un código de seguridad que tiene un tiempo de vida de entre 30 segundos y 5 minutos. Solo durante ese lapso el código de seguridad es válido. Ese dato es necesario enviarlo en:
| HL7 | PID-3.1: Identificador del Afiliado o Número de Credencial. |
| Formato XML Prestadores y JSON | campo <VersionCredencial> |
| Formato XML tipo Adesfa | Nodo <Credencial> Tag <CSC> |
| Formato V250 | campo CSC (Código de Seguridad de la Credencial) |
| Formato V106 | el dato se envía en AUDIGA y AUVERA |
Manejo de Credenciales con Banda Magnética
Cuando realiza la integración de aplicaciones, la lectura de la banda magnética no requiere un manejo especial. Esta lectura es en todos los casos tomada con un lector con interfase de teclado o con interfase USB que se comporta como un teclado. Es decir los datos se ingresan como si fuesen tipeados por el operador. Esta lectura no requiere un parseo, esto es importante dado que la magnetización de las credenciales en el sector de la salud no se encuentra estandarizada no hay y entonces ninguna garantía de que la misma no cambia de financiador en financiador y a lo largo del tiempo para el mismo financiador cuando este cambia de proveedor.
La lectura de la banda, es enviada en los formatos
| HL7 | PID-3.1: Identificador del Afiliado o Número de Credencial. |
| Formato XML tipo Adesfa | Nodo <Credencial> Tag <Track> |
Debe enviarse la lectura tal cual se recibe, todos los caracteres son enviados en un mismo campo. En la respuesta de la transacción obtendrá todos los datos de la credencial parseados, número, nombre, sexo, etc.
Nomencladores Propios
Independiente del formato utilizado, el prestador puede utilizar su propia forma de denominar gran parte de la información enviada. ITC toma la función de transcodificar o convertir estas porciones del mensaje para que pueda ser interpretada por cada financiador. Entre los nomencladores propios que se pueden manejar son el de prestaciones, motivos de ingreso y egreso de internación, motivos de finalización de terapia en tratamientos por sesiones, y el manejo de medicamentos durante la internación entre otros. En el caso de los diagnósticos en general es un dato no controlado en línea, es decir se aceptará el código enviado, en algunos formatos se solicita la identificación de la nomenclatura del diagnóstico además del código.
En general el resto de los datos se intenta que sean estandarizados, así por ejemplo la identificación de los prestadores se realizar mediante CUIT, y en algunos casos de los prescriptores y efectores también. ITC convierte estos valores a la nomenclatura requerida por el financiador en todos los casos.
Recursos Disponibles
Formatos
| Dispensa de Medicamentos | Servicios Médicos | |
| De longitud variable | Formato Farmacias XML | Formato Prestadores JSON Formato Prestadores XML |
Agregar valor para el paciente y usuarios
Migrar a XML
La migración de farmacias al formato XML otorga mucha flexibilidad para incorporar cualquier tipo de requerimiento futuro, el formato se basa en el Formato ADESFA, es decir que puede utilizarse en otros carriers.
Esta versión de XML incorpora más funciones para el manejo de las recetas que la farmacia necesita incluir en los cierres de lote para el proceso de liquidación.
Ir a la documentación del formato.
Rescate de Receta Electrónica
Es posible desde una Farmacia habilitado realizar una búsqueda de una receta, de la meta-data de la prescripción, de manera, no solo de no tener que tipear todos los datos, si no también como verificación de la prescripción presentada por el paciente.
Para hacer un Rescate de una Prescripción Electrónica es necesario enviar los siguientes datos:
| Formato XML tipo Adesfa. | <CodAccion> 490120. Consulta de Receta Electrónica | Nodo <Financiador> indicar quién realiza la cobertura, además el dominio donde se encuentra la receta, enviar <Codigo> y <Cuit> | Nodo <Credencial>, identificar la cobertura del paciente enviando <Numero> | Nodo <Formulario> Tag <Numero> se debe ingresar el localizador o número de prescripción. Es un dato que solo conoce el paciente. | Nodo <<Beneficiario> no es una mala práctica utilizar <NroDoc> para identificar al paciente |
Dispensar una Receta Electrónica
Para la autorización de dispensa de medicamentos, es necesario indicar entre los datos enviados el número de prescripción. Esto garantiza que los medicamentos dispensados con cobertura de un financiador tengan luego una correcta liquidación. ¿Donde se envía ese dato?
| Formato XML tipo Adesfa. <CodAccion> 290020. Autorización de Prescripción, 20010 Cancelación de Prescripción | Nodo <Formulario> Tag <Numero> se utiliza para indicar el número de prescripción. |
| Formato V250. Operación 01. Alta de ticket, 02. Anulación ticket, 03. Devolución, 05. Alta diferida de ticket | campo Receta permite el envío del número de la receta que se utiliza para identificar una receta electrónica, digitalizada o formulario pre-impreso numerado. |
Formatos de medio magnético para presentar facturación
El formato del archivo de liquidación depende del financiador. V250 intenta realizar una estandarización que mediante una única transacción que elimina no solo la necesidad de confeccionar el archivo si no, también la necesidad del cálculo de totales y del envío. Para farmacia V250 y tipo Adesfa (al cual también lo hemos incorporado) tienen esta presentación digital en forma obligatorio a través de los cierres.
Para prestadores médicos, existe en V250 y otros formatos, la capacidad de solicitar digitalmente mediante una transacción la liquidación. Sin embargo varios financiadores no han asignado los valores en la contratación que permitirían obtener el cálculo exacto. En estos casos, donde no se haya implementado la liquidación electrónica es preciso remiter un médio magnético o contactar al financiador para conocer el mecanismo para solicitar la liquidación.
Por ejemplo, en OSDE Metropolitana (pero no en las filiales del interior), deberá remitir un archivo con el siguiente formato OSDE#Liquidación Manual con Medio Magnético.
Anexos
Ejemplo Pseudocódigo utilizando SFTP
/* considera el uso de SFTP */
sftp user@hostTransacciones:/share/terms/term01/estado.rsp
Si existe archivo estado.rsp
{
/* Existe una respuesta pendiente de proceso */
Mostrar mensaje "Transacción anterior terminada anormalmente "
Guardar archivo term01/download/_svl.itc
Borrar archivo term01/estado.rsp
}
Armar y grabo localmente archivo _svl.itc
/* ver pseudocódigo para Intercambio de Archivos Planos */
*/ se van colocando los tags requeridos de acuerdo a la información a enviar */
sftp _svl.itc user@hostTransacciones:/share/terms/term01/
/* copio archivo ida */
sftp term01 user@hostTransacciones:/share/terms/tx/
/* copio archivo para disparar la transacción */
Mientras no exista archivo sftp user@hostTransacciones:/share/terms/term01/estado.rsp
{
esperar 1 segundo
}
Abrir archivo term01\estado.rsp
Leer de archivo primer carácter
Cerrar archivo
Si primercaracter del archivo es ‘0’
{
/* la transacción salió bien a nivel de conexión */
sftp user@hostTransacciones:/share/terms/term01/download/_svl.itc
/* todos los archivos de respuesta del formato vienen dentro de este separado por los TAGS */
Abrir archivo term01\_svl.itc
Si existe [_sitel.err] {
/* hubo un error de formato de la transacción */
/* los registros luego de [_sitel.err] contienen una descripción de los errores */
Imprimir [_ticket.prn]
}
si no
{
Abrir [_svl.1]
Mostrar archivo.Comentario/Display
Si archivo.Error=’0000’
{
5
/* la transacción está aprobada */
}
si no
{
/* la transacción no esta aprobada se puede consultar si alguno */
/* de los items de la receta es responsable de que la transacción
no haya sido aprobada */
Abrir [_svl.3]
/* el campo archivo2.Error es ’00’ o ’99’ para prescripciones sin error */
}
Cerrar archivo term01\_svl.itc
}
}
si no
{
/* hubo un problema de conexión */
Mostrar contenido de term01\estado.rsp
}
Si existe archivo term01\estado.rsp
{
Borrar archivo sftp user@hostTransacciones:rm /share/terms/term01/estado.rsp \
}
<analytics uacct="UA-2549201-4"></analytics>
