WorkSafeBC-oriented workflows without overclaims: structured summaries, careful language

Source: Dev.to

Goal: Structured Context, Not Proof

In work‑related injury workflows, people often need something that’s both:

• consistent enough for a clinician or case manager to scan
• grounded enough that it doesn’t feel like a rewrite of their experience

The temptation (especially in startups) is to over‑promise:

• “clinically validated”
• “compliant”
• “fills the official form”

If the code doesn’t do that, don’t say it.

Pain Tracker’s approach is more defensible:

• generate a structured summary of self‑reported data
• include explicit disclaimers
• keep the workflow local‑first and user‑controlled

WorkSafeBC Export (Local PDF Generator)

The implementation lives in the repository at:

• src/utils/pain-tracker/wcb-export.ts
• Test suite: src/utils/pain-tracker/wcb-export.test.ts

It uses jsPDF (via dynamic import) to produce a PDF as a data: URI string, then triggers a download. This keeps the boundary consistent with the “export = create a file locally” principle from Part 6—sharing is the user’s choice.

Careful Language in the Report

Pain Tracker bakes non‑claims directly into the PDF output. The report includes an explicit disclaimer (verbatim from the generator):

Disclaimer: This report is a structured summary of self‑reported pain data for WorkSafe BC reference only. It does not constitute medical advice, diagnosis, or treatment. This document should be reviewed with a qualified healthcare provider. Pain Tracker Pro is not affiliated with WorkSafe BC.

The disclaimer is not marketing; it defines the boundary:

• What the report is – a structured summary
• What it is not – medical advice, diagnosis, or legal determination
• Who should interpret it – a qualified healthcare provider

What the Report Actually Does (Grounded in Code)

The generator takes:

• a list of PainEntry records
• a date range (startDate, endDate)
• optional identifying fields (patient name, claim number, provider)

and produces:

• summary metrics (min / max / average, variability)
• lists of common locations / symptoms
• work impact and treatment summaries
• optional “detailed entries” (notes included when present)

Because you’re exporting self‑reported notes and shaping them into a “professional‑looking” document, careful language matters. The output must remain positioned as:

• a structured summary
• not a diagnosis
• not a legal determination

Workflow Framing That Respects People

The healthiest framing for these workflows is:

1. Capture – small, repeatable entries
2. Summarize – aggregate in a human‑readable way
3. Export – user‑controlled boundary

Anything beyond that (auto‑submission, background sharing, “send to insurer”) introduces a new trust boundary and new risks:

• network exposure
• account/identity handling
• consent UX
• audit trails

Pain Tracker’s local‑first stance intentionally limits the scope to the three steps above.

Next Up

Part 8 covers analytics without surveillance: how the repo gates outbound analytics behind both an environment flag and explicit consent, and how it avoids Class A fields in GA4 event parameters.

• Previous: Part 6 — Exports as a security boundary
• Next: Part 8 — Analytics without surveillance

Support This Work

• Sponsor the project:
• Star the repo: