Jengu Insurance

Why this matters

A typical European hospital deals with one national insurer (the state fund — Tervisekassa, GKV, Assurance Maladie) plus a long tail of private supplemental insurers, occupational insurers, travel insurers for international patients, and contracted corporate plans. Without a registry, each integration is bespoke; the lab or clinic maintains a private mental model of which insurers it works with, and the IT team rebuilds it every time something changes.

A registry makes the set explicit and auditable. The tenant lists the insurers it accepts; each entry declares enough metadata for downstream features (coverage lookup, claims submission, pre-authorization) to behave correctly. New insurers are added as configuration; retired insurers are deprecated cleanly.

What customers and operators experience

• A hospital admin onboarding lists the insurers the organization accepts in the configuration repo. Each entry includes the insurer's identity, the connector to use, and the zone-specific claim format.

• A clinician registering a patient picks the patient's insurance from a curated list; entries no longer accepted by the tenant don't appear.

• A financial team sees per-insurer activity in one place — claim volume, payment cadence, rejection rate.

• A central administrator managing a multi-organization tenant configures different insurer sets per organization (each lab department may work with different private insurers even when the national insurer is the same).

How the module would deliver this

• FHIR InsurancePlan and Organization resources. Each insurer is an Organization; each plan it offers is an InsurancePlan with coverage types, period, network references.

• Configured in the tenant's git config repo. Adding, modifying, or retiring an insurer is a reviewed change in the customer's repository; history is the audit trail.

• Per-(module, organization) scope. Insurance plan bindings follow the platform's organizational-structure model: different organizations within a tenant can accept different insurer sets.

• Connector reference per plan. Each plan declares which connector (national insurance bridge, FHIR-Coverage REST, per-insurer adapter) handles its traffic. The registry is metadata; the connectors do the protocol work.

• Per-zone defaults. The compliance zone provides baseline national insurance plans (Tervisekassa for zone-ee, GKV funds for zone-de when delivered); tenants extend with private insurers.

Limits and trade-offs

• Connector availability is finite. Standard-protocol insurers (FHIR Coverage, common HL7 v2 flavours) work via shared connectors; insurers with bespoke APIs need adapters written. The registry models this as configuration; it does not eliminate the engineering for novel APIs.

• Plan metadata accuracy is the customer's responsibility. An entry mis-classifying a plan's coverage type produces wrong downstream behaviour. The platform errs on the side of explicit configuration over inference.

• Zone-shared baselines are starting points. Each zone's baseline national-insurer entry covers the common case; tenant-specific contractual differences need overrides.

Related capabilities

• National insurance integration — the registry references; the connectors implement.

• Patient coverage lookup — uses the registry to know which connector to ask.

• Claims submission — uses the registry to know where to submit each claim.

• Platform: Declarative tenant configuration — the registry lives in the tenant's git config repo as FHIR resources.

• Platform: Organizational structure — registry bindings scope per organization within the tenant.

• Platform: Compliance zones — per-zone baseline national insurance plans.

Why this matters

A clinical service delivered to an unverified patient is a financial liability waiting to surface. National insurance verification in most EU countries is a real-time API call; failing to make it produces unpaid bills, surprise patient charges, and billing-team rework that's entirely preventable.

More importantly, surfacing coverage at the moment of decision lets the clinician choose well. A specialist referral that requires pre-authorization is better caught at order time than at delivery time. A medication outside the patient's formulary is better identified before prescribing than after dispensing. Patient-facing clarity ("you'll pay €N for this") reduces complaints and improves trust.

What customers and operators experience

• A clinician registering a patient sees the patient's coverage immediately: which insurer is primary, which is supplemental, what plan, what's the active period, what's the in-network status with the current organization.

• A clinician ordering a service sees coverage status next to the order: "covered, no copay", "covered with €15 copay", "requires pre-authorization", "not covered for this plan".

• A patient asking "what will I pay?" gets a precise answer at registration, not a surprise at billing.

• A financial team sees patients with stale or unverified coverage flagged for follow-up before clinical service proceeds.

• A billing flow downstream has confidence that services it receives have been pre-validated for coverage; rejection rates fall.

How the module would deliver this

• Real-time API call to the insurer's eligibility endpoint. Each connector handles its insurer's protocol — the platform models the result as a FHIR Coverage resource attached to the patient.

• Cached with refresh policy. Coverage data has an explicit freshness window per insurer; stale data triggers re-verification before billable service. Offline operation degrades gracefully to last-known coverage with a clear indicator.

• Service-aware lookups. When a clinician orders a specific service, the lookup is service-scoped: not just "is the patient covered" but "is this service covered for this patient on this date".

• Multi-payer aware. When a patient has several insurers, lookup returns the full stack with priority order — see multi-payer coordination.

• Patient-context modifiers. Pregnancy, paediatric, occupational coverage flags affect the answer; the platform reads patient context already on the record.

Limits and trade-offs

• Insurer API availability bounds the result. An insurer's eligibility endpoint that is slow or down forces the platform to fall back to cached coverage with an explicit indicator. Real-time verification is best-effort, not guaranteed.

• Coverage data accuracy depends on the insurer. Some insurers return coverage details with high precision; others return only "covered yes/no" and require manual lookup for copay rules. The platform exposes whatever it gets.

• Cross-border coverage is harder. A patient covered by an insurer in another EU country may have EHIC entitlements; cross-border verification works for participating systems and is best-effort otherwise.

• Privacy of coverage queries. Each query is an audit event; patterns that look like fishing for coverage info (queries without a clinical reason) are surfaced for review.

Related capabilities

• Insurance plan registry — tells the lookup which connector to use.

• National insurance integration — the connector that handles state-insurance lookups.

• Coverage rules engine — applies coverage details (copay, in-network) to specific orders.

• Multi-payer coordination — when several insurers are involved, returns the full stack.

• Platform: Patient data anonymisation — coverage queries on anonymised patient data are not meaningful; lookup is always on identifying data inside the tenant boundary.

• Platform: Regulatory audit trail — every lookup is audited.

Why this matters

In most European countries the national insurance system covers the majority of the population. Estonia's Tervisekassa covers nearly all residents; Germany's statutory health insurance (GKV) covers ~88% of the population; France's Assurance Maladie covers universally. A platform that does not integrate well with the relevant national insurer is operationally non-viable in that country — every patient interaction would require manual coverage verification, paper claims, fax communication.

Each national system uses its own protocol, its own identifiers (Estonian isikukood, German Krankenversichertennummer, French NIR), its own data formats, its own integration prerequisites (certificates, secure gateways, professional smart cards). A platform that builds one connector per country, behind a uniform interface, makes country expansion a configuration question.

What customers and operators experience

• An Estonian hospital integrates with Tervisekassa through the platform's zone-ee national-insurance connector — coverage lookups, prescription submission, claims all flow through X-Road as expected by Tervisekassa.

• A German hospital (when zone-de delivers) integrates with GKV through the TI Connector / KIM channels per the zone-de national-insurance connector. SMC-B and HBA card integration handled at the edge.

• A French clinic (zone-fr, future) integrates with Assurance Maladie through DESC and Carte Vitale workflows per zone-fr's connector.

• A clinician sees consistent UX regardless of which national insurer is involved — the connector hides the protocol differences.

• A multi-country operator maintains one platform serving several jurisdictions; each tenant's zone determines which national connector applies.

How the module would deliver this

• One connector per zone. Each zone module ships a national-insurance connector implementing the platform's uniform NationalInsuranceConnector interface in terms of the local protocol.

• Identifiers handled per zone. Estonian isikukood, German Krankenversichertennummer, French NIR — each zone knows its national identifier format and validation rules. Patient registration uses the zone-aware identifier model.

• Authentication via zone-specific credentials. X-Road certificates for Estonia, TI Connector + SMC-B for Germany, DESC certificates for France — all handled by the zone connector; tenants configure the credentials once.

• Edge or cloud per zone. Some national systems require on-premise smart cards (TI Connector with SMC-B/HBA in Germany); those parts run at the edge. Others are pure API calls and run in cloud. The connector decides.

• Inheritance through the zone chain. Tenants in zone-ee inherit zone-eu's GDPR baseline plus zone-ee's national connector. The tenant doesn't configure the chain; the platform resolves it.

Limits and trade-offs

• Each new country requires a connector. This is not a one-shot integration project. Each zone with its own national insurance body requires a connector built and maintained per that body's protocol. The framework is generic; the connectors are not.

• National protocols change. Tervisekassa updates X-Road service definitions; gematik changes TI; ANS revises French protocols. Maintenance is ongoing per zone.

• Some operations are inherently in-country. Smart-card authentication (German HBA, French Carte Vitale) cannot happen across borders; cross-border patients fall back to EHIC where applicable.

• Connector quality bounds capability. A new-zone connector that supports only basic eligibility but not pre-auth limits the module's behaviour in that zone. Capability matrices document what each connector covers.

Related capabilities

• Insurance plan registry — references the national connector for state-insurance plans.

• Patient coverage lookup — uses the connector for real-time verification.

• Claims submission — submits via the connector to the national insurer.

• Electronic insurance card — works alongside the connector at the edge for card-based systems.

• Platform: Compliance zones — the zone chain provides the national connector; the rule "external integrations live in cloud" applies to off-premise insurer endpoints; some on-premise components (TI Connector, smart-card readers) run at the edge.

Why this matters

Most EU countries with state insurance issue an electronic insurance card to every covered resident. The card carries the patient's national identifier and (in some countries) coverage details, plan validity, and entitlements. Reading the card at registration is faster than typing, less error-prone, and captures the authoritative source.

A platform that ignores cards forces clinicians or registration clerks to type identifiers from the card manually — a step that is slow, error-prone, and adds zero clinical value. Card integration replaces a typing task with a reading task.

What customers and operators experience

• A patient at registration presents their national insurance card (Estonian ID-card, German eGK, French Carte Vitale). The clerk taps it to a reader; coverage data populates automatically.

• A clinician seeing the patient sees coverage already verified by the card-reading flow — no follow-up coverage lookup needed (the card itself is the proof for in-card data).

• A patient with an expired card sees a clear indication; registration flags the issue; the patient is asked to renew before service if applicable.

• A patient without a card (e.g., a tourist with EHIC, a non-resident) is handled by the country-specific fallback — EHIC for cross-border EU patients, manual identifier entry otherwise.

• An emergency department can register a patient quickly with a card while clinical care begins; coverage details catch up with the patient through registration.

How the module would deliver this

• Card readers connected to the edge. Insurance cards are physical hardware on the hospital's premises; readers connect to the edge via USB / serial / NFC. The edge is the point of contact, consistent with the platform's on-premise integration rule.

• Per-zone card formats. Estonian ID-card uses standard PKCS#11; German eGK uses TI Connector + KVK applet; French Carte Vitale uses APCV / GALSS. Each zone connector knows its card format.

• Card data triggers coverage record. Card read produces a FHIR Coverage resource directly (where the card carries enough data) or triggers a national-insurance lookup (where the card is just identification).

• Integration with national insurance. Card data flows into the same Coverage model the lookup capability uses; downstream features don't distinguish card-sourced from API-sourced coverage.

• Audited card reads. Each card read is an audit event recording who read which patient's card when. Card reads outside the registration flow are flagged.

Limits and trade-offs

• Cards require physical hardware. Hospitals without card readers fall back to manual entry. The platform supports both; the value of cards depends on hardware presence.

• Card data quality varies by country. German eGK carries less coverage detail than the API it represents; Estonian ID-card identifies the patient but coverage details come from a Tervisekassa lookup; French Carte Vitale carries broader data. Each zone documents what its card actually delivers.

• Some countries are moving away from physical cards. Mobile insurance apps (Estonian smart-ID, German eGK-app) are emerging; these need their own integration pattern (which would be a separate capability).

• Cross-border cards (EHIC) are limited. EHIC is a paper-equivalent card; it doesn't carry the fine-grained coverage detail of a domestic card.

Related capabilities

• National insurance integration — cards feed the same Coverage model the API lookup produces.

• Patient coverage lookup — card-source data participates in the same lookup flow.

• Insurance plan registry — card-issued plans appear in the registry as system-managed entries.

• Platform: Hybrid edge–cloud operation — card readers are on-premise integrations through the edge.

• Platform: Edge fleet management — card readers are edge-attached devices.

Why this matters

Many insurers require pre-authorization for non-routine services. A clinician orders an MRI; the insurer must approve before the appointment is scheduled. A specialist referral for a chronic condition needs a coverage commitment before it counts as in-network. A high-cost medication needs the insurer's nod before the pharmacy dispenses.

Without a managed workflow, this is paper forms and phone calls. A request goes out, sometimes by fax; a response comes back sometimes by email; it gets attached to the patient's record by the clinic's coordinator if they remember; the audit trail lives in someone's email folder. Delays in approval become delays in care; lost approvals become repeat requests; rejected requests become expensive surprise bills.

A managed pre-auth workflow turns this into an auditable, tracked process. The clinician sees pre-auth requirements at order time, submits with one click, sees status, and proceeds when approved.

What customers and operators experience

• A clinician ordering a service that requires pre-auth sees a clear indicator: "This service requires pre-authorization from [insurer]". One click submits the request with the order's clinical context.

• A coordinator managing pending requests sees a worklist of submitted, in-review, and approved/rejected requests. Each item shows time-since-submission and any insurer feedback.

• A clinician waiting for approval can check status in the order itself; doesn't need to call the insurer or hunt for emails.

• A patient asking "is this covered?" gets a definitive answer once approval comes back; before that, they get "submitted for approval, expected by [date]".

• A rejected request triggers a documented appeal flow with the supporting clinical evidence the clinician provides.

• A regulator reviewing utilization patterns sees the full pre-auth audit trail — submissions, responses, appeals, outcomes — for every request.

How the module would deliver this

• FHIR ServiceRequest carries the pre-auth. The order resource gains a pre-authorization extension; the workflow lifecycle attaches to the same resource.

• Per-insurer pre-auth rules. Which services require pre-auth from which insurer is configured per insurer (in the registry) — driven by the connector's declarations or the tenant's manual rules.

• Submission via the insurer's connector. The national-insurance connector or per-insurer adapter handles protocol — FHIR, HL7, web-form scraping for legacy insurers.

• Status polling or webhook. Where the insurer supports webhooks, status updates push; otherwise the module polls. Status changes are audit events.

• Decision attached to the order. Approval, rejection, conditions all attach as FHIR resources to the original order; downstream billing references the approval.

• Manual fallback for non-API insurers. Where an insurer doesn't support API submission, the workflow surfaces a generated form and tracks the manual response; it's still a tracked workflow even when submission is offline.

Limits and trade-offs

• Insurer response time isn't ours to control. The platform tracks; it cannot make the insurer respond faster. Some insurers are real-time; others take days.

• Pre-auth rules vary widely. What requires pre-auth depends on plan, on diagnosis, on prior authorizations on file, on jurisdiction. The configuration is expressive but not exhaustive; edge cases need human judgment.

• Manual-fallback workflows are real but slower. Insurers without API support are tracked but not automated; the clinic's coordinator still does the out-of-band work.

• Cross-border pre-auth is rare and complex. Patients covered by an insurer in another EU country usually use EHIC for emergency care only; planned care across borders involves S2 forms and is largely out-of-platform.

Related capabilities

• Coverage rules engine — determines whether pre-auth is needed for a given (service, plan) pair.

• Patient coverage lookup — surfaces pre-auth requirement at order time.

• Claims submission — claims reference the approved pre-auth.

• Platform: Cross-module clinical workflow — pre-auth status flows back to whichever module ordered the service (Lab, Visits).

• Platform: Regulatory audit trail — every submission, response, appeal is an audit event.

Why this matters

Coverage isn't a yes/no boolean. A blood test may be covered with no copay, a specialist visit may be covered after meeting a referral requirement, an MRI may be covered with a 20% copay, a brand-name medication may be replaced with a generic equivalent that is the only covered option. Surfacing these rules at order time is what turns coverage from a billing surprise into a clinical-decision input.

A platform that defers coverage rules to billing time produces two failure modes. Patients receive surprise bills because they were told a service was "covered" without knowing about the copay or formulary substitution. Clinicians inadvertently cause out-of-pocket costs they didn't intend by ordering off-formulary. Both undermine trust.

A rules engine that applies coverage rules at the moment of ordering closes the gap. The clinician sees what the patient will pay, what's required (referral, pre-auth), and what alternatives exist.

What customers and operators experience

• A clinician ordering a service sees coverage status inline: "covered, no copay" / "covered, €15 copay" / "requires referral from primary care" / "not covered for this plan, alternative: [generic equivalent]".

• A clinician prescribing sees formulary information: whether the medication is on the patient's plan formulary, what equivalents are, whether a non-formulary exception needs to be requested.

• A patient asking "what will I pay?" gets a precise answer pre-service.

• A financial team auditing can see the coverage rule applied to each claim — when a service was billed with a copay, the rule that produced that copay is traceable.

• A clinician treating a patient with frequency limits (e.g., this insurer covers MRI once per 12 months) sees whether the limit applies before ordering.

How the module would deliver this

• Rules expressed per-plan. Each insurer's plan in the registry carries its rule set: covered services, copay schedules, network rules, formularies, frequency limits.

• Evaluated at order time. When a clinician orders a service for a patient, the engine evaluates: is this covered? what copay? is referral required? is pre-auth needed? is there a frequency limit?

• Result is a structured decision. The engine returns coverage status with structured reasons; the order UI surfaces these as inline annotations, not buried.

• Per-zone rule packs. Common rules for each jurisdiction (Estonian Tervisekassa baseline, German GKV-Modellverträge structure) come as zone-shared rule packs; tenants override per their contracts.

• Patient-context-aware. Rules consider patient age, diagnosis, prior authorizations, prior orders. The same service for two patients on the same plan can produce different coverage decisions.

• Auditable. Every coverage decision is recorded with the rule that produced it, ready for review if the resulting claim is questioned.

Limits and trade-offs

• Rule expressiveness is finite. Some plans have rules too complex for any rule engine to fully model (multi-condition pre-existing-condition exclusions, jurisdictional appeals processes). The engine handles the common 90%; complex cases escalate to manual review.

• Rule maintenance is real work. Plans change rules; jurisdictional rules change. Per-plan rule packs need curation; the platform supports versioning and review, but it does not automatically discover new rules.

• Network-status accuracy depends on freshness. Whether a clinician is in-network for a plan changes; the engine consumes whatever the registry knows. Stale network data produces wrong decisions.

• The engine is not legal advice. A coverage decision surfaced by the engine is the platform's best evaluation; for high-value decisions, written insurer confirmation remains the safer source of truth.

Related capabilities

• Patient coverage lookup — provides the patient's plan(s) the engine evaluates against.

• Pre-authorization workflow — engine flags pre-auth requirements; workflow handles submission.

• Claims submission — the rule that produced the coverage decision feeds into the claim.

• Multi-payer coordination — when several plans cover the patient, the engine evaluates each in priority order.

• Platform: Compliance zones — zone-shared rule packs per jurisdiction.

• Platform: Cross-module clinical workflow — coverage decisions reach whichever module is ordering.

Why this matters

Claims are how the lab and clinic actually get paid. A platform that captures clinical activity beautifully but produces a manual claims process loses operational value where it matters most. EU healthcare payment is heavily insurer-mediated; a clinic working without automated claims would spend hours per day on administrative work that can be configuration.

Claim formats are also heavily standardized — within a jurisdiction. Estonia uses Tervisekassa-defined claim structures, Germany uses multiple formats depending on which fund (GKV-funds, BG, PKV), France uses NOEMIE / SESAM-Vitale flows, Spain uses regional formats. A single global claim format does not exist; per-zone integration is required.

Auto-claim-submission is the operational counterpart of the clinical workflow: services ordered → services delivered → claims generated → claims submitted → payment received. Each step audited.

What customers and operators experience

• A clinician finishing a service does nothing for billing — the service event is captured automatically, and a claim is drafted from it.

• A financial team reviewing claims sees a worklist of drafted, submitted, in-process, and resolved claims. Most are auto-submitted after the configured review period; exceptions surface for manual handling.

• A claim rejected by the insurer triggers a defined workflow: review the rejection reason, attach corrected information or appeal documentation, resubmit. Each resubmission is a versioned event on the same claim.

• A clinician asking "did the patient's insurance cover the lab I ordered?" sees a status: claim submitted, claim paid, claim rejected (with reason). The link from order to payment is intact.

• A patient asking "did my insurance pay?" gets a precise answer; their portal shows which services were covered and which generated patient liability.

• A regulator or auditor reviewing the practice's claims activity sees one trail: claims submitted, paid, rejected, appealed. Accreditation review becomes routine.

How the module would deliver this

• FHIR Claim and ClaimResponse resources. Each claim is modelled as a FHIR resource referencing the encounter, patient, services, payer. Responses come back as ClaimResponse.

• Per-zone formatter. The zone connector translates the FHIR claim into the jurisdiction's expected wire format — Tervisekassa's expected XML, German GDV / KIM-secured submissions when delivered, French NOEMIE / SESAM-Vitale, etc.

• Lifecycle tracked end-to-end. Drafted → reviewed → submitted → acknowledged → in-process → paid / rejected / appealed. Each transition is an audit event.

• Cross-module sourcing. Claims draw from clinical activity in any enabled module (Lab, Visits) — the platform's cross-module workflow makes the source uniform.

• Tariff-aware via Billing. The claim's monetary lines use tariffs from the Billing module's pricing engine; Insurance and Billing collaborate (Insurance handles the insurer-facing format, Billing handles the pricing).

• Manual fallback for non-API insurers. For insurers that don't accept electronic claims, the module generates the printable claim form and tracks the manual submission status.

Limits and trade-offs

• Per-zone formats need maintenance. Each jurisdiction evolves its claim format; the platform's zone connectors evolve with them. New zones require connector development.

• Rejection reasons need handling logic. Insurers reject claims for many reasons — missing data, coding errors, eligibility issues, pre-auth missing. Some rejections can be auto-corrected; others need human review. The workflow models both.

• Coordination of benefits is involved. When multiple payers are on a claim, the order matters; failed primary submissions cascade to the secondary. Multi-payer coordination handles this.

• Some insurers settle slowly. The platform tracks; it cannot make payment faster.

• Claim privacy is auditable. Each claim's submission, response, payment is audited; access to claims history is itself audited.

Related capabilities

• Coverage rules engine — decisions made at order time inform the claim.

• Pre-authorization workflow — claims reference the pre-auth approval where one was required.

• Multi-payer coordination — orchestrates primary-then-secondary submission.

• National insurance integration — submits to state insurers via the connector.

• Billing: Service event capture — the source events for claims live in Billing; Insurance handles the insurer-facing translation.

• Platform: Compliance zones — claim format per zone.

• Platform: Regulatory audit trail — every claim transition is audited.

Why this matters

Many EU patients carry more than one insurance. A German employee has GKV (statutory) plus may have private supplemental coverage for amenities the statutory plan doesn't cover. An Estonian patient has Tervisekassa plus may have employer-provided supplemental insurance. A French patient has Assurance Maladie plus the near-universal mutuelle complémentaire. Cross-border patients may have EHIC plus their domestic plan.

Without coordination logic, the platform either ignores the multi-payer reality (causing under-billing or over-billing) or forces the financial team to coordinate manually (which is slow and error-prone). Coordination of benefits is a real semantic problem with established conventions; the platform has to implement them.

The strategic value: bills get paid right the first time, patients aren't asked for amounts that should have been covered, and the financial team focuses on exceptions instead of routine multi-payer orchestration.

What customers and operators experience

• A patient at registration with multiple insurances has all of them captured (national + supplemental). The primary-secondary order is determined by jurisdictional rules (national usually primary in EU systems).

• A clinician ordering services sees the coverage from the full payer stack — what the primary covers, what the secondary fills in, the patient's residual liability.

• A financial team submitting claims does not orchestrate primary-then-secondary manually; the platform handles sequence and deferred submission.

• A patient asking "between my two insurances, what do I pay?" gets a clear breakdown: primary covers €X, secondary covers €Y, you pay €Z.

• A regulator reviewing claim coordination sees the full chain: primary submission, primary response, secondary submission with primary's response attached, secondary response.

How the module would deliver this

• Patient Coverage stack with priority order. Each patient carries multiple Coverage resources; the order is set by jurisdictional defaults (national insurance primary in EU patterns) and tenant configuration where needed.

• Claim orchestration. Submitting a claim for a service to the primary first; on response, submitting to the secondary with the primary's response attached (ClaimResponse referenced by the secondary Claim).

• Per-jurisdiction coordination rules. Estonian rules for Tervisekassa + supplemental, German GKV + PKV / GKV + supplemental rules, French Sécu + mutuelle. Each zone provides its coordination logic.

• Cross-border via EHIC. Where a patient uses EHIC, the EHIC-issued domestic insurer is treated as primary for emergency care; planned care across borders is out-of-scope (S2 forms, manual coordination).

• Patient liability calculation. After primary + secondary apply, the residual liability calculation is what the patient gets billed for via Billing's patient self-pay capability.

Limits and trade-offs

• Coordination-of-benefits rules are jurisdiction- specific and subtle. The platform models the common cases; complex cases (e.g., coordination across jurisdictions, between national and private with different deductibles, occupational vs general) may need configured overrides per tenant.

• Multi-payer slows the claim cycle. Secondary submission waits on primary's response; if the primary is slow, the secondary is delayed too. The platform tracks; it cannot make insurers respond faster.

• Mismatched coverage data is hard to detect. If a patient's supplemental insurance has a different coverage scope than the primary, the gap appears as patient liability — sometimes legitimately, sometimes because the secondary's coverage data is out of date.

• EHIC coordination is limited to emergency care. Planned care under EHIC is essentially nonexistent outside S2 forms.

Related capabilities

• Patient coverage lookup — provides the multi-payer stack for the patient.

• Claims submission — handles the per-payer wire format; coordination handles the order.

• Coverage rules engine — evaluates each plan's contribution to a service.

• National insurance integration — handles the primary-payer-side submission for state insurance.

• Billing: Patient self-pay — handles the residual liability after coordination.

• Platform: Compliance zones — jurisdictional coordination rules per zone.