REPRESENTATIVE VENDOR FIELD. Illustrative healthcare-AI procurement, not a real client RFP. No IQVIA or client data is touched. The four vendor rows are public archetypes; the method (four structural questions, the weighted scorecard, the posture gate) is the grounded part, from the 2013 OMA deliverables.
The best demo is third. One bid is unscoreable, not ranked.
Run a representative clinical-AI vendor field through four structural questions and a weighted scorecard. The verdict lands on one screen: the slickest demo does not win, and a "usage-based, we'll work with you" cost line gets flagged, not averaged in. This is the worksheet your advisory consultant performs with a client, on the client's own field and re-balanced weights.
Step 0 · Foundation-model posture (set this before any vendor is scored)
Walk a scenario: one click sets the view
Re-balance the weights (optional)
Default weights trace to the 2013 OMA scorecard: Functionality 25, Cost 20, Ops 20, Experience 15, Architecture 10, Integration 10. Re-balance per engagement; the verdict re-computes live.
Rank
Vendor (archetype)
Func
Cost
Ops
Exp
Arch
Integ
Score
Why one vendor scores 0 on Cost (and is flagged, not ranked)
The four structural questions (the gate before any vendor is scored)
Data control. What data are you allowed to use, by whom, under what conditions? Drawn as an architecture before the shortlist exists, not rubber-stamped at the back end.
Whose outcome. Say in plain English whose outcome the system optimises: clinician decision quality, payor cost, hospital throughput, or vendor renewal. On the first page.
How it fails safely. How does the model fail, and on whose dataset has the vendor shown it? Substantiated failure modes, or the claim is written unscoreable.
Who owns the audit. Put a name and a reporting cadence on "is this still doing what we bought it to do?" before signing, not 18 months after.
Model-monitoring ownership (the month-18 question)
Monitoring duty
Demo-only vendor
FM vendor
Probabilistic ML
Deterministic CDSS
Re-run parity / accuracy checks (quarterly)
No named owner
No named owner
Clinical informatics lead
Vendor + clinical lead
Accountable when the model drifts
No named owner
No named owner
Named on contract
Named on contract
Answers the regulator's audit request
No named owner
Vendor DPO
Named on contract
Named on contract
The gap: the two vendors with the strongest demos (the demo-only vendor and the foundation-model vendor) are exactly the two with no named owner for "is this still doing what we bought it to do in 18 months." That ownership is OMA Phase 2 governance, and it is assigned before signing, not after.
Honest bound. This is the method on a representative field, not a read of your client's real procurement. The real scoring happens in your engagement, with your client's vendors and your re-balanced weights. The vendor rows here are public archetypes, tuned to the structure of a real evaluation, never to a real vendor's numbers. The deliverable is the method and a worked example, embedded under your banner with Jeff as the named method author.
Sources & method
The weighted scorecard and weights (Functionality 25, Cost 20, Ops & Support 20, Experience 15, Architecture 10, Integration 10): from Jeff's 2013 Ontario Medical Association Big Data deliverables, the 11-vendor CDSS interview matrix. GROUNDED. Published as the method note at jeffpinto.com/notes/oma-big-data-revisited.
The four structural questions and the posture gate (data control, whose outcome, how it fails safely, who owns the audit; posture upstream of vendor): same OMA deliverables, with the foundation-model posture gate added as the documented 2026 modification. GROUNDED.
The four vendor rows: REPRESENTATIVE public archetypes (a deterministic rules-engine CDSS, a probabilistic ML tool, a general-purpose foundation-model vendor with usage-based pricing, a demo-only vendor with unnameable references). No real company is scored; the per-criterion scores are illustrative, tuned to the structure of a real evaluation, not to any vendor's real numbers. ILLUSTRATIVE.
Regulatory frame: Ontario's PHIPA (Personal Health Information Protection Act, 2004) governs the data-control question in Ontario; the method names data control and audit ownership up front because the statute makes the physician the data custodian.