Enrollment & Claims Platform Modernization

Licensing, implementation support and design review for the six downstream integrations. Issued under the governing master agreement.

SOW-002 · Integration Middleware Implementation Support

1 · Parties and Instrument

2 · Scope

The program is replacing a set of point-to-point interfaces with a middleware layer. Today each downstream system connects to the core platform directly, so every change to the platform is a change to every interface that touches it, and no interface can be tested without the systems at both ends of it. The layer exists to break that coupling: interfaces are defined once, against the layer, and the systems behind it change independently.

Six downstream integrations move onto the layer during this engagement. The Vendor licenses the middleware and supports its implementation; the Client builds and owns the integrations themselves. That division is deliberate, and it is why this Statement of Work is shaped as support rather than delivery: the knowledge of what a claim record means in this business sits with the Client and cannot be transferred to a supplier inside one engagement. What can be transferred is the Vendor's knowledge of its own product, and that is what is being bought.

In scope. Licensing for the program's non-production and production environments; installation, configuration and environment validation support; interface design review against the Vendor's published patterns, with written findings; resolution of defects in the middleware product itself; and a named technical contact available during Client business hours through go-live.

Out of scope. Building, testing or maintaining the six integrations, which are the Client's. Data mapping decisions, which need business knowledge the Vendor does not hold. Remediation of defects in Client-built interfaces, even where the middleware is what surfaced them. Performance tuning of downstream systems the Vendor does not supply. Production operations after warranty exit at program closeout on Nov 2, 2027.

Anything not described in this section is out of scope. The boundary is stated both positively and negatively because a boundary discovered during delivery is renegotiated under pressure, at a price set by whichever party can least afford to walk away. A boundary written down before execution is simply the deal.

3 · Approach

The engagement runs in three phases, sequenced so the expensive work is never attempted first. Environments are licensed and proven before any interface is designed against them, and designs are reviewed before they are built, because a pattern error found in review costs a conversation and the same error found in test costs a rebuild.

The Vendor's method is review-led rather than build-led. Its consultants do not write the integrations; they read the Client's designs against the product's published patterns and state, in writing, which parts will work as drawn and which will not. Findings are classified so the Client can triage them: a must-fix finding blocks the interface, a should-fix finding will cost more later than now, and an advisory finding is a preference the Client is free to decline.

Environment parity is treated as a deliverable rather than an assumption. Each environment is demonstrated against the same test artifact, and any configuration difference between environments is listed rather than corrected silently — an undocumented difference between test and production is where integration programs fail late and expensively.

Work runs against the Client's own schedule. The Vendor attends the program's weekly delivery forum and reports against the measures below. Reporting is an obligation of this SOW rather than a courtesy: a service level that is not reported is not being managed.

4 · Delivery Phases

Phase 1 — Environments

Licensing applied and every environment proven reachable and deployable before design work begins.

Phase 2 — Design review

Each of the six integration designs read against the product's published patterns, with written findings the Client can triage.

Phase 3 — Validation and readiness

Environments re-proven after configuration, and a written statement of production readiness with residual findings named.

5 · Acceptance

Each Deliverable is submitted with the evidence its acceptance criteria call for. The Client has the stated Review Period to accept, or to reject in writing with specific, criterion-by-criterion reasons. Silence for the whole Review Period is acceptance — deemed acceptance — because a program cannot hold a supplier to a date while leaving its own review open-ended.

A rejection must identify which criterion failed and how. An objection that the Deliverable is not what was expected, where it meets every stated criterion, is a variation rather than a rejection. The Vendor re-submits within ten Business Days and a second Review Period of five Business Days runs. A Deliverable rejected twice on the same criterion is escalated rather than looped.

The Review Period is deliberately short and deliberately symmetrical. The Client gains a fixed window in which to find defects; the Vendor gains certainty that the window closes.

6 · Timeline and Resourcing

The engagement runs from execution to warranty exit at program closeout on Nov 2, 2027. Phase 1 completes before Phase 2 begins; Phase 3 overlaps the tail of Phase 2 where a design has been signed off early. The critical dependency is environment availability, which is the Client's.

The table below shows who is involved on each side. Client effort is drawn from the program's Resource Plan and is not charged under this SOW; it is shown because the Vendor's dates depend on it. Vendor rows are roles rather than named individuals, consistent with the rest of this suite.

7 · Fees and Payment

Fees are payable as percentages of the committed value against named Deliverables, never against elapsed time. Percentages are used rather than restated dollar amounts so that a variation to the value does not leave a payment schedule that no longer sums.

• 30% on acceptance of D-M1.
• 30% on acceptance of D-M2.
• 25% on acceptance of D-M3.
• 15% on acceptance of D-M4.

Invoices are payable thirty days from receipt of a correct invoice. The Client may withhold the disputed portion of an invoice, and only that portion. No fee is payable for a Deliverable that has not been accepted.

8 · Assumptions

The dates and the price in this Statement of Work rest on the following. Each is stated so that its failure is visible rather than argued about later; where one fails, the consequence is handled under Project Variations.

• Environments are available and reachable within ten Business Days of execution. Phase 1 dates move day-for-day with any delay here.
• The six integration designs are complete enough to review when submitted. A design submitted incomplete is returned rather than reviewed, and the review clock restarts on re-submission.
• The integration count is fixed at six. A seventh is a variation, priced separately.
• Test data meeting the agreed profile is available for environment validation. The Vendor does not create test data.
• The Client's integration architect is available for finding walk-throughs within five Business Days of each written review.
• No change to the middleware product version during the engagement, other than patches the Vendor recommends and the Client accepts.

9 · Project Variations

Either party may propose a variation. The Vendor prices it within five Business Days, stating the effect on fees, on dates, and on any other Deliverable. No variation takes effect until both parties sign, and work performed in anticipation of one is at the Vendor's own cost — the clause exists so that goodwill work does not arrive later as an invoice.

Where an assumption in the preceding section fails, the consequence is handled here rather than absorbed silently. A failed dependency moves the affected dates by the period of delay and no more; it does not reopen scope or price unless the parties agree that it should.

A variation that alters the program baseline set at the Nov 3, 2026 milestone is additionally subject to program change control and the Change Control Board, not to this SOW alone. A change within the SOW is a commercial matter between the parties; a change to the baseline is a program matter that other work packages depend on.

10 · Terminology

11 · Governing Agreement

This Statement of Work is issued under the Master Services Agreement between the parties and creates no rights independent of it. Warranty, limitation of liability, intellectual property, confidentiality, data protection, insurance, termination and dispute resolution are governed by the MSA and are not restated here. Restating them invites the two documents to disagree, and a Statement of Work that contradicts its own master agreement is worse than one that is silent.

Where the Vendor handles protected health information, the parties' Business Associate Agreement governs and prevails over both this SOW and the MSA to the extent of any conflict. On any other matter the order is: the BAA, the MSA, this SOW, then an executed variation, which prevails over this SOW only on the matter it changes. The Vendor's standard terms — in a portal click-through, an invoice footer or an order acknowledgement — are excluded.

12 · Execution

Executed following the approval convention this suite uses in SOW-001: the Vendor / Procurement Manager signs for the Client, the Vendor signs through its own authorized representative, and the internal approvals below are recorded separately. ⚠ The Program Manager approves but does not sign — program authority is not signing authority, and the separation is deliberate.

⚠ The Vendor is deliberately unnamed throughout this suite, so the vendor signature line carries a role rather than a person. That is the convention, not an omission — and an unexecuted Statement of Work does show a blank signature line on both sides. The Client side names individuals because they are the program's own people, who appear by name across the rest of the suite.