implementacion_fhir_facturacion_y_debitos

Introducción

Esta guía define como hacer uso del estándar FHIR DSTU 2 para la transmisión en forma de recursos de los datos de facturación y débitos entre prestadores y financiadores de salud.
Se han estudiado los recursos necesarios a intercambiar para hacer un uso acorde a las necesidades en el ámbito nacional.

Actualmente hay cientos de formatos que dependen de cada financiador para la transferencia de información de facturación y casi no hay implementaciones para el caso de los débitos. Por otra parte el desarrollo de la guía de implementación MAIS para los adjuntos a facturación permitirá integrar los ítems facturables con la documentación respaldatoria asociada a cada servicio.

Se intercambian transacciones electrónicas con los ítems facturables mensajes electrónicos con información en salud entre instituciones con Sistemas de Información diferentes. La información de facturación fluye desde los prestadores y los financiadores, y la información de débitos, desde los financiadores a los prestadores una vez analizada cada liquidación.
A continuación se detalla una tabla con los perfiles definidos:

Ver Glosario

  1. Transacciones de Facturación: Se producen cuando la organización prestadora envía un resumen de servicios prestados o (‘liquidación’ o ‘facturación’) para que la organización financiadora realice el pago correspondiente o debite total o parcialmente los ítems de facturación observados (ver transacciones de débitos)
  2. Transacciones de Débitos: Se producen cuando la organización financiadora envía un resumen de los ítems observados en un resumen de servicios liquidados, expresando para cada uno el motivo del débito y el importe debitado.

El estándar utilizado es FHIR DSTU 2.0.
La versión definitiva de FHIR se espera para fin de 2016, pero debido a los requerimientos tecnológicos y funcionales de la especificación, era el estándar más adecuado para nuestro escenario.

FHIR puede utilizar tres paradigmas de interoperabilidad: Mensajería, Documentos Clínicos y Recursos. Se seleccionó el paradigma de recursos en forma de transacción por ser el más apropiado, ya que la información no se intercambia para su consumo humano principalmente (paradigma de documentos), ni se espera una respuesta activa (modelo de mensajes) por parte del receptor, sino que se agrupa un conjunto de recursos (ítems de facturación o débitos) para su procesamiento, y este puede ser asincrónico.

Opción 1: El transporte de las transaciones se realiza a través de REST, esto es, se realiza un POST al end point de la aplicación receptora utilizando lo que se denomina en FHIR un Bundle de tipo Transaction. La respuesta a cada transacción es SINCRÓNICA, pero solamente consiste en una respuesta general que implica la aceptación de los ítems para su procesamiento o la descripción de errores puntuales, no la aceptación inmediata de los ítems facturables.
Opción 2: El archivo XML o JSON con las transacciones de cada liquidación se envían por correo, medio magnético o FTP del emisor al receptor. En este caso no se recibe respuesta inmediata del financiador sino en forma de débitos una vez procesado el archivo.

FHIR sugiere la utilización de la especificación oAuth v.2.0 para la seguridad entre aplicaciones.

FHIR soporta para el intercambio de recursos y mensajes las sintaxis JSON y XML.
Ambas son semánticamente equivalentes. Los ejemplos que acompañan esta guía están expresados en XML, pero es trivial traducirlos a JSON.

var xml = new XmlDocument();
xml.LoadXml(xmlString);
string jsonString = Newtonsoft.Json.JsonConvert.SerializeXmlNode(xml, Newtonsoft.Json.Formatting.None);
Response.ContentType = "application/json";
Response.Write(Newtonsoft.Json.JsonConvert.SerializeObject(jsonString));

Definición de contenidos

Los mensajes están basados en combinaciones (de acuerdo a las necesidades específicas de cada escenario) de los siguientes recursos: Bundle: Contenedor para todos los recursos involucrados en una transacción específica, puede ser de tipo transaction, document, search o MessageHeader. El utilizado en nuestro caso es ‘transaction’. Patient: Información acerca del paciente – datos demográficos y de afiliación. Organization: detalle de las organizaciones participantes - razón social, identificación -, ya sean prestadoras o financiadoras de salud. OperationOutcome: resultado de una operación realizada – se incluye como parte de la respuesta a la transacción en todos los casos Encounter: se utiliza para describir un episodio de atención (generalmente en el caso de internación o urgencias) al que corresponden algunos ítems de facturación. Practitioner: se utiliza para identificar a los médicos solicitantes y a los profesionales prestadores.

Ver detalles en archivo ExtensionesMAIS.xlsx

NombreDescripción
SituacionIVAPacienteTipo de IVA Paciente (Voluntario, Obligatorio, Particular)
ReliquidacionMarca de reliquidacion, si esta en true, el item es una reliquidacion
ReliquidacionNumeroFacturaNumero de factura original, en caso de reliquidacion
ValorHonorariosValor de Honorarios Facturados, en pesos
ValorGastosValor de Gastos Facturados, en pesos
ImporteExentoValor de Importe Exento, en pesos
ImporteGravadoValor de Importe Gravado, en pesos
DiferencialCodigoCódigo de diferencial facturado
DiferencialCantidadCantidad de diferencial facturado
TipoArancelCodigoCódigo de Tipo de Arancel
TipoArancelCantidadCantidad por Tipo de Arancel
PiezaDentalCodigo identificador de pieza dental
CaraDentalCodigo identificador de cara dental
SectorDentalCodigo identificador de sector dental
MaxilarDentalCodigo identificador de maxilar

Ver el análisis de información y los xpath para cada ítem de información definido en el archivo ANALISIS_DE_INFORMACION.

En síntesis, los recursos para cada tipo de transacción son los siguientes:

Bundle (“transaction”)

1…1 Organization (Prestadora)

1…1 Organization (Financiadora)

1..n Claim (Detalle de Item de Facturacion)

Patient (Afiliado)

Practitioner (Solicitante)

Practitioner (Efector)

ClaimResponse (Autorizacion)

Encounter (Episodio)

DocumentReference (Documento Respaldatorio)

Bundle: (“transaction”)

1…1 Organization (Prestadora)

1…1 Organization (Financiadora)

1..n ClaimResponse (Detalle de Debito)

Claim (Item Original Facturado)

Patient (Afiliado)

El esquema genérico para validar el XML de cada interacción es fhir-all-xsd/bundle.xsd. Los esquemas pueden descargarse de: http://hl7.org/implement/standards/fhir/fhir-allxsd.zip

Ver los ejemplos para cada transacción en los archivos

XML: EjemploMAISFacturacion.xml y EjemploMAISDebito.xml

JSON: EjemploMAISFacturacion.json y EjemploMAISDebito.json

Ver MAIS_Profesionales_Identificacion_Clasificacion

Desarrollada por la Subcomisión para Identificación de Profesionales, compuesta por:

  • Pilar Rey Nores del Hospital Privado de Córdoba
  • María Del Carmen Quispe de Swiss Medical
  • Fernanda Aguirre Ojea de PAMI
  • Andrea Nishioka de FLENI
  • Humberto F. Mandirola B. de HL7 Argentina, Hospital Italiano

Desarrollado por: Comsión redactora de guía de implementación de transacciones

Documentos anexos a la facturación

  • implementacion_fhir_facturacion_y_debitos.txt
  • Última modificación: 2019/03/25 14:00
  • por jorge.brugger_dasu