Payments domain model

Product boundary

Payments owns the contractual interpretation that an authoritative clinical or site activity earns a payable amount. It does not own the Subject Visit, Procedure, approval, or other trigger occurrence.

SiteAgreement
└── FeeSchedule
    ├── VisitFee
    ├── ProcedureFee
    ├── SiteFee
    └── PayeeRule / PayeeOverride

Authoritative PayableActivity
└── FeeEvaluation
    └── PayableItem
        └── PaymentRequest
            └── PaymentInstruction / PaymentResult

Key behaviours

• approve a Fee Schedule with effective dates and currency;
• evaluate Subject Visit, Procedure or Site Fee activity against fee criteria;
• create one Payable Item per resolved payee;
• hold, adjust, reverse, approve or dispute a Payable Item;
• group eligible Payable Items into a Payment Request;
• issue payment information to the site and reconcile the external payment result.

An activity correction re-evaluates the payable. It never edits the original clinical occurrence. A mismatch can adjust or reverse the payable while preserving the calculation and agreement version.

Evidence crosswalk

Observed product behaviour	TechSol decision	Difference / question
Fee types are Visit, Procedure and Site Fee	Fee is a discriminated rule tied to one trigger type	do screen-failure and conditional fees need specialized subtypes?
Payable Items are generated when activities reach configured statuses	FeeEvaluation consumes an authoritative occurrence/version	when does a corrected occurrence reverse versus adjust?
Payee override outranks schedule payee, which outranks site payee	PayeeResolutionPolicy records inputs and selected result	can one item legitimately split among several payees?