Métricas Da Vinci PAS con SQL on FHIR en Aidbox

La autorización previa es un punto de fricción persistente en el sistema sanitario de EE. UU., y la presión para medirla no deja de crecer: los pagadores quieren saber dónde se estanca, y reportarla está en camino de convertirse en un requisito regulatorio. Eso implica medir el volumen de envíos, la tasa de errores y el tiempo hasta la decisión.

El IG Da Vinci PAS define diez métricas operativas e incluye un modelo lógico PASMetricData que sugiere los datos en los que se basan dichas métricas.

Calcularlas habitualmente implica copiar los datos a un sistema analítico independiente y reconstruir cada métrica allí, un trabajo a medida que se repite en cada implantación y se desincroniza con el origen. Queríamos lo contrario: definir cada métrica una sola vez, ejecutarla junto a los datos y leerla con las herramientas de BI que ya se utilizan. Como la transformación es declarativa y permanece en la base de datos, no hay nada que copiar para mantener sincronizado ni una segunda pila analítica que construir. Aidbox ya disponía de una forma de hacer esto: SQL on FHIR integrado.

SQL on FHIR en un minuto

SQL on FHIR estandariza tanto el aplanamiento como las consultas sobre él, en lugar de que cada proveedor invente su propia forma de consultar recursos anidados. Sus métricas se convierten en artefactos FHIR portátiles y estándar, analítica interoperable, explicada en detalle aquí. Las piezas:

1. ViewDefinition: un formato portátil para definir vistas tabulares de datos FHIR.
2. SQLQuery y SQLView: SQL compartible sobre dichas vistas, basado en el recurso FHIR Library. Un SQLQuery admite parámetros, por ejemplo un rango de fechas de reporte; un SQLView no tiene parámetros.
3. HTTP API: operaciones FHIR estándar ($viewdefinition-run, $sqlquery-run) para ejecutar vistas y consultas.

Aidbox ejecuta todo esto contra el mismo Postgres que respalda la API FHIR en producción, de modo que los datos y la analítica conviven en una sola base de datos.

Cinco capas, del FHIR en bruto al dashboard

Los datos PAS son complicados de aplanar. Derivan de X12, con respuestas que llegan a lo largo de varios ciclos, y métricas que abarcan Claim, ClaimResponse y el proveedor y la cobertura asociados. Ninguna vista individual proporciona una fila de métrica, por lo que el pipeline se construye en capas, cada una leyendo de la anterior, y el grafo de esas capas constituye el linaje.

Apilar vistas planas en un modelo compartido y luego añadir las métricas encima es el patrón general de analítica descrito en detalle en SQL on FHIR: Interoperable Analytics; aquí lo aplicamos a PAS:

El IG define diez métricas:

Desarrollaremos la primera, el volumen de envíos, por ser la más sencilla. La trazamos capa por capa, comenzando por la Capa 1, los recursos en bruto.

Capa 1: tomamos dos reclamaciones de preautorización, c1 con dos elementos de línea y c2 con uno. Aquí está c1 como JSON anidado:

{
  "resourceType": "Claim",
  "use": "preauthorization",
  "created": "2026-02-01",
  "provider": { "reference": "Practitioner/p1" },
  "item": [ { "sequence": 1, ... }, { "sequence": 2, ... } ]
}

Capa 2: una ViewDefinition realiza el aplanamiento. Un where conserva las reclamaciones de preautorización y forEach sobre item convierte el array en una fila por elemento. Cada columna es una expresión FHIRPath: getResourceKey() y getReferenceKey() para ids y referencias, rutas ordinarias para el resto, incluso valores enterrados en extensiones PAS, sin ningún análisis sintáctico personalizado:

{
  "resourceType": "ViewDefinition",
  "name": "ClaimView",
  "resource": "Claim",
  "where": [{ "path": "use = 'preauthorization'" }],
  "select": [
    { "column": [
      { "name": "claim",    "path": "getResourceKey()" },
      { "name": "created",  "path": "created" },
      { "name": "provider", "path": "provider.getReferenceKey()" }
    ]},
    { "forEach": "item", "column": [{ "name": "item", "path": "sequence" }] }
  ]
}

Para ambas reclamaciones, esto da una fila por elemento:

Capa 3: un SQLView, ClaimWithProviderView, une ClaimView con PractitionerView para añadir el NPI del proveedor:

-- depends on: ClaimView, PractitionerView
select c.*, pr.npi as provider_npi
from "ClaimView" c
left join "PractitionerView" pr on pr.id = c.provider

lo que da:

Capa 4: el modelo.

El lado de la respuesta, ResponseResultView, se construye como el lado de la reclamación: una ViewDefinition aplana cada elemento de ClaimResponse y un SQLView expone su claim, item y result. PASMetricDataView realiza un left-join de cada elemento de reclamación con su respuesta, de modo que cada fila contiene tanto la solicitud como su resultado, el modelo PASMetricData realizado aquí como una fila por elemento de línea:

-- depends on: ClaimWithProviderView, ResponseResultView
select c.claim   as exchange_id,
       c.item    as item_sequence,
       c.created as request_time,
       r.result
from "ClaimWithProviderView" c
left join "ResponseResultView" r
  on r.claim = c.claim and r.item = c.item

lo que da el modelo compartido sobre el que se ejecuta cada métrica:

Capa 5: el volumen de envíos es un agregado sobre ese modelo, un SQLQuery. Es una métrica de adopción, por lo que cuenta envíos y elementos por año de reporte, que un dashboard puede filtrar al año que necesite:

-- SubmissionVolume, by reporting year
-- depends on: PASMetricDataView
select extract(year from request_time)::int as reporting_year,
       count(distinct exchange_id) as submission_count,
       count(*) as service_item_count
from "PASMetricDataView"
group by reporting_year

Como recurso SQLQuery incluye una URL canónica, su depends-on (PASMetricDataView) y el SQL. El apartado de parámetros está vacío aquí, pero es donde podría conectarse un filtro como un rango de fechas de reporte:

Al ejecutarlo con nuestras dos reclamaciones, ambas de 2026: dos intercambios distintos, c1 y c2, es decir, 2 envíos, y tres filas de elementos, es decir, 3 elementos de servicio:

Linaje sin esfuerzo adicional

En la mayoría de las pilas, el linaje es trabajo extra: una herramienta separada o un diagrama que alguien actualiza manualmente. Aidbox lo deriva automáticamente. Como cada SQLView y SQLQuery nombra sus entradas con relatedArtifact: depends-on, en el momento en que se cargan los artefactos Aidbox conoce el grafo de dependencias y lo dibuja, desde el tipo de recurso en bruto hasta la métrica.

Cada nodo se ejecuta en su lugar, por lo que la depuración es concreta: ejecute una única ViewDefinition, SQLView o SQLQuery por separado, vea lo que devuelve y rastree un número en un gráfico hasta el FHIRPath que lo produjo.

Aquí está el linaje que Aidbox dibuja para la métrica de volumen de envíos. Claim, Practitioner y ClaimResponse se aplanan en ViewDefinitions, que alimentan los SQLViews ClaimWithProviderView y ResponseResultView, luego el modelo PASMetricDataView y finalmente la consulta SubmissionVolume:

El grafo PAS real es mayor: el mismo modelo (PASMetricDataView) alimenta las otras nueve métricas, cada una declarando sus entradas del mismo modo.

Ejecútelo en cualquier lugar, sirva cualquier herramienta de BI

$sqlquery-run ejecuta una métrica al instante sobre datos en tiempo real, lo cual resulta práctico mientras se está construyendo una métrica o respondiendo a una pregunta puntual.

Para dashboards, cada métrica se convierte en una vista materializada de Postgres, precalculada y actualizada en su lugar. Metabase, Tableau o Power BI se conectan a una tabla ordinaria y no ven el FHIR subyacente. No se exporta nada y no hay ningún almacén que sincronizar; la analítica reside en el mismo Postgres que los datos FHIR.

Con qué se queda al final

Las métricas acaban siendo un puñado de recursos FHIR ordinarios, ViewDefinitions, SQLViews y SQLQueries, no un pipeline personalizado. Esto encaja bien con PAS, que todavía está evolucionando: PASMetricData es una forma de referencia más que una forma fija, y las métricas a su alrededor siguen cambiando. Cuando lo hacen, se edita un artefacto y el resto del grafo se actualiza. Nada de esto es específico de PAS tampoco: cualquier IG que defina métricas, o simplemente un modelo lógico, puede construirse del mismo modo.

Al ser recursos, se versionan, se agrupan en un paquete y se instalan con una sola carga. En la vista de linaje se puede ejecutar, depurar o modificar cualquier nodo de forma puntual, y $sqlquery-run ejecuta cualquier fragmento al que apunte: una única vista, el camino de una métrica hasta el origen, o el modelo completo de una vez.

¿Desea ejecutar métricas PAS sobre sus propios datos? Pruebe una vista en el constructor de ViewDefinition, o construya el pipeline completo usted mismo en Aidbox.

Los pagadores que se enfrentan al reporte de autorización previa de CMS-0057-F pueden obtener el soporte Da Vinci PAS empaquetado y listo para ejecutarse con Payerbox, la solución CMS-0057-F de Health Samurai.

Hable con nuestro equipo para comenzar.

Véase también:

• SQL on FHIR: Interoperable Analytics, el patrón general detrás de este pipeline

Referencias

• IG Da Vinci PAS y su página de métricas
• Modelo lógico PASMetricData
• Especificación SQL on FHIR y el recurso ViewDefinition
• «SQL on FHIR: Interoperable Analytics», Nikolai Ryzhikov
• «SQL on FHIR: tabular views of FHIR data using FHIRPath», npj Digital Medicine
• FHIRPath
• Constructor de ViewDefinition