Ein Datenraum
für jede Praxis,
jedes PVS.
Polaris ist die FHIR-native Datenplattform für die ambulante Versorgung. Sie läuft in der Praxis, verbindet bestehende PVS-Systeme und nutzt die von cognovis gepflegten deutschen Implementation Guides (fhir-praxis-de, fhir-dental-de).
MIRA ist die erste produktive Anwendung auf Polaris und geht im Juni 2026 in einem fachübergreifenden MVZ live.
Polaris wird als Gesamtplattform lizenziert. MIRA ist optional.
Was Polaris für Praxis und MVZ bedeutet.
drei effekte · konkretEin Bild über jede Betriebsstätte.
Auch wenn im MVZ drei PVS parallel laufen, sehen Controlling, Abrechnung und Leitung denselben Patienten — dieselben Scheine, dieselbe Diagnose, dieselbe Ziffer. Betriebsstätten bleiben sauber getrennt (BSNR-scoped), aber auswertbar als Verbund.
EBM, GOÄ, BEMA, GOZ — konsistent.
Ziffern, Scheine und RLV/QZV-Extensions kommen aus dem PVS, landen in einem FHIR-Profil, fließen zurück ins PVS. Abrechnungsfehler, offene Posten und Mahnlauf werden sichtbar — ohne PVS-Klicks.
Betrieb in der Praxis statt SaaS.
Polaris wird in der Praxis betrieben. KI kann lokal laufen; für externe Anfragen stehen automatische Anonymisierungswege bereit. So bleiben DSGVO und §203 im Praxisbetrieb sauber umsetzbar.
Drei Praxen,
drei PVS, ein Cockpit.
Die meisten MVZ betreiben historisch gewachsene PVS-Landschaften. Polaris bindet sie an — nicht umgekehrt. Ihr bestehendes Human- oder Dental-PVS bleibt. Was sich ändert: Sie sehen den Verbund zum ersten Mal als ein System.
- 01 Betriebsstätten-PoolingSaubere BSNR-Trennung, Berichte auf Gesellschaftsebene.
- 02 Identität & RollenEin zentrales Rollen- und Rechtekonzept über mehrere Praxen hinweg.
- 03 Plattform statt EinzellösungPolaris führt Daten aus mehreren PVS in einem einheitlichen FHIR-Datenraum zusammen.
- 04 Offen für aufsetzende AnwendungenAuf Polaris können z.B. MIRA oder Controlling-Lösungen aufsetzen; TI-Workflows bleiben im PVS.
FHIR-nativ —
zukunftssicher
für die Ambulanz.
FHIR R4 ist im deutschen Gesundheitswesen etabliert — von ePA bis eRezept. Im ambulanten Bereich schafft ein einheitliches FHIR-Modell heute schon die Basis, um Daten systemübergreifend nutzbar zu machen, statt später aufwendig zu migrieren.
Wer jetzt auf FHIR setzt, zahlt keine Migrationsprämie, wenn das Mandat kommt.
Der Standard existiert. Die Tooling-Reife ist da. Der Aufwand, heute auf FHIR zu bauen, ist geringer als der Aufwand, ein proprietäres Format später zu migrieren. Praxen und App-Entwickler, die jetzt auf FHIR setzen, zahlen keine Migrationsprämie, wenn das Mandat sie einholt.
Polaris entstand nicht aus einem Produkt-Roadmap. Es ist die Extraktion aus MIRA — einem agenten-getriebenen Abrechnungs- und Praxismanagement-System. Als MIRA reifte, wurde der Integrationsschicht (PVS-Adapter, deutsche FHIR-Profile, Identity-Reconciliation, Agenten-Endpunkt) immer sichtbarer als das dauerhafte, wiederverwendbare Artefakt. Polaris ist dieses Artefakt. Battle-tested, kein Pitch-Deck-Produkt.
Polaris wird als vollständiger Stack verkauft: CDP + CDR + FHIR-Speicher + SDK. Adapter-only-Sales gibt es nicht. Der Wert eines Adapters ist untrennbar vom umgebenden Plattform-Vertrag: Multi-Tenancy, Write-Serialization, Audit-Trail. Wer nur einen PVS-Konnektor ohne den Datenlayer will, baut ihn selbst — wer nur einen PVS-Konnektor ohne Datenlayer will, baut ihn selbst.
Sechs Schichten.
Eine Plattform.
Polaris strukturiert seine Fähigkeiten in sechs Schichten. Jede Schicht hängt nur von den Schichten darunter ab. Anwendungen und Agenten sehen nur die oberste Schicht.
- Polaris als Gesamtsystem (Schicht 1–5) liefert Datenhaltung, Identitäts- und Zugriffsregeln, Adapterbetrieb und SDK als zusammenhängende Plattform.
- Adapter (Schicht 4) sind integraler Bestandteil dieser Plattform: Sie projizieren PVS-Daten in FHIR und sind nicht als isoliertes Einzelprodukt gedacht.
- SDK (Schicht 5) ist das öffentliche Interface für App- und Agent-Entwickler: typisierte FHIR-Builder, deutsche Profil-Konstanten, IGs von npm.cognovis.de.
- polaris-fhir.de → Entwicklerportal, SDK-Dokumentation, IGs
- SDK Einstieg → Typen, Builder, Integrationsmuster
- Plattform-Architektur → Schichtenmodell, ADRs, Adapter-Typen
Polaris ist offen.
Für Partner gebaut.
Die schwere Arbeit — Daten aus PVS extrahieren, FHIR-normalisieren, §203-konform halten, Audit-Trail führen — machen wir. Partner-Anwendungen und Agenten-Entwickler bauen darauf Workflows, die sie wirklich brauchen.
MIRA ist unser Praxisbeweis: Was wir in der eigenen Anwendung produktiv nutzen, stellen wir auch Partnern als belastbare Plattform bereit.
Polaris läuft in der Praxis.
Partner verbinden sich über das SDK mit Polaris. Ob Daten zusätzlich in eigene Systeme übernommen werden, entscheiden Partner und Praxis gemeinsam.
- 01 Öffentliches SDK — kein Reverse-Engineering nötig. Docs auf polaris-fhir.de
- 02 Alle FHIR-Profile öffentlich auf npm.cognovis.de — versioniert, stabile Pakete
- 03 Demo-Daten (install-pvs) zum Entwickeln ohne echten PVS-Zugang
- 04 Audit-Trail weist nach: Jede Schreibaktion geht auf einen Arzt, nicht auf ein Drittsystem
Zwei Wege,
mit Polaris zu arbeiten.
Polaris ist kein Adapter-Marktplatz. Es ist ein vollständiger Plattform-Stack für klinische Daten. Die Kooperation wählt das Modell, das zur eigenen Infrastruktur passt.
Plattform-Subscription
Monatliche Grundgebühr für den Plattformbetrieb (Aidbox, Adapter-Framework, Adapter-CLI, Identity-Reconciliation, Updates) plus eine monatliche Gebühr pro aktiver BSNR. Keine Installationsgebühr.
Partnerbetrieb unter eigener Marke
Für Partnerorganisationen (z.B. PVS-Hersteller, Trägergesellschaften, App-Anbieter), die Polaris unter eigenem Branding anbieten möchten.
Polaris verkauft keine isolierten Adapter. Die Plattform wird als vollständiger Stack gekauft — oder gar nicht. Der Wert eines Adapters entsteht erst im Kontext des Plattform-Vertrags: Multi-Tenancy, Write-Serialization, Audit-Trail. Wer nur einen PVS-Konnektor ohne Datenlayer will, baut ihn selbst.
Was passiert am Montag nach einem PVS-Update?
Die häufigste Sorge bei PVS-Integrationen. Klare Antwort, keine Marketingprosa.
Auswirkung: keine. Der Adapter spricht direkt mit der Datenbankschicht des PVS — nicht mit der Benutzeroberfläche. UI-Änderungen, neue Menüpunkte oder Workflow-Anpassungen im PVS haben keinen Einfluss auf den Adapter.
Polaris betreibt einen CI-Drift-Gate (schema:check), der automatisch Spalten-Additionen und -Entfernungen erkennt. Bei einem Fund wird automatisch ein Arbeitsticket angelegt.
Für Adapter, die wir mitliefern, testen wir neue Herstellerstände in bereitgestellten Testumgebungen. Nach erfolgreichem Durchlauf geben wir das Update frei oder liefern bei Abweichungen kurzfristig einen Fix nach.
Dadurch ist klar: PVS-Updates sind planbar, aber nicht "heute einspielen, morgen ungeprüft produktiv".
| Schweregrad | Kriterium | Reaktionszeit |
|---|---|---|
| P0 | Kein Datenfluss | Nächster Werktag |
| P1 | Teilweiser Datenverlust | Nächster Werktag |
| P2 | Mapping-Lücken | Nächster Sprint |
Für jeden integrierten PVS-Typ betreiben wir eine Entwicklungsumgebung (z.B. charly-dev, xisynet-dev). Wenn ein PVS-Vendor eine Schema-Migration ankündigt, testen wir den Adapter zunächst gegen den Dev-Server. Ein PVS-Update am Freitagabend bricht nicht den Montagmorgen-Betrieb, solange dieser Workflow eingehalten wird.
Klare Kante:
ambulante Versorgung.
- Praxen und MVZ
- Human- und Zahnmedizin
- EBM · GOÄ · BEMA · GOZ
- KBV / KZV / Gematik IGs
- International, wo IGs es zulassen
- Krankenhäuser
- Stationäre Aufnahmen
- OP- und ICU-Workflows
- Pflegeeinrichtungen
- Kassen- oder KV-Software
Diese Grenze ist operativ, nicht technisch. Polaris könnte mehr — wir wollen in der Ambulanz hervorragend sein, bevor wir woanders mittelmäßig sind.
Wir bauen Polaris.
cognovis ist das Team hinter Polaris und MIRA. Wir entwickeln und betreiben die Plattform — und wir sind gleichzeitig ihr erster Kunde.
Cognovis entwickelt und pflegt die deutschen FHIR Implementation Guides (fhir-praxis-de, fhir-dental-de) — die Paketquelle für alle KBV-, Gematik- und Basis-DE-Profile, die Polaris nutzt. Die IGs sind öffentlich auf npm.cognovis.de verfügbar.
MIRA — unsere eigene ambulante Praxis-App — läuft auf Polaris. Wir testen jede Plattform-Version zunächst an uns selbst, bevor sie bei Partnern ankommt. Das ist kein Marketing — das ist unser Deployment-Prozess.
Partneranfrage & Kontakt
Konkrete Gespräche über Architektur, Kooperation und Piloten.
Polaris ist für ernsthafte Produktgespräche, Architektur-Reviews und integrationsintensive Planungen gebaut. Preismodell und Option für Partnerbetrieb unter eigener Marke sind auf dieser Seite erklärt. Custom-Adapter-Kosten bleiben verhandelbar.