Da Vinci PAS-Metriken mit SQL on FHIR in Aidbox

Prior Authorization ist ein anhaltender Reibungspunkt im US-amerikanischen Gesundheitswesen, und der Druck, sie zu messen, wächst stetig: Kostenträger möchten sehen, wo es stockt, und die entsprechende Berichterstattung ist auf dem Weg, eine regulatorische Anforderung zu werden. Das bedeutet, Einreichungsvolumen, Fehlerquote und Zeit bis zur Entscheidung zu messen.

Das Da Vinci PAS IG benennt zehn operative Metriken und enthält ein PASMetricData-Logikmodell, das die Datenbasis für die Metriken beschreibt.

Deren Berechnung erfordert üblicherweise, die Daten in ein separates Analysesystem zu kopieren und jede Metrik dort neu zu implementieren – eine Eigenentwicklung, die an jeder Stelle wiederholt wird und von der Quelle abweicht. Wir wollten das Gegenteil: jede Metrik einmal definieren, direkt neben den Daten ausführen und mit den bereits vorhandenen BI-Tools lesen. Da die Transformation deklarativ ist und in der Datenbank verbleibt, wird nichts ausgelagert, was synchron gehalten werden müsste, und es muss kein zweiter Analytics-Stack aufgebaut werden. Aidbox bot dafür bereits eine Lösung: das integrierte SQL on FHIR.

SQL on FHIR in einer Minute

SQL on FHIR standardisiert sowohl die Abflachung als auch die Abfragen darüber, anstatt dass jeder Anbieter seinen eigenen Weg zur Abfrage verschachtelter Ressourcen erfindet. Ihre Metriken werden zu portablen, standardisierten FHIR-Artefakten – interoperable Analytics, hier ausführlich erklärt. Die Bausteine:

1. ViewDefinition: ein portables Format zur Definition tabellarischer Sichten auf FHIR-Daten.
2. SQLQuery und SQLView: teilbares SQL über diese Sichten, basierend auf der FHIR- Library-Ressource. Eine SQLQuery akzeptiert Parameter, beispielsweise einen Berichtszeitraum; eine SQLView ist parameterlos.
3. HTTP API: Standard-FHIR-Operationen ($viewdefinition-run, $sqlquery-run) zur Ausführung von Sichten und Abfragen.

Aidbox führt all dies gegen dieselbe Postgres-Instanz aus, die auch die Live-FHIR-API unterstützt, sodass Daten und Analytics in einer einzigen Datenbank liegen.

Fünf Schichten – von rohen FHIR-Daten bis zum Dashboard

PAS-Daten sind schwierig zu glätten. Sie sind X12-abgeleitet, mit Antworten, die über mehrere Zyklen eintreffen, und Metriken, die sich über Claim, ClaimResponse sowie den beteiligten Leistungserbringer und die Versicherungsdeckung erstrecken. Keine einzelne Sicht liefert eine Metrikzeile; daher ist die Pipeline in Schichten aufgebaut, wobei jede die darunter liegende liest – und der Graph dieser Schichten ist die Herkunftskette (Lineage).

Das Stapeln flacher Sichten zu einem gemeinsamen Modell und anschließend das Aufsetzen von Metriken darüber ist das allgemeine Analytics-Muster, das in SQL on FHIR: Interoperable Analytics ausführlich beschrieben wird; hier wenden wir es auf PAS an:

Das IG definiert zehn Metriken:

Wir werden die erste Metrik, das Einreichungsvolumen, durchgehen, da sie die unkomplizierteste ist. Wir verfolgen sie Schicht für Schicht, beginnend bei Schicht 1, den rohen Ressourcen.

Schicht 1: Nehmen wir zwei Vorabgenehmigungsansprüche (Preauthorization Claims), c1 mit zwei Einzelpositionen und c2 mit einer. Hier ist c1 als verschachteltes JSON:

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

Schicht 2: Eine ViewDefinition übernimmt die Abflachung. Eine where-Bedingung filtert die Vorabgenehmigungsansprüche, und forEach über item wandelt das Array in eine Zeile pro Position um. Jede Spalte ist ein FHIRPath- Ausdruck: getResourceKey() und getReferenceKey() für IDs und Referenzen, gewöhnliche Pfade für den Rest – selbst Werte, die tief in PAS-Erweiterungen verborgen sind, ohne benutzerdefiniertes Parsen:

{
  "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" }] }
  ]
}

Über beide Ansprüche hinweg ergibt das eine Zeile pro Position:

Schicht 3: Eine SQLView, ClaimWithProviderView, verbindet ClaimView mit PractitionerView, um die NPI des Leistungserbringers hinzuzufügen:

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

was folgendes ergibt:

Schicht 4: das Modell.

Die Antwortseite, ResponseResultView, wird analog zur Anspruchsseite aufgebaut: Eine ViewDefinition glättet jedes ClaimResponse-Element, und eine SQLView macht dessen claim, item und result zugänglich. PASMetricDataView verbindet jede Anspruchsposition per Left Join mit ihrer Antwort, sodass jede Zeile sowohl die Anfrage als auch deren Ergebnis enthält – das PASMetricData-Modell, hier als eine Zeile pro Einzelposition realisiert:

-- 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

was das gemeinsame Modell liefert, gegen das jede Metrik ausgeführt wird:

Schicht 5: Das Einreichungsvolumen ist eine Aggregation über dieses Modell, eine SQLQuery. Sie ist eine Adoptionsmetrik und zählt daher Einreichungen und Positionen pro Berichtsjahr, das ein Dashboard nach Bedarf filtern kann:

-- 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

Als SQLQuery-Ressource trägt sie eine kanonische URL, ihre depends-on-Abhängigkeit (PASMetricDataView) und das SQL. Der Parameter-Slot ist hier leer, aber dort könnte beispielsweise ein Filter für einen Berichtszeitraum eingefügt werden:

Führt man sie aus, ergibt sich für unsere beiden Ansprüche, beide aus dem Jahr 2026: zwei eindeutige Exchanges, c1 und c2, also 2 Einreichungen, und drei Positions-Zeilen, also 3 Servicepositionen:

Lineage ohne Mehraufwand

In den meisten Stacks ist Lineage Zusatzarbeit: ein separates Tool oder ein Diagramm, das jemand manuell aktuell hält. Aidbox leitet sie ab. Da jede SQLView und SQLQuery ihre Eingaben über relatedArtifact: depends-on benennt, kennt Aidbox in dem Moment, in dem die Artefakte geladen werden, den Abhängigkeitsgraph und visualisiert ihn – vom rohen Ressourcentyp bis zur Metrik.

Jeder Knoten lässt sich einzeln ausführen, sodass das Debugging konkret ist: Eine einzelne ViewDefinition, SQLView oder SQLQuery wird für sich ausgeführt, ihr Ergebnis betrachtet, und eine Zahl in einem Diagramm lässt sich bis zum FHIRPath- Ausdruck zurückverfolgen, der sie erzeugt hat.

Hier ist die Lineage, die Aidbox für die Einreichungsvolumen-Metrik zeichnet. Claim, Practitioner und ClaimResponse werden in ViewDefinitions abgeflacht, die die ClaimWithProviderView- und ResponseResultView-SQLViews speisen, dann das PASMetricDataView- Modell, dann die SubmissionVolume-Abfrage:

Der reale PAS-Graph ist größer: Dasselbe Modell (PASMetricDataView) speist die anderen neun Metriken, von denen jede ihre Eingaben auf dieselbe Weise deklariert.

Überall ausführbar, für jedes BI-Tool nutzbar

$sqlquery-run führt eine Metrik sofort gegen Live-Daten aus, was praktisch ist, während man eine Metrik entwickelt oder eine Ad-hoc-Frage beantwortet.

Für Dashboards wird jede Metrik zu einer materialisierten Postgres-Sicht, vorberechnet und in-place aktualisiert. Metabase, Tableau oder Power BI verbinden sich mit einer einfachen Tabelle und sehen das darunterliegende FHIR nie. Es wird nichts exportiert, und es gibt kein Warehouse zu synchronisieren; die Analytics liegen in derselben Postgres-Instanz wie die FHIR- Daten.

Was am Ende vorliegt

Die Metriken liegen am Ende als eine Handvoll gewöhnlicher FHIR-Ressourcen vor – ViewDefinitions, SQLViews und SQLQueries –, keine benutzerdefinierte Pipeline. Das passt gut zu PAS, das sich noch im Wandel befindet: PASMetricData ist eher eine Referenzform als eine feste, und die Metriken drum herum ändern sich weiter. Wenn das passiert, bearbeitet man ein Artefakt, und der Rest des Graphs folgt. All das ist auch nicht PAS-spezifisch: Jedes IG, das Metriken oder auch nur ein Logikmodell definiert, kann auf dieselbe Weise aufgebaut werden.

Da es sich um Ressourcen handelt, werden sie versioniert, in ein Paket gebündelt und mit einem einzigen Upload installiert. In der Lineage-Ansicht kann jeder Knoten ad hoc ausgeführt, debuggt oder geändert werden, und $sqlquery-run führt jeden beliebigen Ausschnitt aus, auf den man es zeigt: eine einzelne Sicht, den Pfad einer Metrik zurück zur Quelle oder das gesamte Modell auf einmal.

Möchten Sie PAS-Metriken auf Ihren eigenen Daten ausführen? Probieren Sie eine Sicht im ViewDefinition builder aus, oder bauen Sie die vollständige Pipeline selbst in Aidbox.

Kostenträger, die mit der CMS-0057-F-Berichtspflicht zur Prior Authorization konfrontiert sind, erhalten Da Vinci PAS-Unterstützung, fertig paketiert und einsatzbereit, mit Payerbox, der CMS-0057-F-Lösung von Health Samurai.

Sprechen Sie mit unserem Team, um loszulegen.

Siehe auch:

• SQL on FHIR: Interoperable Analytics – das allgemeine Muster hinter dieser Pipeline

Referenzen

• Da Vinci PAS IG und dessen Metriken-Seite
• PASMetricData-Logikmodell
• SQL on FHIR-Spezifikation und die ViewDefinition-Ressource
• „SQL on FHIR: Interoperable Analytics", Nikolai Ryzhikov
• „SQL on FHIR: tabular views of FHIR data using FHIRPath", npj Digital Medicine
• FHIRPath
• ViewDefinition builder