Hypothetical Module

Jengu Billing

How clinical-to-financial flow — service capture, tariff application, invoicing, accounting integration, payment reconciliation — would be expressed as a Jengu module. The Billing module pairs with Insurance to form the revenue cycle.

Hypothetical Module

Jengu Billing capabilities

What the Billing module would deliver, expressed at a level intended for clinical leadership, finance, and procurement reviewers — not engineers. Each capability leads with the business value, then the regulatory or operational driver, then a sketch of how the module would deliver it.

Service Event Capture

Every billable clinical event — a lab test finalised, a visit closed, a procedure performed, a medication dispensed — becomes a tracked billable item the moment it happens. The clinical record drives the financial record automatically; there is no separate billing data-entry step.

Why this matters

A bill is only as accurate as the events it captures. In a typical hospital, services are delivered clinically and then re-entered into the billing system later — sometimes by the clinician at end-of-day, sometimes by a billing team transcribing from notes, often partially missed. Every transcription is a place data deteriorates: services not billed, services billed twice, services billed with the wrong code or wrong patient, services billed for the wrong organization.

Capturing events at the moment they happen — driven by the same FHIR resources the clinical workflow already produces — fixes this. A lab order that finalises with a result automatically produces a billable item. A visit that closes with a signed note produces an encounter-level charge. A procedure documented clinically is the source for the procedure charge.

The strategic value: the billing data captures what actually happened, every time, with no separate transcription step.

What customers and operators experience

A clinician finishing a service does nothing for billing — the event is captured automatically. The clinical workflow is the source of the billing data.
A financial team reviewing bills sees a queue of captured events ready for tariff application and invoicing, not a stack of unentered services to chase.
A laboratory director sees a real-time count of billable tests delivered today / this week / this month matched against orders received; gaps are visible.
A clinic manager sees encounters closed today billed the same day, not weeks later.
A regulator or auditor sees a clean trail from clinical record to billable item to invoice; transcription errors that obscure this trail simply don't exist.

How the module would deliver this

Listen for FHIR resource events. A ServiceRequest fulfilment, an Encounter end, a Procedure finalisation, a MedicationDispense event — each is a signal the module subscribes to.
Convert to FHIR ChargeItem. Each captured event becomes a ChargeItem resource referencing the clinical resource it came from. The link is structural (FHIR reference), not a copy.
Per-(module, organization) capture rules. Different modules emit different event shapes; the capture rules per module declare what counts as billable. Per organization, the rules can vary (e.g., outpatient vs inpatient billing differences).
Cross-module sourcing. Lab events, Visit events, future-module events all converge into the same ChargeItem queue; the module is one consumer of the cross-module clinical workflow.
Idempotent capture. Each clinical event produces at most one ChargeItem; replaying events does not produce duplicates. The link to the source resource is the dedup key.
Adjustments after capture are tracked. A service later cancelled, refunded, or re-coded produces an audit-tracked adjustment to the original ChargeItem, not a hidden re-write.

Limits and trade-offs

Capture quality bounds billing quality. Events the clinical workflow doesn't emit aren't captured; events emitted incorrectly are captured incorrectly. The platform errs toward explicit-source-of-truth; the clinical record drives.
Some billable events have no clinical equivalent. Service charges that aren't tied to a specific clinical event (e.g., a flat per-encounter administration fee) need configured rules; not everything billable is emitted by clinical activity.
Cancellations and re-codes are common in clinical reality. The platform tracks; it does not pretend every captured event is final.
Out-of-platform events still require manual entry. Services delivered through systems outside the platform (hand-off to an external imaging service, for example) need manual ChargeItem creation if they're to be billed by the platform.

Related capabilities

Tariff and pricing engine — captured events get prices applied here.
Invoice generation — priced events become invoices.
Accounting system connector — captured events flow to the accounting system.
Insurance: Claims submission — captured events, priced, become the source for claims.
Platform: Cross-module clinical workflow — modules' clinical events drive billing through this capability.
Platform: Regulatory audit trail — every captured event, every adjustment, every reversal is audited.

Tariff and Pricing Engine

Per-service pricing across multiple price lists: national tariff, insurer-negotiated rates, private cash rates, contracted discounts. The engine looks up the right price for the right (service, payer, contract, time) tuple — not one number per service.

Why this matters

A single "price" for a service is fiction. The same lab test has one price under the national tariff, a different price for a private insurer with a negotiated contract, another price for a self-pay patient, possibly a contracted price under a corporate agreement. A platform that uses one number is wrong most of the time; one that doesn't track which price applied to which event can't reconcile when the wrong price appears on a bill.

Tariffs also evolve. National tariff lists update annually (or more often); insurer contracts have effective dates; new services get added; services get retired. A pricing engine that doesn't version prices loses the ability to bill historical services correctly.

The strategic value: bills carry the right price, every time, traceable to the source price list and the version that applied. Reconciliation against insurer or accounting records becomes possible because the platform knows which price went where.

What customers and operators experience

A financial team configuring contracts sets up per-insurer price lists in the configuration repo; new contracts go through the same review workflow as everything else.
A clinician ordering a service sees the patient-relevant price (after coverage rules apply) at order time — see the Insurance module's coverage rules engine.
A patient receiving a self-pay invoice sees a price that matches the published cash price for that service.
A claim submitted to an insurer carries the negotiated contract price for that insurer; rejections for wrong pricing become rare.
A financial team auditing can see, per ChargeItem, which price list applied, which version, what the resulting amount was, why.

How the module would deliver this

FHIR ChargeItemDefinition per (service, payer, plan). Each price is a ChargeItemDefinition referencing the service code (LOINC, national procedure codes, internal catalogue) and the payer/plan it applies to.
Effective dating. Each definition carries an effective period; pricing at billing time uses the version active on the service date.
Lookup by (service, payer, date). The engine resolves the correct price by service, by payer (with multi-payer handled by the Insurance module's coordination), by service date.
Per-zone baselines from national tariffs. The national-tariff integration capability provides the zone's baseline; tenant-specific contracts overlay.
Per-(module, organization) overrides. A specific organization within a tenant can override prices when it has its own contracts (e.g., a satellite clinic with different corporate agreements).
Versioned, reviewable, auditable. Every price change is a git change; every applied price is recorded in the ChargeItem audit.

Limits and trade-offs

Contract complexity is finite. Bundled pricing, volume discounts, conditional rebates exist in the insurer-contract world; the engine models common patterns. Highly bespoke contracts may need manual application.
Price-list maintenance is real work. Effective dates, retirements, new services — the configuration needs upkeep; without it, prices go stale.
Tariff changes mid-period need careful handling. When a national tariff revises mid-month, the platform bills the version active on each service date; the revenue impact is felt across that boundary.
Cross-zone pricing is per-zone. A service delivered to a zone-ee tenant uses zone-ee pricing; cross-zone patients (rare) need explicit contract handling.

Related capabilities

Service event capture — events arrive priced; the engine applies the price.
National tariff integration — provides the zone's baseline tariff list.
Invoice generation — priced items become invoice lines.
Insurance: Claims submission — the price the engine applied is what the claim carries.
Insurance: Coverage rules engine — coverage evaluation uses the engine's price.
Platform: Compliance zones — tariff baselines provided by zone.
Platform: Declarative tenant configuration — contracts and price lists live in the git config repo.

National Tariff Integration

Per-zone integration with each country's national health-service tariff list — Estonian Tervisekassa tariffs, German EBM, French NABM, future zones each contributing their own. The national baseline pricing flows automatically when the national authority publishes updates.

Why this matters

National tariff lists are the baseline pricing for state-insurance reimbursement in most EU countries. Estonia's Tervisekassa publishes a tariff list (hinnakiri) per period; Germany has the EBM (Einheitlicher Bewertungsmaßstab) for outpatient and DRG-G for inpatient; France has NABM for lab and CCAM for procedures. These lists change at least annually and each change ripples through every state-insurance claim.

A platform that does not auto-sync these tariffs forces the financial team to manually update prices when each new period begins — a mass-update task that's error-prone and historically the source of period-end billing errors.

Auto-integration with the publishing authority means the platform catches updates as they're published, applies them with the right effective date, and bills accordingly. The financial team reviews the changes once and signs off; the platform takes care of the rest.

What customers and operators experience

A financial team starting a new period sees the new national tariff applied to the right effective date; bills for services delivered after the date use new prices, bills for services delivered before use old.
A laboratory director does not need to manually update test prices when Tervisekassa publishes a new hinnakiri; the integration applies the change.
A new hospital onboarding does not start from scratch on pricing — the zone's national tariff baseline is available immediately.
An auditor reviewing past bills sees the version of the national tariff active at the time of service; historical re-pricing is unambiguous.
A regulator reviewing the practice's billing sees tariffs sourced from the recognised national authority; there is no question of "where did this number come from".

How the module would deliver this

Per-zone tariff connectors. Each zone with a national tariff publication ships a connector that pulls or consumes the published tariff list — Tervisekassa publishes XML through their portal; Germany's KBV publishes EBM updates; ANS publishes French tariffs. Each connector is zone-specific.
Mapped to FHIR ChargeItemDefinition. The pulled tariff list is translated into the platform's pricing model — one ChargeItemDefinition per service, with the national code carried as the canonical identifier and the effective period attached.
Effective-date handling. New tariff versions arrive with their effective dates; the pricing engine uses the version active on each service date.
Tenant override remains possible. A tenant with contracts that override the national tariff for some services keeps those overrides; the national list is the baseline only.
Audit of every sync. Each tariff sync is an audit event: which connector ran, what version was pulled, what services changed price.
Manual fallback. Where a national authority does not publish in machine-consumable form, the connector supports manual file ingestion through a reviewed config-repo change.

Limits and trade-offs

Each new zone requires a connector. Same pattern as national insurance integration — country-specific work per jurisdiction, generic framework on top.
National authorities change publication formats. Connectors need maintenance when the upstream format evolves.
Mid-period changes need clean handling. When a national authority issues a correction or retro-active change, the platform must apply with care — historical bills already paid are not retroactively re-priced unless explicitly reconciled.
Some tariffs are bundled in complex ways. DRG-G in Germany prices encounters as bundles, not per-service; a per-service pricing engine needs special handling for these cases.
Coverage of the national tariff is not 100%. Some services are not in the national tariff (private-only services); those fall to tenant-configured pricing.

Related capabilities

Tariff and pricing engine — uses national tariffs as one input.
Service event capture — captured events get priced from the tariff.
Insurance: National insurance integration — claims to the state insurer use the matching national tariff price.
Insurance: Claims submission — claim amounts reference the tariff.
Platform: Compliance zones — tariff publication is a per-zone capability.
Platform: Declarative tenant configuration — tariff data is consumed by the platform's config repo flow.

Accounting System Connector

Push billable events, invoices, and payments to the customer's existing accounting / ERP system: SAP, Oracle, Microsoft Dynamics, regional ERPs, hospital-specific systems. The hospital's finance team continues to run their books in the system they're certified on; the platform feeds it.

Why this matters

Hospitals do not replace their accounting system because of clinical software. The accounting / ERP system is where finance lives — payroll, accounts payable, accounts receivable, general ledger, statutory reporting, audit. It's certified, it's integrated with the hospital's bank and tax systems, and it's the system finance is comfortable in.

A platform that demands the hospital adopt its own accounting fails procurement: finance teams will not accept a clinical vendor as their system of record for financial transactions. The right answer is the opposite: clinical activity flows out of the platform into the customer's accounting system, in the format that system expects.

This is integration, not replacement. The platform handles clinical-to-financial conversion (service capture, pricing, invoicing) and pushes the result into the customer's general ledger.

What customers and operators experience

A finance team using SAP sees billable events posted as journal entries through SAP's expected interface (IDoc or REST); invoices go where SAP expects invoices.
A finance team using a smaller ERP uses its connector (ERP-vendor REST, flat-file CSV import for legacy systems); the platform supports the systems most hospitals use.
A multi-organization tenant can configure different accounting systems per organization — a satellite clinic using a smaller ERP while the main hospital uses SAP, both in the same tenant.
A finance manager sees data flow into their existing reports (accounts receivable aging, revenue recognition) with no parallel reporting to maintain.
An auditor sees one set of books, not two — the hospital's accounting system is the authoritative financial record.

How the module would deliver this

Per-system connectors. SAP via IDoc (e.g., INVOIC02, FIDCC2) or S/4HANA REST APIs; Oracle via ERP Cloud REST or EBS XML interfaces; Microsoft Dynamics via OData; smaller systems via flat-file or vendor-specific REST.
Per-(module, organization) configuration. Connector selection, credentials, chart-of-accounts mapping, cost centre mapping all configured per binding in the git config repo.
FHIR Invoice and ChargeItem to GL. Platform resources translate to the accounting system's expected shape — chart-of-accounts codes, cost centres, tax codes, document types.
Bidirectional flow. Outbound: platform-generated invoices and event postings push to accounting. Inbound: payments recorded in accounting (from bank reconciliation) flow back as PaymentReconciliation resources that close out the platform's outstanding bills.
Idempotent posting. Each platform event posts at most once; replay protection on both sides.
Audit of every push and pull. Every transmission to or from the accounting system is an audit event.

Limits and trade-offs

Each accounting system needs its own connector. SAP is one connector, Oracle another. The framework is generic; the per-system work is real.
Chart-of-accounts mapping is tenant-specific. Mapping from clinical services to GL accounts depends on how the hospital structures its books; configuration per tenant is required.
Some accounting systems lag in real-time integration. Legacy systems may only accept batched imports; the platform supports both real-time and batch but the real-time benefits depend on the accounting side.
Reconciliation depends on bidirectional accuracy. Payments recorded in accounting that don't flow back promptly leave the platform with stale "outstanding" bills. Operational discipline matters.
Multiple ERP environments multiply effort. A customer on multiple ERPs across organizations is workable but operationally heavier than a single ERP.

Related capabilities

Service event capture — events flow to accounting via this connector.
Invoice generation — invoices flow to accounting.
Payment reconciliation — bidirectional flow with the accounting side.
Revenue cycle visibility — uses both platform-side and accounting-side data for full-cycle reporting.
Platform: Hybrid edge–cloud operation — accounting systems live on-premise (most hospital ERPs) and the connector reaches them through the edge if they're not internet-accessible; cloud-hosted ERPs go through cloud.
Platform: Organizational structure — connector binding is per (module, organization), so different departments can use different accounting systems.

Invoice Generation

Generate invoices for patients, insurers, sponsors, or third parties. Per-zone formatting honours national tax rules, mandatory fields, language requirements, and e-invoicing standards. Invoices are sent through the channels each recipient expects.

Why this matters

Invoicing is heavily regulated by jurisdiction. Estonia mandates e-invoicing in defined formats; Germany has ZUGFeRD and X-Rechnung for B2B / B2G; France mandates electronic invoicing for VAT- registered transactions. National tax law dictates mandatory invoice fields, archival periods (typically 10 years in EU), language, currency, sequential numbering, and immutability.

A platform that uses one global invoice format fails compliance review in every jurisdiction. Worse, an invoice that misses a mandatory field is rejected by tax authorities or by recipient e-invoicing portals — silently, sometimes, leaving the bill unpaid until someone notices.

Per-zone invoice generation honours each jurisdiction's rules automatically, so the financial team configures recipients and delivery channels rather than crafting invoices manually.

What customers and operators experience

A financial team configuring invoice templates picks from per-zone defaults (Estonian e-invoice format, German ZUGFeRD/X-Rechnung, French Factur-X) and overlays hospital-specific branding.
An invoice generated carries the right format for the recipient — patient sees a human-readable PDF, insurer receives a machine-readable structured invoice, government body receives the mandated e-invoice format.
A patient receiving an invoice in their preferred language sees clear charges, due dates, and payment options.
An insurer or sponsor receiving an invoice electronically can ingest it into their system without manual transcription.
A regulator or tax authority sees invoices that conform to the jurisdiction's standards, sequentially numbered, immutable, archived.
An auditor reviewing an old invoice retrieves it exactly as issued — invoice immutability is structural.

How the module would deliver this

FHIR Invoice resource as the canonical source. Each invoice is generated from ChargeItem records, carrying tariff-engine-applied prices. The FHIR resource is the source of truth.
Per-zone formatter. A zone-specific formatter produces the wire format the recipient expects: Estonian e-invoicing XML, German ZUGFeRD/X-Rechnung, French Factur-X. The formatter is part of the zone module.
Sequential, immutable numbering. Invoice numbers are assigned by the tenant's configured numbering scheme (per zone tax requirements); once issued, immutable. Corrections are issued as separate credit/debit notes referencing the original.
Per-recipient delivery channels. Configured per recipient — email PDF for patients, e-invoicing portal upload for B2B, printed mail fallback. Tenant configures default channels; recipient overrides apply.
Multi-currency aware. Where the tenant operates with multiple currencies (rare in EU but possible for international patients), invoices carry the issued currency and any conversion details.
Language follows recipient. Patient invoices use the patient's preferred language (where the translation is supported); B2B invoices use the jurisdiction's default unless the recipient configures otherwise.
Archival per zone retention. Invoices archive for the jurisdiction's mandated period (typically 10 years EU); archival storage is part of the platform's compliance posture.

Limits and trade-offs

Invoice formats evolve. EU member states keep refining e-invoicing requirements; per-zone formatters need maintenance.
Cross-border invoicing is complex. A patient resident in one EU country invoiced by a clinic in another may trigger VAT-cross-border rules; the platform handles common cases but not all bilateral edge cases.
Branded templates are tenant work. The platform provides the data and the legal-format compliance; visual branding (logos, layout) is per-tenant configuration.
E-invoicing portal failures need manual fallback. When a recipient's e-invoicing portal is down or rejects, manual delivery (PDF email) is the fallback; status is tracked.
Historical invoice retrieval is slow for long-archived ones. Invoices archived per the 10-year retention requirement are retrievable but not on the same low-latency path as recent ones.

Related capabilities

Tariff and pricing engine — provides the prices the invoice carries.
Service event capture — the events the invoice bills for.
Patient self-pay — patient invoices flow to the self-pay capability for payment.
Accounting system connector — invoices push to accounting for the financial record of issuance.
Insurance: Claims submission — claims to insurers parallel invoices; some insurers want both, some one.
Platform: Compliance zones — invoice format and archival per zone.
Platform: Open standards data portability — invoices are FHIR Invoice resources, portable.

Patient Self-Pay

Direct billing to patients for services not covered by insurance, for copays remaining after insurance, or for self-pay-only services. Patients see what they owe in their portal, pay online or in person, receive receipts. Friction in patient billing reduces collection rates; the module reduces friction.

Why this matters

Even in EU jurisdictions with comprehensive state insurance, some services are out-of-pocket: cosmetic procedures, certain elective services, copays remaining after insurance, services delivered to patients without coverage (tourists, undocumented). The patient-facing billing experience determines collection rate and patient satisfaction.

A platform that requires patients to call, email, or mail-in payment loses collection. A platform that surfaces a clear "here's what you owe" with a one-click payment option collects faster and frustrates patients less.

The strategic value: patient liability becomes patient revenue sooner, with lower administrative cost.

What customers and operators experience

A patient finishing a self-pay service sees the bill on their phone (or printed at the desk if they prefer). Total, itemised charges, payment options visible.
A patient paying online clicks through to a regional payment processor (Stripe, Adyen, regional alternatives), pays with card or bank transfer, receives a receipt.
A patient paying at the desk has the receptionist take payment via the configured POS terminal; the platform records it, the receipt is the same shape as the online one.
A patient with both insurance and a copay sees the copay portion clearly separated from what insurance covers; only the copay is the patient's bill.
A patient asking for a payment plan can be set up by the financial team with scheduled payments; the platform tracks the plan and sends reminders.
A patient refunded for a cancelled or mis-billed service receives the refund through the same channel they paid on, with audited reversal.

How the module would deliver this

Patient invoices flow to the patient portal. The invoice generated by the invoice-generation capability routes through the patient's preferred channel — portal notification, SMS link, email, paper.
Online payment via configured processor. Tenant configures one or more payment processors per zone; Stripe or Adyen widely supported, regional alternatives configurable. The platform never holds card data — PCI scope stays with the processor.
In-person payment via POS integration. For walk-in payments, POS terminal integration records payment with the same trail as online.
Receipt as FHIR Invoice with payment status. A paid invoice is a PaymentReconciliation linking the invoice to the payment event; the receipt is the same resource viewed from the paid side.
Refund workflow. Refunds reverse the payment and produce a credit note referencing the original invoice; financial team approves; processor refund is audited.
Payment plan support. Tenant-configured ability to break a large bill into scheduled payments; reminders send through the patient's channel.

Limits and trade-offs

Payment processor availability per zone. Stripe is widely available in EU; Adyen ditto; some regions prefer regional alternatives (Estonian banks have their own payment-link standards). Tenant chooses among supported processors.
PCI scope exists somewhere. The platform's scope is reduced because the processor handles card data, but the processor's compliance is real and is the customer's contract.
Refunds depend on processor support. Online refunds for processors that support them are automatic; processors without programmatic refund support need manual handling.
Patient communication preferences vary. Some patients want SMS, some email, some paper. Per-tenant configuration with patient-level overrides handles this; without configuration, defaults apply.
Bad-debt handling is manual. Unpaid bills past due flag for the financial team; collection-agency hand-off is per-tenant policy, not platform-built-in.

Related capabilities

Invoice generation — patient invoices come from here.
Payment reconciliation — payments received reconcile against open invoices.
Accounting system connector — payment events flow to the accounting system.
Revenue cycle visibility — patient AR is part of the cycle metrics.
Insurance: Coverage rules engine — distinguishes insurance liability from patient liability.
Visits: Patient-facing visit summary — bills are surfaced in the patient portal alongside other patient-facing content.

Payment Reconciliation

Match incoming payments — from insurers, patients, sponsors — against outstanding invoices. Routine matches close automatically; mismatches and partial payments surface for review. The financial team works exceptions, not the every-day matching.

Why this matters

Payments rarely line up perfectly with invoices. An insurer pays a batch of claims with one wire transfer; a patient pays the copay in two instalments; a refund arrives net of a fee; a correction is issued for a previous overpayment. Manually matching every payment to invoices is the kind of work that absorbs financial-team time without producing insight.

Auto-reconciliation flips this. Payments that match an open invoice on amount, reference, date, and payer close automatically. Payments that mismatch surface in an exceptions queue with the gap clearly identified. The financial team works the queue; the routine 80% works itself.

The strategic value: lower cost-to-collect, faster cash recognition, fewer surprises in the AR aging report.

What customers and operators experience

A finance team member opening their dashboard sees a small exception queue rather than a long matching backlog. The queue lists the dozen-or-so payments that need judgment.
A typical day's payments close 80–90% automatically without intervention.
A partial payment (patient pays some of an invoice) closes the matched portion; the residual remains open with the partial-payment history visible.
An overpayment (patient or insurer overpaid) flags as a credit balance; financial team chooses refund or apply-to-next.
An insurer batch payment for many claims arrives with a remittance advice (ERA / 835 in some systems, custom in others); the platform parses the advice and matches each line to its claim.
A reconciliation report at month-end shows what's closed, what's outstanding, what's in dispute, what's past-due — all per-organization for the tenant.

How the module would deliver this

Listen for payment events. From the accounting-system connector (where payments first land in the customer's GL) and from the patient self-pay processor (for direct payment events).
Match by reference, amount, date, payer. A payment with an invoice number reference and the right amount closes its invoice. Tolerance rules handle small rounding differences.
Parse remittance advices. Insurer batch payments with structured remittance (ERA / 835 / national-format equivalents) are parsed and matched per line.
Exception queue. Payments that don't match drop into an exception queue with the inferred gap (no matching invoice, amount mismatch, multi-invoice candidate). Financial team resolves manually.
Audit every match and every manual resolution. The audit trail shows who closed which invoice with which payment, when, why.
Per-organization views. Multi-organization tenants see exception queues split by organization where appropriate.

Limits and trade-offs

Match accuracy depends on payment metadata. Payments with rich references (invoice number, claim reference) match easily; payments without metadata fall to the exception queue more often.
Insurer remittance formats vary. ERA / 835 is common but not universal; some insurers produce custom remittance shapes. Per-insurer parsing rules may be needed.
Foreign-currency payments are subject to FX variation. A payment arriving in a different currency than the invoice produces an FX-adjusted match; the residual rounding falls into a configured account.
Late or disputed payments are an exception workflow, not auto-reconciled. Disputes need human attention by definition.
Matching depends on bidirectional accounting flow. If payments don't flow back from accounting promptly, reconciliation is delayed.

Related capabilities

Invoice generation — invoices are what reconciliation closes.
Patient self-pay — patient payments flow through here.
Accounting system connector — payment events arrive from the accounting system.
Revenue cycle visibility — uses reconciliation status for AR aging.
Insurance: Claims submission — claim payments reconcile against the corresponding claims.
Insurance: Multi-payer coordination — multi-payer payments need to be split across the right invoices.
Platform: Regulatory audit trail — every match, every exception resolution is audited.

Revenue Cycle Visibility

Real-time view of the financial pipeline: services delivered → billed → claimed → paid → reconciled. Aging analysis, collection rates, rejection patterns, days-sales-outstanding, per organization within the tenant. The hospital's finance team sees the cycle, not just the end.

Why this matters

A hospital's revenue cycle is where most operational money is won or lost. Slow-moving claims, persistent insurer rejections, aging accounts receivable, services delivered but never billed — all reduce realised revenue. Without visibility, problems hide in month-end reports and only surface as quarterly disappointments.

Visibility makes the cycle a managed process. The director of finance sees, today, that claims to a particular insurer have been rejecting at a higher rate this week and can act on it. The operations director sees that a particular department's services-delivered-vs-billed gap is widening and can investigate. The CFO sees DSO trending up and can address it before it becomes a cash-flow problem.

The strategic value: financial issues become identifiable, and therefore solvable, before they crystalise as bad debt or missed targets.

What customers and operators experience

A CFO or finance director opens a dashboard showing the cycle: services this week, services billed, claims submitted, claims paid, claims rejected, aging buckets, DSO trend.
A revenue cycle manager sees rejection patterns broken down by insurer, by service, by reason; recurring rejections become triage items.
A laboratory director sees the lab's own cycle: services delivered, billable items captured, invoices generated, claims submitted, claims paid. Per-lab visibility.
A clinic manager sees encounter-level cycle metrics: encounters closed today, encounters billed today, the gap between them, why.
A multi-organization tenant's central finance sees per-organization cycle metrics, with the ability to drill in to one department.
An auditor reviewing financial controls sees a full cycle trail per service event: when delivered, when billed, when claimed, when paid, when reconciled.

How the module would deliver this

FHIR-based metrics across the cycle. The platform's FHIR resources (ChargeItem, Invoice, Claim, ClaimResponse, PaymentReconciliation) carry the events; metrics aggregate them.
Per-tenant aggregation only. No cross-tenant metrics — that's a hard platform principle. Within a tenant, per-organization aggregation respects the tenant's permission model.
Configurable views per role. A clinic manager sees their organization's view; a CFO sees the tenant view; a department head sees their department only.
Time-series tracking. Trends in DSO, rejection rate, collection rate are tracked over time so operational decisions have history.
Cross-module cycle. The cycle starts in clinical modules (services from Lab and Visits) and ends in reconciliation; visibility spans the whole flow through the platform's cross-module workflow.
Drill-down to root events. A high rejection rate for a particular insurer drills down to the rejecting claims and ultimately to the source events — whether the issue is coding, eligibility, pre-auth, or something else.

Limits and trade-offs

Aggregation is per-tenant, never cross-tenant. Customers wanting cross-customer benchmarks contribute through the consented-data-use programme, anonymised.
Metrics quality depends on cycle completeness. Some events (services delivered outside the platform, payments outside the accounting system) won't appear in the cycle; per-tenant configuration helps but gaps remain.
Real-time has limits. Most metrics are near-real-time (seconds-to-minutes); some heavy aggregations are batched. The dashboard indicates freshness.
Cross-organization sharing within a tenant respects tenant policy. A department head sees only their department by default; tenant-level sharing rules can extend.
Comparing across zones requires care. A tenant in zone-ee and a tenant in zone-de produce numbers shaped differently by their tariff structures and reimbursement cadences; cross-zone comparison needs context.

Related capabilities

Service event capture — the cycle begins here.
Tariff and pricing engine — pricing influences the per-service portion of the cycle.
Invoice generation — invoice events feed the cycle metrics.
Payment reconciliation — closure of the cycle happens here.
Insurance: Claims submission — claim activity is part of the cycle.
Platform: Tenant data isolation — aggregation respects the tenant boundary.
Platform: Organizational structure — per-organization cycle metrics within a tenant.
Platform: Consented data use — cross-customer benchmarks (where consented) flow through here.