Diferencia entre revisiones de «Homologar»

De ITC Soluciones SA
Ir a la navegación Ir a la búsqueda
imported>Naquista
 
imported>Javier
 
Línea 144: Línea 144:
 
*[[Farmasoft]]
 
*[[Farmasoft]]
 
*[[Farmasys]]
 
*[[Farmasys]]
−
*[[Farmatronic]]
+
*[https://zetti.com.ar/farmatronic Farmatronic]
 +
*[https://zetti.com.ar/touchandsale Touch&Sale]
 
*[[Gestor]]
 
*[[Gestor]]
 
*[[Nova]]
 
*[[Nova]]

Revisión actual del 10:44 21 feb 2022

IntegreEInnove.png

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 ofrecen una serie de herramientas o posibilidades entre las cuales el desarrollador puede optar libremente de acuerdo a sus necesidades y experiencia.

Empezar! Recursos Disponibles Agregar valor para el paciente y usuarios

Detalle finales de la integración:




Formatos para Prestadores Médicos:

Formatos para Farmacia:

Mecanismos:

Aplicaciones:

Mantener:

Mejoras en farmacia:

Mejorar la integración en Centros Médicos:

Otras Mejoras:

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?

Esquema funcionamiento.png

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.

Ejemplos de Transacciones
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:

  1. Seleccionar el formato adecuado para su producto
  2. Realizar las modificaciones necesarias
  3. Probar la integración
  4. 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
  5. Coordinar con ITC la instalación de aplicativos de comunicaciones si fuese necesario
  6. Actualizar su aplicación
  7. Verificar si utiliza nomencladores propios
  8. Comunicar a los usuarios contactos con la Mesa de Ayuda
  9. 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.


Guia-para-elección-de-formato-de-homologación.jpg

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:

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>
Formato V250 campo Tarjeta

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>
Formato V250 campo Tarjeta

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
De longitud fija Formato V250 Farmacia Formato V107 Prestadores

Mecanismos

Web Service Farmacia

  • El método a invocar se llama ProcesarXML.
Operation Notes
Public Parameters:
InformarPrestacion(
string version, in string version de los archivos que envía (por ej. para XML farmacia enviar V251)
string empresa, in string código de empresa (ver valores en la tabla)
string actividad, in string actividad (por ej. Farmacia enviar 1 ver la actividad en la descripción del formato. Permite indicar formas especiales de procesamiento de la transacción de acuerdo al tipo de actor)
string licencia, in string licencia (es un dato a solicitar no es público)
string mensaje ):string in string mensaje (se incluye la transacción).

Web Service Prestadores

  • Existe un único método con lo siguientes parámetros:
Parámetro Notas
pas Es un token válido para un único lugar físico de un prestador y un financiador determinado. Por ejemplo: 32dbf220f1ab2303592b4a076162c221600ef704
msj Mensaje a enviar. Por ejemplo: <Mensaje><EncabezadoMensaje><VersionMsj>1.0</VersionMsj></EncabezadoMensaje></Mensaje>

Intercambio de Archivos Planos

El mecanismo de funcionamiento de Sitel Cliente fue diseñado para que desde la perspectiva del prestador, la realización de transacciones, sea similar a la utilización de bandejas de entrada y de salida como las que se encuentran en cualquier escritorio del mundo real. Esto traducido a términos informáticos implica que cada terminal que realiza transacciones, utiliza un directorio o carpeta de salida de requerimientos denominado upload y otro directorio o carpeta de entrada de respuestas denominado download. De esta manera, en la bandeja de salida se depositarán los requerimientos y las respuestas correspondientes generadas por el ente financiador se encontrarán en la bandeja de entrada. Depositar un requerimiento en la bandeja de salida (upload) consiste en grabar un conjunto de archivos cuyos nombres y estructuras se encuentran predefinidos (ver Formatos). Otro tanto ocurre con la respuesta. Para obtener la respuesta de la bandeja de entrada (download) debe leerse un conjunto de archivos, también predefinidos, en sus nombres y estructuras.De acuerdo a estos conceptos cuando se realiza una transacción los pasos son:

  1. Generar los archivos del requerimiento
  2. Grabar los archivos en la bandeja de salida (upload)
  3. Esperar la respuesta en la bandeja de entrada (download)
  4. Leer la respuesta de la bandeja de entrada (download)
Pseudo-código sugerido

La realización de una transacción es un proceso de intercambio de información entre el prestador y el financiador. Se describe aquí el pseudo-código sugerido para la homologación cuando se busca que ese intercambio se realice mediante archivos de texto plano o simples copiados localmente en su máquina: 

/* en este ejemplo se usa una terminal creada en forma aleatorio como directorio de la terminal */
/* este ejemplo es para homologación de transacciones farmacéuticas utilizando V250 pero es extrapolable a cualquier versión */ 
/* para homologar transacciones de con otros formatos simplemente revise la documentación del mismo todos los formatos */
/* contienen un archivo de identificación en general llamado _svl.0, un archivo de cabecera con datos no repetitivos */
/* normalmente _svl.1 o nnnn.xml y uno o más archivos con items repetitivos _svl.2, _svl.3, _svl.4 etc.  */

Genero un nombre de terminal aleatorio termAleatorio
Mientras exista archivo termAleatorio
{
       /* Existe directorio, genero otro nuevo nombre */
       Genero un nombre de terminal aleatorio termAleatorio
}
Crear directorio termAleatorio\upload
Crear directorio termAleatorio\download
Armar archivo termAleatorio\upload\_svl.1
Si transacción lleva medicamentos {
       Armar archivo termAleatorio\upload\_svl.3
}
Si transacción necesita diagnósticos asociados a la receta {
       Armar archivo termAleatorio\upload\_svl.4
}
/* creo el archivo de identificación de la transacción */
Armar archivo termAleatorio\upload\_svl.0
/* esto dispara la transacción */
Crear archivo tx\termAleatorio
Mientras no exista archivo termAleatorio\estado.rsp
{
       esperar 1 segundo
}
Abrir archivo termAleatorio\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 */
       Si existe termAleatorio\download\_sitel.err {
               /* hubo un error de formato de la transacción */
               /* termAleatorio\download\_sitel.err contiene los errores */
               Imprimir termAleatorio\download\_ticket.prn
               /* es el ticket confeccionado por el validador */
       }
       si no
       {
               Abrir archivo termAleatorio\download\_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 archivo2 termAleatorio\download\_svl.3
                     /* el campo archivo2.Error es ’00’ o ’99’ para prescripciones sin error */
                     Cerrar el archivo2
           }
           Cerrar _svl.3
       }
}
si no
{
      /* hubo un problema de conexión */
      Mostrar contenido de termAleatorio\estado.rsp
}
Eliminar la carpeta termAleatorio

Copia de los archivos

El árbol de directorio Sitel puede estar, en la misma máquina (local) o remoto en un servidor de comunicaciones (en otra máquina de la red), usualmente un gateway Linux de ITC, que tenga la aplicación de comunicaciones Sitel Cliente instalada.

La copia de los archivos se podrá hacer directamente, vía un Samba (en el caso de un Linux remoto) o también mediante una conexión a un puerto FTP, SCP, o SFTP de server remoto de comunicaciones.

Aplicaciones

  • Ver manual jSitelProcess y bajar aplicación de comunicación: cuando no pueda usarse Sitel Cliente por tener un firewall o debido a que su carrier de Internet tenga cerrados ciertos puertos indispensables, puede utilizar jSitelProcess una aplicación Java que permite el procesamiento de transacciones a través "solo" por Internet pudiendo ser configurado para pasar a través de un proxy como si el usuario "estuviera navegando por Internet" es decir sin abrir puertos especiales, e incluso permitiendo la utilización de password para navegar.

Agregar valor para el paciente y usuarios

Seguimiento de Reclamos Operativos

Puede dejar su reclamo operativo aquí. Nuestra Mesa de Ayuda atiende reclamos especialmente de índole técnico, los reclamos relacionados con respuestas de los financiadores sin generalmente respondidas directamente por estos. Sus reclamos al respecto pueden ser canalizados por ITC o directamente a través de ellos. Podrá encontrar más datos al respecto consultado directamente en la documentación de cada uno.

Mecanismos de Contingencia

En ciertas condiciones, ya sea por problemas técnicos o operativos necesitará contar con algún mecanismo alternativo para poder realizar autorizaciones en forma circunstancial. Le presentamos aquí las alternativas:

Mecanismos independientes. Para acceder a estos mecanismos deberá contar con un alta previa:

  • IVR al (011) 4515-0500 (+): no requiere ninguna instalación pero normalmente es complicado disponer de teléfonos con habilitación para realizar llamadas salientes en grandes centros y que además no estén con sus líneas telefónicas saturadas.
  • WebPos (+): simple pero no posee todas las transacciones implementadas, si le permitirá realizar todas las verificaciones para atender a los pacientes sin riesgos. Requiere que disponga de conexión.
  • eMail (+): simple pero requiere el conocimiento de una nueva filosofía de trabajo que es la transacción incremental.

Envío de la transacción como Diferida: las aplicaciones integradas disponen de un tipo de transacción que les permite reeneviar solicitudes pero que estas sean procesadas con la particularidad de que el servicio ya se realizó. Es decir el financiador contempla la posibilidad eventual de que pudiera haber ocurrido un problema técnico al momento del envío de la transacción original y ofrece esta alternativa a través de la cual la transacción es sometida reglas más laxas de control una vez que el problema haya sido solucionado. Esta transacción solo debe utilizar en circunstancias especiales. Su uso injustificado podría derivar en un débito.

Utilización de una aplicación local de validación: PCPOS es una aplicación desarrollada por ITC cuya única función es la realización de transacciones. Es posible utilizar es aplicación ya sea para realizar transacciones poco frecuentes que no se encuentran homologadas en el sistema de gestión, como una aplicación de contingencia, o para ser utiliza en algún lugar aislado que posea el prestador en el cual no disponga de conexión con el sistema principal del centro. El uso de esta aplicación requiere un doble data entry de datos (en la aplicación y luego en el sistema de gestión del prestador. Existen formas de exportar las transacciones procesadas en PCPOS).

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.

Migrar a V250

La migración de farmacias a V250 solo se justifica para mejoras marginales si ya está utilizando V000 y V101. Entre los beneficios más importantes:

  • Poder realizar transacciones para Rescatar una Prescripción Digital es decir atender pacientes que se presentan sin receta papel.
  • Hacer una Consulta de ticket donde no registra una autorización en la cuenta corriente
  • Hacer una Alta diferida de ticket solo para casos excepcionales se permite comunicar una dispensa ya realiza
  • Hacer una Verificar Beneficiario
  • Hacer una Verificar Beneficiario / Medicamento
  • Hacer una Solicitar autorización
  • Hacer una Consultar Resolución Solicitud Autorización
  • Reimprir un Ticket

En relación a la presentación de la liquidación, este formato permite:

  • Excluir receta de un Cierre de Lote
  • Incluir receta previamente excluida

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
Formato V250 Operación 06. Rescatar una Receta Electrónica Identificación del financiador se realiza en _svl.0. Indica quién realizará la cobertura, y el dominio donde se encuentra la receta campo Tarjeta identificación de la cobertura 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. campo Documento Retira opcional pero sugerido 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.

Prescripción Electrónica

La nueva ley de Receta Digital permite al médico extender una receta digital por medicamentos y por estudios.

  • En V250 el archivo _svl.3 opcional permite el envío de información complementaria para la prescripción de medicamentos. N registros. Este archivo contiene una descripción de cada uno de los items de la receta.

Ir al formato.

Migrar a V107

Si usted ya posee su sistema homologado con versiones anteriores de la familia V10x migrar a V107 le proveerá de las siguientes nuevas funciones, con una modificación muy simple dado que la adopción de este formato es solo una extensión del tamaño de los archivos de envío y recepción.

Función Características nuevas
Campo BANDA Te permite enviar el string leido con un lector sin necesidad de conocer el algoritmo de parseo que difiere de tarjeta en tarjeta y obtener de la respuesta los datos ya parseados.
Datos de respuesta del afiliado enriquecidos En la respuesta obtendrás datos del afiliado que antes solo estaban disponibles con información en el ticket y no como dato. Por ejemplo NOMBRE, SEXO, y FECHANACIMIENTO
Mejor manejo de Cosegures Se incluyen el coseguro total a cobrar al afiliado y los montos discriminados por prestación.
Nuevas transacciones médicas Posibilidad de adjuntar archivos a la transacción permitiendo el envio de datos complementarios: Protocolo Quirúrgico, Protocolo Anestesia, Informe Médico, Resultado de Laboratorio, Pre-factura
Nuevas transacciones administrativas Consulta de Tickets, Consulta de Lotes, Cierres de Lote que permitirán en un futuro la liquidación electrónica sin necesidad de enviar un archivo ni papeles.
Flexibilidad embebida para el futuro Campos filler para incorporar datos futuros de envío o respuesta manteniendo la longitud fija.

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>

Obtenido de «http://wiki.itcsoluciones.com/index.php?title=Homologar&oldid=2832»