One FHIR contract
for German ambulatory
care.
Polaris sits between PVS systems, Aidbox, and the apps or agents above them. It normalizes KBV, Gematik, Basis-DE, and Cognovis profile families into one stable platform surface without asking partners to learn each PVS schema.
FHIR Praxis DE
0.45.1Profiles for practice operations, billing context, and platform-native ambulatory workflows.
FHIR Dental DE
0.29.1Dental profiles for treatment plans, BEMA and GOZ charge flows, and oral-health domain models.
- tier 1 hl7.fhir.r4.core · de.basisprofil.r4 HL7 / HL7 DE
- tier 1 kbv.basis · kbv.ita.for · kbv.ita.erp KBV
- tier 2 erezept-workflow · epa.medication · vsdm2 · kbv.ita.eau Gematik / KBV
One FHIR contract above the adapters.
The PVS stays the system of record.
install overview →
// Apps and agents target one FHIR contract.
// Adapters translate between Aidbox and the external source system.
interface PvsAdapter {
readonly name: string
connect(): Promise<void>
sync(opts: SyncOptions): Promise<SyncResult[]>
writeback(res: FhirResource): Promise<void>
}
// Builders are PVS-agnostic.
// They know profile rules, not SQL table names.
buildPatient(data) -> KBV_PR_FOR_Patient
buildEncounter(data) -> Encounter profile
buildChargeItem(data) -> ChargeItem / Claim profile- pvs Billing · Diagnoses · Source master data system of record
- polaris FHIR contract · Validation · Writeback orchestration platform layer
- apps & agents Scheduling · Automation · Partner workflows build on the contract
Polaris does not ask downstream teams to learn MSSQL schemas, proprietary export formats, or dental billing edge cases. It isolates that complexity behind adapters and publishes one FHIR-facing contract to the rest of the platform.
Shipped adapters, planned coverage, and operator tooling.
compiled delivery · no source in runtime imageHumanmedizin ambulant
Compiled PVS adapter for ambulatory medical practices. Specific source-system support is discussed per rollout and depends on available customer-side access.
Dental ambulant
Dental PVS adapter in development, using the same compiled delivery model and FHIR builder layer, tuned for dental billing and treatment workflows.
Weitere PVS-Adapter
Additional ambulatory PVS targets are planned. Polaris treats each connector as an adapter capability rather than a public vendor partnership claim.
Polaris FHIR SDK · adapter CLI
The public developer surface is the Polaris FHIR SDK, currently published through @polaris/fhir-de. Runtime operations use the adapter CLI for health, sync, and reconciliation.
Two patterns for building on Polaris.
partner SDK · same contractPolaris is infrastructure. Apps and agents consume it through one SDK surface, no matter which PVS sits under the adapter. Teams building on Polaris pick the pattern that fits their product — both are first-class supported.
Your FHIR store, synced from Polaris.
Partner app hosts its own FHIR store in the cloud. Data syncs out of the PVS through Polaris adapters and into the partner store. Partner owns UX and hosting end to end.
- +Full sovereignty over data and UX
- +No dependency on Polaris install base
- −Partner owns PVS-drift maintenance
- −Data leaves the practice to partner cloud
Dock into the CDP, data stays local.
Polaris runs in the practice. Partner cloud reaches in via WireGuard VPN and the SDK. Data can be synced selectively — or tunneled stateless. The §203 problem is solved by construction.
- +Data stays in the practice by default
- +Adapter maintenance handled by Polaris
- +Structural §203 compliance
- −Depends on Polaris rollout in the practice
Your LLM tooling works out of the box.
The Polaris SDK was built for humans and agents on equal footing. The same typed interface that your developers use, Claude Code, Codex, or an in-house MCP client can use too — with anonymization and audit handled at the platform boundary, not at the app.
JSON Schema on every tool
MCP-native tool discovery via tools/list. Agents know the contract before they call.
Anonymized or real
Every tool accepts mode. Default is anonymized; real mode requires Practitioner JWT.
Every call logged
Caller, tool, arguments, mode, response fingerprint. Audit by construction, not by convention.
Use-case tools, not raw FHIR
getEncounterForCodingSuggestion, not readEncounter. Less PII leaks, cleaner responses.
Public docs
Start with the platform. Then use the SDK.
Polaris FHIR should answer two technical questions immediately: how the platform is installed, how the SDK is used once the platform exists, and how agent access is meant to work. FHIR-specific links still go straight to fhir.cognovis.de.
platform install
Install Polaris as a platform, not as a bag of packages.
Aidbox, deployment modes, identity, install-data, and rollout guidance now live in a dedicated platform hub.
- Single-tenant, multi-org platform model
- Read-only and bidirectional deployment modes
- Identity and access control at the platform layer
sdk
Use the Polaris FHIR SDK from one coherent surface.
The SDK hub separates the current public package surface from the broader SDK work that is still landing.
- Today the package surface is @polaris/fhir-de.
- Canonical constants should be imported, never hard-coded.
- Broader Polaris SDK surfaces are marked in work where needed.
agents
Document agents and LLM access from the ADRs onward.
The agent hub now explains the MCP agent surface and the LLM gateway direction, while stating clearly what is accepted and what is not shipped yet.
- Inbound MCP surface from ADR-012
- Outbound LLM gateway from ADR-020
- Anonymization, auth, and audit model explained publicly
Canonical stability
Canonical URLs stay stable even when the presentation layer grows better docs around them.
Stable canonicals
Canonical URLs identify the guide artifacts themselves. Public landing pages and docs can evolve without redefining those identifiers.
Registry consistency
Package distribution remains centralized through npm.cognovis.de for predictable installation and version pinning.
No duplicate guide body
This site should orient, summarize, and link outward. It should not fork the canonical guide content into a second uncontrolled IG tree.
Technical contact
Need deployment guidance, SDK help, or a deeper platform conversation around Polaris?
Reach out for public guide questions, platform install reviews, adapter rollout support, or SDK-level integration discussions.