Inside Use-Case Matching: How WoundScribe Surfaces the Right Product for Each Wound…
product
A look inside the matching engine that decides which catalog product appears for which wound, and why clinicians trust it.
The Product Catalog only works if the right product surfaces for the right wound. That's the job of WoundScribe's use-case matching engine.
What matching actually reads
Matching does not run on a single snapshot. It reads the wound's healing trajectory — measurements over time — plus wound phenotype, comorbidities, prior treatments, and reapplication history. This is the same trajectory data powering the healing analytics dashboard.
Inputs include:
- Wound phenotype — DFU, VLU, pressure injury, surgical dehiscence, and sub-types.
- Trajectory state — progressing, stalled, or declining, based on serial measurements from AI-powered wound imaging.
- Treatment history — prior products used, reapplication counts, response.
- Patient context — diabetes control, perfusion status, offloading compliance.
How rules are configured
Each catalog product carries a matching rule set assembled during onboarding with the partner's clinical team:
- Approved indications and contraindications.
- Preferred trajectory triggers (e.g., stalled DFU after 4 weeks of standard care).
- Reapplication windows and code caps.
- Exclusion criteria — where the product should not surface.
What the clinician sees
At the point of care, matched products appear with:
- The specific rationale ("stalled DFU, week 5, appropriate for skin substitute").
- Approved indication text.
- Correct HCPCS/CPT codes, reducing denial risk.
What matching does not do
Matching does not choose the treatment. It surfaces options with rationale; the clinician decides. That guardrail is why matching earns clinician trust rather than getting dismissed as advertising.
See the full workflow in the solutions overview.