Automated Regression and Confluence Integration Streamline Health Insurance Policy Rule Alignment and Governance

Overview

A health insurance product team struggled to keep policy rules aligned with how the app calculated eligibility, accumulators, and benefits, which led to claims disputes and support escalations. Intelligex stood up a rules governance workflow that bound Confluence specifications to a versioned rules engine repository and added automated regression checks in GitHub Actions. Rule changes moved with traceable approvals, discrepancies between policy intent and runtime behavior dropped, and release coordination with Compliance and Customer Support became predictable—without replacing the team’s rules engine, claims core, or planning tools.

Client Profile

• Industry: Health insurance and benefits administration
• Company size (range): Multi-product portfolio with employer and individual plans
• Stage: Established claims core and rules engine; policy specs documented in Confluence and PDFs
• Department owner: Product Management & R&D
• Other stakeholders: Actuarial, Policy/Compliance, Customer Support, Engineering, QA, DevOps, Provider Network Operations, Legal

The Challenge

Plan rules changed every renewal cycle and through mid-year updates. Product managers documented intent in Confluence, Policy maintained PDFs with legal language, and engineers implemented logic in a rules engine. Minor differences in exclusions, visit limits, or accumulator interactions slipped into production because the path from specification to code lacked guardrails. Customer Support surfaced discrepancies when members or providers challenged determinations, and QA recreated scenarios manually to confirm whether the discrepancy was in the rule or the spec.

Artifacts were scattered. Confluence pages described benefit tiers, exceptions, and effective dates in prose. The rules engine repository contained decision tables and functions that evolved quickly during plan setup. The claims core consumed rule artifacts but did not retain a clear link back to the policy source. Engineers added hotfixes to meet dates, but those changes were not always reconciled with Confluence. During audits or escalations, teams rebuilt context from comments and screenshots instead of pointing to a single, versioned truth.

Teams wanted a lightweight, governable thread from policy to code. The solution needed to keep Confluence for specifications, the existing rules engine for execution (for example, DMN tables or Drools rules), and the current CI setup. It also needed fast automated checks and human approvals that Policy and Product trusted. For a shared structure around decision logic, the team aligned on decision tables and references such as the Decision Model and Notation (DMN) standard, and for CI, on GitHub Actions.

Why It Was Happening

Root causes were fragmented ownership and unstructured specifications. Policy language arrived as narrative text and PDFs; implementation required precise inputs, outputs, and effective dating. Without a canonical template tying plan rules to testable scenarios, engineers translated prose into code inconsistently. Hotfixes landed under time pressure without synchronized updates to Confluence or regression suites, and branch protections were not tied to rule-specific checks. Effective-dated nuances created further drift when prior-year logic remained in place for legacy members.

Definitions diverged across systems. Accumulator names in the claims core differed from labels in Confluence, network exceptions used provider taxonomy not reflected in decision tables, and eligibility edge cases were handled as annotations rather than governed criteria. No single path required that a change to a rule came with updated examples and approvals from Policy and Product.

The Solution

Intelligex implemented an orchestration that connected Confluence specifications to a versioned rules repository and enforced automated checks in CI. Confluence templates captured policy intent in a structured format (inputs, outputs, criteria, examples, and effective dates). A synchronization service published those templates into machine-readable artifacts alongside rule code. Pull requests in the rules repository required linked Confluence pages and triggered regression suites in GitHub Actions. Contract-style tests executed decision tables against example scenarios, validated accumulator and network logic, and checked effective dating. Merges required e-signatures from designated approvers, and releases produced a traceable bill of rules with links back to approved specs.

• Integrations: Confluence for governed specification templates; rules engine repository (for example, DMN decision tables or Drools) as the source for executable logic; CI via GitHub Actions to run linting and regression checks; optional Jira status badges on epics and stories to reflect rule readiness; deployment into the existing claims core.
• Specification templates: Confluence pages with structured fields: inputs, outputs, decision logic notes, examples, exclusions, network/plan variations, effective dates, and deprecation markers. Pages included a unique spec ID used in code and tests.
• Repo synchronization: A service that mirrored approved spec metadata into the rules repo, generated stubs for decision tables, and ensured file names and IDs matched the spec. Changes without linked spec IDs failed checks.
• Automated regression: GitHub Actions jobs that validated syntax, ran decision suites against example scenarios, checked accumulator composition, and verified effective-dated behavior. Failures blocked merges until addressed or explicitly waived with reason codes.
• Approval workflow: Code owners and approvers from Product and Policy reviewed pull requests. E-signatures and reason codes were required for exceptions (for example, a temporary variance for a specific plan).
• Effective dating and release packaging: Support for multiple active versions; release bundles documented which rule versions applied to each plan year and segment, with links to their Confluence specs and approvals.
• Dashboards and traceability: Jira and Confluence views showed rule readiness, failing scenarios, and change history. Release notes included a bill of rules with spec links.
• Security and audit: Branch protections, least-privilege repo access, immutable logs of approvals and CI runs, and evidence packs for audits showing spec, code, tests, and approvals tied together.

Implementation

• Discovery: Mapped plan design, renewal timelines, and mid-year change patterns. Collected representative Confluence pages, policy PDFs, and existing decision tables. Cataloged accumulator types, network variations, and typical dispute drivers from Support.
• Design: Defined the Confluence template schema and spec IDs, crosswalked labels to the claims core and rules engine, and set approval roles. Designed GitHub Actions workflows for linting and regression, and agreed on exception handling and effective-dating conventions.
• Build: Implemented the spec-to-repo synchronization, added code-owner protections, and built regression suites from approved examples. Configured Jira badges and Confluence macros for status. Created release packaging scripts to produce a bill of rules with links.
• Testing/QA: Ran in shadow mode: specs drove test generation while existing processes continued. Compared CI failures to known disputes and tuned templates and tests. Piloted on a subset of plans with a human-in-the-loop review board from Product, Policy, QA, and Engineering.
• Rollout: Enabled by plan family and renewal cycle. Kept the legacy path as a controlled fallback for the first cycles. Expanded coverage as teams saw stable merges and clear evidence in Support reviews.
• Training/hand-off: Delivered short sessions for PMs, Policy, Engineering, and QA on templates, approvals, and CI behavior. Updated SOPs for rule changes, effective-dated updates, and release notes. Transferred ownership of templates, approvals, and regression suites to Product Ops and Policy under change control.

Results

Rule changes moved with traceable intent and tests. Engineers opened a pull request with a linked spec, CI ran decision suites against the examples, and approvers saw exactly what changed and why. Discrepancies between policy language and runtime behavior were caught at merge time rather than by Support. Release notes pointed to the governing spec for each rule, which gave Compliance and Customer Support a shared reference during questions.

Day-to-day work became simpler. Product and Policy wrote to a consistent template in Confluence; Engineering focused on decision logic rather than reconstructing requirements; QA used the same examples to expand regression coverage. When a plan-year update required multiple active versions, effective dating and release packaging kept the right rule in the right plan without manual swaps. Escalations decreased because determinations aligned with approved rules, and exceptions carried clear rationale and expiry.

What Changed for the Team

• Before: Policy intent lived in prose and PDFs. After: Confluence templates captured inputs, outputs, examples, and effective dates in a consistent format.
• Before: Hotfixes diverged from specs. After: Pull requests required a linked spec ID and approvers; merges were blocked on failing tests.
• Before: QA built ad hoc test cases. After: Example scenarios in specs generated decision tests that ran in CI.
• Before: Plan-year logic drifted. After: Effective-dated rule versions and release packaging aligned behavior by plan and segment.
• Before: Audits required manual reconstruction. After: Bills of rules and evidence packs tied spec, code, tests, and approvals together.
• Before: Support escalations chased intent. After: Determinations referenced the exact approved rule and spec link.

Key Takeaways

• Make policy executable; structured specs and decision tables bridge narrative intent and code.
• Tie specs to code and tests; require linked IDs and run example-driven regression in CI.
• Govern exceptions; approvals with reason codes and expirations keep agility without losing control.
• Treat effective dates as first-class; multiple active versions and release packaging avoid logic drift.
• Expose status where teams work; Confluence, GitHub Actions, and Jira provide a shared fact base.
• Integrate, don’t replace; keep the rules engine and claims core, add orchestration and governance around them.

FAQ

What tools did this integrate with? Confluence hosted structured specifications and status views (Confluence). The rules engine repository contained executable logic (for example, decision tables following DMN or rules in Drools). GitHub Actions ran linting and regression checks (GitHub Actions). Optional Jira badges reflected readiness in planning.

How did you handle quality control and governance? Confluence templates enforced structured fields and spec IDs. Pull requests in the rules repo required linked specs, passed regression checks, and had code-owner approvals from Product and Policy. Exceptions required e-signatures and reason codes. Branch protections and immutable logs preserved an audit trail from spec to code to test results.

How did you roll this out without disruption? The workflow ran in shadow mode first, generating tests from existing specs while teams continued current practice. After templates and checks were tuned, the gate was enabled for one plan family during a renewal cycle, then expanded. Legacy paths remained as a controlled fallback early on.

How were regression tests created and maintained? Each Confluence spec included example scenarios with inputs, expected outputs, and effective dates. The synchronization service translated these into decision tests run in CI. QA expanded coverage by adding scenarios to the same spec template, so tests and specs evolved together under change control.

How did you manage effective dates and multiple plan versions? Rules supported multiple active versions keyed to plan, segment, and date ranges. Release packaging produced a bill of rules indicating which version applied to each plan and period, with links to the governing specs. CI validated behavior across relevant date windows before release.

Did this require changing the rules engine or claims core? No. The orchestration wrapped the existing rules engine and claims core. It added structured templates, repo synchronization, CI checks, and approvals. Execution artifacts and deployment paths remained the same, with better traceability and fewer surprises.