The bridge between business need and build. The BRD states what the business requires and why; this document states how the solution will behave to satisfy it — in enough detail for eighteen integration developers, the platform configuration team and the test organization to work from a single agreed definition. Produced during the Solution Architecture & Design phase, between requirements sign-off (3 Nov 2026) and integration build.
6
Interface specifications
3
BA domains
18
Developers served
FS-###
Traced to BRD FR-###
Design
Phase artifact
01 Document Position in the Specification Chain
Project Charter
Authorizes the program and its objectives
BRD
What the business needs and why. Design-agnostic, business language.
Functional Specification
How the solution behaves to satisfy the BRD. System behaviour, interfaces, rules, data.
Technical Design
How it is built. Owned by the architects and the vendor.
Why this document has to exist. The BRD is deliberately design-agnostic — it says a claim must adjudicate to the same outcome as the legacy system, not how the interface will carry it. That is correct for a requirements baseline, but it leaves a gap: eighteen developers cannot build six integrations from business statements. Without a functional specification, each developer resolves the ambiguity privately, and those private interpretations only surface during integration testing, when they are expensive.
Document control
| Owner | F. Jones — Lead Business Analyst |
| Domain authors | M. Ferraro (Underwriting & Billing) · T. Whitaker (Claims & Commission) · R. Okonkwo (Data Warehouse & Payment) |
| Technical review | J. Albert (Solution Architect) · M. Castillo (Integration Architect) · K. Larsson (Data Architect) |
| Phase | Solution Architecture & Design |
| Baselined against | BRD baseline of 3 Nov 2026 |
| Consumers | Integration developers (18), platform configuration, test design, training content |
Authored by the three domain Business Analysts who ran the requirements workshops for those same areas. Continuity of author from requirement to specification is deliberate — it is the cheapest available defence against meaning drifting between the two documents.
02 Specification Conventions
| Convention | Rule |
|---|---|
| Identifier | FS-###, each traced to one or more BRD FR-### requirements |
| Language | "The system shall…" for mandatory behaviour. "Should" is not used — if it is not mandatory it does not belong in a specification |
| Testability | Every specification must be verifiable by observation. A statement that cannot fail a test is not a specification |
| Design boundary | Specifies behaviour and data, not implementation. Technology choices belong to the technical design |
| Ambiguity | Where legacy behaviour and documentation conflict, the specification records the decision taken and its owner — never both options |
03 Solution Context
The upgraded platform is the system of record. It exchanges data with six downstream systems, each of which continues to operate unchanged apart from its interface to the platform.
| Element | Role | Change under this program |
|---|---|---|
| Core platform (vendor-delivered) | System of record for member, policy, provider/producer and claims | Version upgrade + configuration |
| Billing | Premium invoicing and receivables | Interface re-established |
| Underwriting | Risk assessment, rating, policy issuance | Interface re-established |
| Claims Administration | Claim intake and downstream processing | Interface re-established |
| Commission Management | Producer commission calculation and payment | Interface re-established, with a rule correction (FS-041) |
| Data Warehouse / Reporting | Analytical and regulatory reporting | Extract interface re-established |
| Payment Processing | Disbursement and payment status | Interface re-established |
04 Platform Configuration Specifications
| ID | Specification | Traces to |
|---|---|---|
| FS-001 | The system shall support member enrollment, change, termination and reinstatement transactions, including retroactive effective dating within the configured retroactivity limit | FR-001 |
| FS-002 | The system shall reject a retroactive transaction beyond the configured limit and route it for supervisory override rather than failing silently | FR-001 |
| FS-003 | The system shall maintain group, policy and benefit-plan configuration equivalent to the legacy production configuration as at the conversion cut date | FR-002 |
| FS-004 | The system shall maintain provider and producer records with hierarchy and effective dating, preserving legacy identifiers as cross-reference | FR-003 |
| FS-005 | The system shall adjudicate a claim against the benefit configuration in force on the claim's date of service, not the date of processing | FR-004 |
| FS-006 | The system shall support claim adjustment, reversal and reprocessing, retaining the original transaction and linking the adjustment to it | FR-005 |
| FS-007 | The system shall apply coordination-of-benefits rules where more than one coverage is in force, determining primacy per configured order of benefits | FR-006 |
| FS-008 | The system shall carry converted accumulator balances (deductible, out-of-pocket) forward such that a member's plan-year position is continuous across the conversion boundary | FR-007, TR-001 |
| FS-009 | The system shall enforce role-based access with segregation of duties preventing the same user from both entering and approving a financially material transaction | FR-008 |
FS-005 and FS-008 are the two that break programs. Adjudicating against date-of-service configuration rather than processing date is the difference between correct and incorrect payment on any claim submitted after a benefit change. And accumulators that reset at conversion mean a member who has already met their deductible is asked to meet it again — a defect invisible in testing unless the test data deliberately spans the conversion boundary, which is why the Test Strategy requires exactly that.
05 Integration Specifications — Domain A M. Ferraro
FS-010 to FS-019 · Billing Interface
| Purpose | Supply premium, adjustment and membership data sufficient for invoicing and receivables |
| Direction | Platform → Billing (outbound), with acknowledgement return |
| Trigger | Scheduled batch on the billing cycle, plus event-driven for mid-cycle membership change |
| Traces to | FR-009, SR-004 |
| ID | Specification |
|---|---|
| FS-010 | The system shall transmit billable membership and premium data per billing cycle, keyed by group, policy and member |
| FS-011 | The system shall transmit retroactive membership changes as explicit adjustment records, never as silent restatement of a prior period |
| FS-012 | The system shall include a control total (record count and premium sum) in each transmission for receiving-side reconciliation |
| FS-013 | The system shall not transmit a partial cycle: a transmission is complete or it is not sent |
| FS-014 | The system shall consume a billing acknowledgement and flag any cycle unacknowledged within the configured window |
FS-020 to FS-029 · Underwriting Interface
| Purpose | Provide risk and policy data required for rating and issuance; consume issued policy terms |
| Direction | Bi-directional |
| Trigger | Event-driven on new business and renewal; scheduled for in-force refresh |
| Traces to | FR-010, SR-003 |
| ID | Specification |
|---|---|
| FS-020 | The system shall transmit risk and census data required for rating at new business and at renewal |
| FS-021 | The system shall consume issued policy terms and apply them to the policy record as the authoritative rating outcome |
| FS-022 | The system shall not permit enrollment against a policy whose terms have not been received and applied |
| FS-023 | The system shall retain the rating basis applied to each policy period for audit and dispute resolution |
06 Integration Specifications — Domain B T. Whitaker
FS-030 to FS-039 · Claims Administration Interface
| Purpose | Exchange claim intake, adjudication outcome and status at production volume |
| Direction | Bi-directional |
| Trigger | Continuous intake; batch adjudication outcome on the processing cycle |
| Traces to | FR-011, SR-002 |
| ID | Specification |
|---|---|
| FS-030 | The system shall accept claim intake records and acknowledge receipt individually, so that a rejected record is identifiable without reference to the batch |
| FS-031 | The system shall return adjudication outcome including allowed amount, member responsibility, and denial reason where applicable |
| FS-032 | The system shall transmit claim status transitions as discrete events, preserving sequence |
| FS-033 | The system shall link an adjustment or reversal to the original claim identifier in every transmission |
| FS-034 | The system shall complete the daily adjudication outcome transmission within the batch window defined in NFR-002 |
FS-040 to FS-049 · Commission Management Interface
| Purpose | Provide the data required to calculate and trigger producer commission payment |
| Direction | Platform → Commission Management (outbound) |
| Trigger | Scheduled on the commission cycle |
| Traces to | FR-012, FR-016, SR-004 |
| ID | Specification |
|---|---|
| FS-040 | The system shall transmit earned premium by producer, policy and period as the commission calculation basis |
| FS-041 | The system shall apply the documented business decision resolving the divergence between the published integration specification and legacy calculation logic; the decision, its owner and its date are recorded in the business rules catalogue (Section 08) |
| FS-042 | The system shall transmit chargebacks and reversals explicitly where premium is refunded or a policy is rescinded |
| FS-043 | The system shall preserve producer hierarchy as at the effective date of the transaction, not as at transmission date |
FS-041 is the specification this whole document justifies. Issue I-004 found that the Commission Management integration specification and the legacy calculation logic disagreed — the document described what the system was believed to do, and the code did something else. Without an FSD, each of the three Commission developers would have resolved that discrepancy independently, and the divergence would have surfaced in integration testing as three different answers. Here it is resolved once, in writing, with a named decision owner.
07 Integration Specifications — Domain C R. Okonkwo
FS-050 to FS-059 · Data Warehouse / Reporting Interface
| Purpose | Deliver extracts sufficient for operational, analytical and regulatory reporting |
| Direction | Platform → Data Warehouse (outbound) |
| Trigger | Nightly full and incremental extracts |
| Traces to | FR-013, FR-017, SR-007 |
| ID | Specification |
|---|---|
| FS-050 | The system shall produce nightly extracts covering member, policy, provider, claim and financial transaction entities (supports FR-020) |
| FS-051 | The system shall include record counts and financial control totals with every extract |
| FS-052 | The system shall flag an extract as incomplete rather than deliver partial data, and shall not overwrite the prior good extract with a failed one |
| FS-053 | The system shall preserve legacy keys as cross-reference so that reporting spanning the conversion boundary remains continuous |
| FS-054 | The system shall supply the data elements required for each state-mandated filing currently produced |
FS-060 to FS-069 · Payment Processing Interface
| Purpose | Initiate disbursement instructions and consume payment status with full reconciliation |
| Direction | Bi-directional |
| Trigger | Scheduled on the payment cycle; status consumed continuously |
| Traces to | FR-014, SR-004, SR-005 |
| ID | Specification |
|---|---|
| FS-060 | The system shall transmit payment instructions with payee, amount, and the claim or premium transaction they settle |
| FS-061 | The system shall consume payment status (issued, cleared, returned, stopped) and update the originating transaction |
| FS-062 | The system shall not permit duplicate payment instruction for the same settled transaction, enforced by idempotency key |
| FS-063 | The system shall reconcile instructed against confirmed payment each cycle and raise an exception for any unmatched item |
| FS-064 | The system shall retain payment audit trail sufficient for SOX control evidence (satisfies FR-018 for payment transactions) |
FS-062 exists because of how payment defects actually happen. Duplicate payment is rarely caused by a person pressing a button twice; it is caused by a retry after an ambiguous failure, where the sender does not know whether the first instruction was received. Idempotency at the interface is the control, and it has to be specified — it is not a natural property of a retry mechanism.
08 Business Rules Catalogue
Rules that govern behaviour across more than one specification, recorded once so they cannot diverge.
| ID | Rule | Decision owner |
|---|---|---|
| BRule-01 | Benefit configuration in force at date of service governs adjudication, not date of processing | D. Kessler — Claims SME |
| BRule-02 | Producer hierarchy applies as at transaction effective date | M. Ferraro / Finance |
| BRule-03 | Commission calculation follows the documented resolution of the specification-versus-legacy divergence (I-004) | Finance, recorded with date |
| BRule-04 | Retroactive change beyond the configured limit requires supervisory override; it is never auto-applied or silently rejected | Enrollment Operations |
| BRule-05 | Duplicate member records resolved during conversion are merged under the documented rule, with the merge reversible | T. McCormick — per TR-002 |
| BRule-06 | A financially material transaction may not be entered and approved by the same user | G. Fenwick — SOX |
09 Data & Conversion Specifications
Detailed mapping is held in the Data Conversion Plan; this section specifies the functional behaviour the converted data must exhibit.
| ID | Specification | Traces to |
|---|---|---|
| FS-070 | Converted member records shall retain legacy identifier as cross-reference for the retention period | TR-001, FS-053 |
| FS-071 | Converted claims shall retain original adjudication outcome; conversion shall not re-adjudicate history | TR-001, FR-019 |
| FS-072 | Accumulator balances shall convert at plan-year position as at the cut date | FS-008, TR-001 |
| FS-073 | Records failing conversion validation shall be written to a quarantine set that is queryable and reportable — never discarded | TR-003 |
| FS-074 | Every merge of duplicate member records shall be recorded with source identifiers, rule applied, and timestamp | TR-002, BRule-05 |
10 Error Handling & Exception Standard
Applies to all six interfaces. Specified once here rather than repeated per interface, so that behaviour cannot diverge between developers.
| ID | Condition | Required behaviour | Traces to |
|---|---|---|---|
| FS-090 | Transmission failure | Retry per configured policy; after exhaustion raise an operational alert. Never fail silently. | FR-015 |
| FS-091 | Partial batch | Reject the batch; do not process partial. Report the failing record identifiers. | FR-015 |
| FS-092 | Record-level validation failure | Reject the record, accept the remainder where the interface is record-acknowledged, and report the rejection with a reason code | FR-015 |
| FS-093 | Duplicate submission | Detect via idempotency key and acknowledge without reprocessing | FR-015 |
| FS-094 | Control total mismatch | Halt downstream processing and raise an exception — a mismatch is never resolved by proceeding | FR-015 |
| FS-095 | Unmatched acknowledgement | Flag for operational review within the configured window | FR-015 |
One standard, six interfaces. Specifying error handling once is the single highest-value decision in this document. When each interface defines its own behaviour, operations staff must learn six different failure modes, and a control-total mismatch means something different depending on which interface reported it. A common standard makes exceptions interpretable by people who did not build the interface.
11 Security & Access Model
| ID | Specification | Traces to |
|---|---|---|
| FS-080 | Access shall be role-based, with roles mapped to current job functions and reviewed at implementation | FR-008, NFR-005 |
| FS-081 | Segregation of duties shall be enforced by the system, not by procedure alone | BRule-06, NFR-007 |
| FS-082 | Access to protected health information shall be logged with user, record, timestamp and action | NFR-006, FR-018 |
| FS-083 | Interface credentials shall be service-account based, individually attributable, and rotatable without code change | NFR-005 |
12 Traceability & Open Items
BRD to FSD coverage
| BRD requirement group | Specified by | Coverage |
|---|---|---|
| FR-001 – FR-008 (core platform) | FS-001 – FS-009 | Complete |
| FR-009 – FR-016 (integrations) | FS-010 – FS-064 | Complete |
| FR-017 – FR-020 (reporting & compliance) | FS-050 – FS-054, FS-082 | Complete |
| NFR-001 – NFR-012 | Referenced; realized in technical design | Referenced |
| TR-001 – TR-012 (transition) | FS-070 – FS-074; remainder in the Conversion and Cutover Plans | Partial by design |
The RTM is the missing link, and it is scheduled. The WBS contains a task to build a requirements traceability matrix, and the PMBOK® Guide names the RTM as an output of Collect Requirements alongside the requirements documentation itself. It now exists — see the Requirements Traceability Matrix, generated from this document and the BRD. Building it forced four implicit traces to be made explicit, including the shared error-handling standard, which now carries specification identifiers FS-090–095 against FR-015.
Open items at issue of this specification
| Item | Owner | Needed by |
|---|---|---|
| Confirmation of retroactivity limit to be configured (FS-002) | Enrollment Operations | Before configuration |
| Final reason-code set for claim denial transmission (FS-031) | D. Kessler | Before Claims interface build |
| Batch window confirmation at converted data volume (FS-034) | M. Alvarez | Before performance testing |
| State filing element set confirmation (FS-054) | Compliance | Before reporting build |
13 Approval
| Role | Name | Approval basis |
|---|---|---|
| Lead Business Analyst | F. Jones | Completeness and traceability to the BRD |
| Solution Architect | J. Albert | Technical feasibility and design boundary |
| Integration Architect | M. Castillo | Interface specifications are buildable and consistent |
| Data Architect | K. Larsson | Data and conversion specifications |
| QA / Test Lead | R. Whitfield | Every specification is testable |
| Program Manager | C. Tyrrell | Deliverable within schedule and budget |
QA Lead approval is a deliberate gate: if the test organization cannot design a test for a specification, that specification is not finished. It is the cheapest point at which ambiguity can still be removed.
Governing relationship. This specification is subordinate to the baselined BRD and governs integration build, platform configuration and test design. Changes route through the Change Control Log; a change that alters business need is a BRD change first and reaches this document second, never the reverse.