What a UK product specification has to say
The catalogue models cover well: modules, limits, contributions, channels, a clinical vocabulary. The question this page answers is a different one - not "is the shape consistent" (that is #1657) but is the specification complete for a product sold in the UK.
Two sources decide that: what a PMI product is made of (IF7, Healthcare insurance products), and what a UK insurer is obliged to tell a customer (IF1, Insurance, legal and regulatory). Measured against both, the catalogue is one layer of three.
The completeness test: can the catalogue produce the IPID?
Since October 2018 an Insurance Product Information Document must be given to every retail customer before a sale or renewal, whatever the channel. IF1 describes it as "a short, pre-contractual, non-personalised product summary document, the layout of which is fixed and must follow closely what is prescribed in the IDD", whose purpose is "to allow customers at the quotation stage to compare similar products offered by different insurers in an easy-to-follow consistent way".
That gives a sharper completeness criterion than any gap list: a product specification is complete when the IPID can be generated from it. The layout is fixed, so the required facts are known in advance, and a field the catalogue cannot supply is a field a human is retyping into a regulated document.
We already generate the Benefit Schedule from the catalogue (plan documents). The IPID is its regulated sibling, and it asks for things the catalogue does not hold:
| IPID asks | Catalogue today |
|---|---|
| What is this type of insurance? | product lob only; no product-type statement |
| What is insured? | yes - modules, limits, includes |
| What is not insured? | yes - exclusions, and channel absence |
| Are there any restrictions on cover? | partial - restrictions, but excess and waiting periods are absent or untyped |
| Where am I covered? | restrictions.residency, no territorial scope for treatment |
| What are my obligations? | absent - disclosure duty, notification of change |
| When and how do I pay? | term.payment, no instalment terms |
| When does the cover start and end? | term.start, cycle; no end/renewal terms |
| How do I cancel? | term.cooling_off_days only |
Note the asymmetry: everything we model well is the benefit axis, and every missing row is a contractual one.
Layer 1: cover - largely complete
IF7 lays out the anatomy of a UK PMI product in chapter 3. Mapping it:
| IF7 | Catalogue |
|---|---|
| A5 comprehensive / A6 mid-range / A7 basic policies | tiers as separate products; equivalent |
| A5A hospital charges · A5B specialist fees · A5C out-patient | modules are service-typed, not cost-typed. A defensible difference for a digital product, but it means an invoice split by hospital versus consultant has nowhere to land |
| A8 menu products | addons with optional |
| A9 exclusions | structured objects with basis and enforcement |
| A11 benefit limits | per-module included_per_cycle / cycle_limit |
| A3 hospital bands | absent - no facility or network tiering |
| A12 policy excess | absent |
| A13 pricing structure and discounts | absent beyond a flat per-member premium |
The three absences are not exotic. IF7 A12: "most healthcare insurers offer customers the option of an excess (sometimes called a deductible) on their policy... they agree to pay the first £100 of their medical expenses in the event of a claim during any one year in return for a lower premium"
. An excess is how UK buyers expect totrade price against cover, and we cannot express it.
Layer 2: commercial terms - mostly missing
The catalogue prices one way: a flat premium per member per month. IF7's corporate chapter describes a market that does not work like that.
Funding basis (A10F). For large corporate schemes IF7 lists fully insured, risk share, cost plus, self-insured and corporate deductible, and notes fully insured "is the most common approach... where there are fewer than 1,000 employees on cover". Only the first is expressible today. This is what schemes.premium_basis was reserved for, and it decides who carries claims risk - a fact that belongs in the specification, not in a spreadsheet.
Underwriting style. IF7's syllabus names the styles a UK product must declare: "moratorium, full medical underwriting, continued personal medical exclusions (CPME), medical history disregarded (MHD)". We carry one string, pre_existing_conditions.basis = "assessed_at_claim", roughly meaning moratorium. CPME and MHD are precisely what an employer moving members from another insurer asks for, and neither is sayable.
Rating factors. A13 covers pricing structure and discounts; we have neither age-banding nor a no-claims mechanism, though IF7 carries an entire AXA PPP NCD guide as source material. Whether Olly wants NCD is a product decision; whether the specification can express one is a shape decision, and today it cannot.
Layer 3: regulatory - absent entirely
None of this exists in the catalogue, and all of it is a fact about the product rather than about a member:
- Target market. The FCA's authorisation function focuses on product governance; a product that cannot state who it is for cannot evidence that it is being sold to them.
- IPID reference. Which IPID version corresponds to this product version. Since both are versioned, this is a pin, not a filename.
- Renewal disclosure. IF1: for consumers "the renewal notice must include the renewal premium, the previous year's premium and a statement that the consumer should ensure that the level of cover is appropriate and can compare prices and cover with other providers". Producing that requires the prior term's premium, which nothing on the product knows how to find.
- Cancellation and refund terms. We hold
cooling_off_days: 14; what happens on day 15 is unstated . - Regulatory permissions.
policy_schema.regulatorynames the regime; nothing records what the product is authorised to be sold as, or to whom.
Suggested changes to the specification
In the order I would make them, cheapest-and-most-structural first.
1. Add a contract block. Everything the IPID needs that is not cover:
"contract": {
"product_type": "private_medical_insurance",
"territorial_scope": "UK_treatment_only",
"term_length": "P1Y",
"renewal": { "basis": "annually_renewable", "notice_days": 21,
"discloses_previous_premium": true },
"cancellation": { "cooling_off_days": 14,
"after_cooling_off": "pro_rata_refund_less_claims" },
"obligations": ["notify_change_of_address", "answer_underwriting_questions_honestly"]
}This is where the missing IPID rows go, and it is cheap: additive, and nothing reads it until the IPID generator does.
2. Type the waiting periods. Today waiting_period_days: 0. A UK product needs at least initial, condition-specific and pre-existing, and the rule that the longer applies:
"waiting_periods": [
{ "kind": "initial", "days": 30 },
{ "kind": "condition", "days": 365, "conditions": [{"id":"…","key":"hernia"}] }
]The vocabulary already exists to key these: policy_admin.clinical_terms carries kind = condition. Changing a scalar to a list is free now and a migration later, which is why it belongs before the first externally-sold product.
3. Declare the underwriting style rather than implying it:
"underwriting": { "style": "moratorium", "moratorium_months": 24,
"declared_conditions_required": false,
"continuity_credit_accepted": true }continuity_credit_accepted is the switch that lets an employer move a scheme across without members re-serving waiting periods - the single most commercially significant field on this list.
4. Give cost-sharing a home, if the answer to "do we ever sell the same cover at two prices" is yes:
"cost_sharing": {
"excess": { "amount": 100, "currency": "GBP", "applies": "per_policy_year",
"premium_effect": "discount" },
"copayment": null
}IF7 notes the per-policy-year versus per-claim-year distinction, so applies has to be explicit. Per-module contribution stays as it is: it is a per-benefit co-payment and works.
5. Move funding basis onto the scheme, using the reserved column:
"premium_basis": { "funding": "fully_insured", "rating": "per_capita",
"risk_share": null }with funding from IF7's list. This is also the moment to settle whether scheme pricing may disagree with the catalogue price, which Scheme & roster §3 flags as decide-before-you-populate.
6. Add target market and IPID pin to the product version:
"governance": { "target_market": {"employment": "employed_uk", "age_min": 18, "age_max": 74},
"ipid_ref": "IPID-OHC-2026-v2", "fair_value_review": "2026-07-01" }Age bounds double as the product-eligibility gap (#1664 gap 7): a product that states its target market has also stated who can be covered.
What not to add
Room-rent caps, itemised consumables, proportionate deduction and named treatment-zone tiers are indemnity-market mechanics that do not apply to a session-and-contribution product. Sum-insured-as-a-pot is only needed if a shared cash allowance is sold; per-module limits express today's product correctly.
The one call that orders the rest
Items 1, 2, 3 and 6 are needed for any UK product and are cheap while nothing has been sold externally. Items 4 and 5 depend on a single commercial question: will the same cover ever be sold at two prices? If yes, cost sharing and funding basis are how the UK market expresses that, and both belong in the specification now. If no, they are a deliberate difference and this page should say so explicitly rather than leaving the absence to be discovered.
