> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clinero.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Potenzial-Check per API

> Abrechnungspotenzial einer Praxis programmatisch mit der Clinero-Regelprüfung analysieren.

Der Potenzial-Check analysiert die Behandlungs- und Abrechnungsdaten einer Praxis mit der
Clinero-Regelprüfung und liefert für ein Abrechnungsquartal:

* **Potenzial**: Gebührenziffern, die hätten abgerechnet werden können, aber nicht erfasst wurden — inklusive Punkt- und Euro-Summe.
* **Korrekturen**: Ziffern, die entfernt werden müssen.
* **Begrenzungen**: Ziffern, die durch Abrechnungsbestimmungen (z. B. Häufigkeitsregeln) limitiert wurden.

Die vollständige Feldreferenz finden Sie unter [Potenzial-Check durchführen](/api-referenz/potenzial-check).

## Authentifizierung

Alle Anfragen benötigen einen API-Key im Header `X-Api-Key`:

```bash theme={null}
curl --request POST \
  --url https://ui.clinero.de/api/v1/potential-check \
  --header "X-Api-Key: ck_..." \
  --header "Content-Type: application/json" \
  --data @anfrage.json
```

API-Keys werden vom Clinero-Team ausgestellt. Wenden Sie sich an
[support@clinero.de](mailto:support@clinero.de), um einen Key zu erhalten. Keys können
jederzeit widerrufen werden; behandeln Sie sie wie ein Passwort und übertragen Sie sie
niemals im Anfrage-Body oder in URLs.

## Wie viel Behandlungshistorie wird benötigt?

<Warning>
  Übermitteln Sie **die vollständige Behandlungshistorie** der Patienten, nicht nur die
  Termine des Zielquartals. Viele Abrechnungsbestimmungen sind Häufigkeitsregeln
  („einmal pro Kalenderjahr", „einmal je Fall"). Fehlt die Historie, kann die Prüfung
  diese Regeln nicht anwenden und **überschätzt das Potenzial**.
</Warning>

Richtwerte:

| Umfang | Ergebnisqualität |
| - | - |
| Nur das Zielquartal | Nicht empfohlen — Häufigkeitsregeln greifen nicht. |
| 2–3 Jahre | Gute Basis für die meisten BEMA-Regeln. |
| **5 Jahre** | **Erforderlich für eine zuverlässige PAR-Erkennung** (Parodontitis-Behandlungsstrecken erstrecken sich über mehrere Jahre). |

Das Feld `quarter` bestimmt, welches Quartal analysiert wird — die übrige Historie dient
der Regelprüfung als Kontext und erscheint nicht in den Ergebnissen.

## Aufbau der Anfrage

Die Anfrage ist ein JSON-Objekt mit dem Zielquartal, dem KZV-Bereich (`bundesland`) und
einer Liste von Patienten. Jeder Patient bringt seinen Zahnbefund und seine
Terminhistorie mit:

```json theme={null}
{
  "quarter": { "year": 2026, "quarter": 2 },
  "bundesland": "BW",
  "patients": [
    {
      "id": "12345",
      "birthday": "1980-04-12",
      "insurance_status": "public",
      "befund": {
        "16": ["crown"],
        "24": ["caries", "vital"],
        "36": ["missing"]
      },
      "appointments": [
        {
          "date": "2026-04-03",
          "documentation": "eingehende Untersuchung, ZST o.B., Mundhygiene besprochen",
          "codings": [
            { "code": "01", "schema_type": "BEMA" }
          ]
        }
      ]
    }
  ]
}
```

Hinweise:

* `id` ist Ihre Patienten-ID; sie wird unverändert in den Ergebnissen zurückgegeben und muss innerhalb der Anfrage eindeutig sein.
* `documentation` ist der Freitext der Behandlungsdokumentation aus dem PVS. Die Regelerkennung wertet diesen Text aus — je vollständiger, desto zuverlässiger das Ergebnis.
* `birthday` ist erforderlich, da einige Leistungen altersabhängig sind (z. B. IP und FU).
* `bundesland` verwendet die KZV-Kürzel; Nordrhein-Westfalen ist in `NR` (Nordrhein) und `WL` (Westfalen-Lippe) geteilt.

## Der Zahnbefund

`befund` ist für jeden Patienten erforderlich und bildet den Zahnstatus im FDI-Schema ab:
Schlüssel sind die Zahnnummern `18`–`48`, Werte sind Listen von Befund-Tokens. Zähne ohne
Befund können weggelassen werden. Ohne Befund können prothetik- und
erhaltungsbezogene Regeln nicht greifen.

| Token | Bedeutung (Dampsoft-Kürzel) |
| - | - |
| `vital` | vital (+) |
| `dead` | tot (-) |
| `caries` | Karies |
| `filling` | Füllung |
| `inlay` | Inlay |
| `missing` | fehlt (f) |
| `gap_closed` | Lückenschluss (l) |
| `crown` | Krone (k) |
| `crown_renew` | Krone erneuerungsbedürftig (kw) |
| `partial_defect` | Teildefekt (pw) |
| `partial_crown_renew` | Teilkrone erneuerungsbedürftig (pkw) |
| `post_crown` | Stiftkrone (r) |
| `post_crown_renew` | Stiftkrone erneuerungsbedürftig (rw) |
| `bridge` | Brückenglied (b) |
| `bridge_renew` | Brückenglied erneuerungsbedürftig (bw) |
| `adhesive_anchor` | Adhäsivbrücken-Anker (a) |
| `adhesive_anchor_renew` | Adhäsivbrücken-Anker erneuerungsbedürftig (aw) |
| `adhesive_bridge` | Adhäsivbrücken-Glied (ab) |
| `adhesive_bridge_renew` | Adhäsivbrücken-Glied erneuerungsbedürftig (abw) |
| `replaced` | ersetzt (e) |
| `replaced_renew` | Ersatz erneuerungsbedürftig (ew) |
| `telescope` | Teleskopkrone (t) |
| `telescope_renew` | Teleskopkrone erneuerungsbedürftig (tw) |
| `telescope_secondary_renew` | Sekundärteil erneuerungsbedürftig (t2w) |
| `implant_crown` | Implantatkrone (sk / j) |
| `implant_crown_renew` | Implantatkrone erneuerungsbedürftig (skw) |
| `implant_bridge` | Implantat-Brückenglied (sb) |
| `implant_bridge_renew` | Implantat-Brückenglied erneuerungsbedürftig (sbw) |
| `implant_denture_tooth` | Implantatgetragener Ersatzzahn (se) |
| `implant_denture_tooth_renew` | Implantatgetragener Ersatzzahn erneuerungsbedürftig (sew) |
| `implant_connector` | Implantat-Verbinder (so) |
| `implant_connector_renew` | Implantat-Verbinder erneuerungsbedürftig (sow) |
| `implant_telescope` | Implantat-Teleskop (st) |
| `implant_telescope_renew` | Implantat-Teleskop erneuerungsbedürftig (stw) |
| `implant_remove` | Implantat zu entfernen (ix) |
| `retention_insufficient` | Unzureichende Retention (ur) |
| `severe_damage` | Stark zerstört (ww) |
| `non_restorable` | Nicht erhaltungswürdig (x) |

## Das Ergebnis lesen

Die Antwort enthält vier Ebenen:

* `summary` — die Kernzahlen des Quartals, inklusive `total_add_points` und `total_add_eur` (Punkte × Punktwert).
* `add_code_stats` — das Potenzial aggregiert je Gebührenziffer.
* `rule_impacts` — welche Regeln wie oft ausgelöst haben, mit fachlicher Begründung.
* `appointments` — die betroffenen Termine mit den konkreten Vorschlägen (`add_codes`, `remove_codes`) je Patient und Datum. Termine ohne Auffälligkeiten sind nicht enthalten.

## Grenzen und Datenschutz

* Die Analyse läuft synchron; bei sehr großen Praxen (mehrere zehntausend Termine) kann die Antwort entsprechend dauern.
* Die übermittelten Daten werden ausschließlich zur Berechnung der Antwort verarbeitet und nicht gespeichert.
* Für die Übermittlung von Patientendaten ist ein Auftragsverarbeitungsvertrag (AVV) mit Clinero erforderlich. Wenden Sie sich dazu an [support@clinero.de](mailto:support@clinero.de).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.