The FHIR layer
German ambulatory
care navigates by.
Polaris is the platform that apps and agents — including Mira — navigate by. It consumes KBV, Gematik, and Basis-DE implementation guides, owns all writes to Aidbox, and exposes one FHIR R4 contract across every PVS in the German market.
de.cognovis.fhir.praxis- tier 1 hl7.fhir.r4.core · 4.0.1 HL7
- tier 1 de.basisprofil.r4 · 1.5.0 HL7 DE
- tier 1 kbv.basis · kbv.ita.for · kbv.ita.erp KBV
- tier 1 de.cognovis.fhir.praxis · 0.35.0 Cognovis
- tier 2 erezept-workflow · epa.medication · vsdm2 Gematik
- tier 2 kbv.ita.eau KBV
- dental fhir-dental-de · fhir-praxis-de Cognovis
all resolved via npm.cognovis.de — private FHIR registry, proxying packages.fhir.org
One adapter owns all writes.
Apps read one FHIR contract.
architecture overview →
// Every PVS looks like one FHIR R4 server to apps above it. // The adapter is the only thing that writes to Aidbox. interface PvsAdapter { readonly name: string // "x-isynet" | "charly" | "dswin" connect(): Promise<void> sync(opts: SyncOptions): Promise<SyncResult[]> // Writeback: Aidbox → PVS, preserves PVS as system of record writeback(res: FhirResource): Promise<void> } // Builders are PVS-agnostic. They know KBV constraints, not SQL tables. buildPatient(data) → KBV_PR_FOR_Patient buildEncounter(data) → KBV_PR_Base_Encounter buildChargeItem(data) → chargeitem-de-ebm | MIRA-only GOÄ
- pvs Billing · Diagnoses · Stammdaten stays
- mira Scheduling · Controlling · AI moves
- mira/ti eRezept · eAU · ePA · VSDM2 moves
Polaris doesn’t replace the PVS. It projects it into FHIR, then gradually accepts ownership of the domains where the PVS is a liability — scheduling first, TI workflows next.
Adapters, shipped as compiled binaries.
ip-protected delivery · no source in runtime imagepvs-x-isynet
Medatixx x.isynet (WINACS). MSSQL. 2,115 tables profiled, 63 generic tables in sync scope.
pvs-charly
Solutio Charly (dental). PostgreSQL. Uses fhir-dental-de profiles for BEMA/GOZ/FDI bindings.
pvs-dswin · ds4 · cgm
Dampsoft DS-Win, DS4, and CGM systems. Same PvsAdapter contract, same fhir-de builders.
ti-connector
eRezept · eAU · ePA Medication · VSDM2 eGK. PVS-agnostic — reads Aidbox, talks to TI.
adapter-sdk
PvsAdapter interface, sync harness, MSSQL streaming, Aidbox $import, watermark state. Trinity-checklist scaffolds new adapters.
where IGs allow
Polaris is FHIR-based. International installations are viable where equivalent IG ecosystems exist. Not a commitment — an opening.
Install paths
Use the packages through the tooling your team already works with.
Package distribution is centralized through npm.cognovis.de. Canonical documentation stays on fhir.cognovis.de.
Aidbox
BOX_FHIR_NPM_PACKAGE_REGISTRY=https://npm.cognovis.de
FHIR_PACKAGES=de.cognovis.fhir.praxis@0.35.0,de.cognovis.fhir.dental@0.17.0 SUSHI
dependencies:
de.cognovis.fhir.praxis: 0.35.0
de.cognovis.fhir.dental: 0.17.0 IG Publisher
package-id: de.cognovis.fhir.praxis
package-id: de.cognovis.fhir.dental
package-server: https://npm.cognovis.de Canonical stability
Canonical URLs are treated as a trust signal for integration partners and production systems.
Stable canonicals
Canonical URLs identify the actual guide artifacts. Public presentation can evolve without redefining those identifiers.
Registry consistency
Package distribution is centralized through npm.cognovis.de for predictable installation and versioning.
Production orientation
Polaris FHIR is designed for teams building real integrations, not just browsing examples.
Technical contact
Need package support, integration guidance, or a deeper technical conversation around Polaris?
Reach out for technical conversations around guides, registry behavior, install paths, connector models, or product architecture on Polaris.