Pain Tracker is a private pain tracking app for logging symptoms, spotting flare patterns, and preparing for appointments without creating an account or sending daily records to the cloud.

It is built for people who want practical pain tracking first: daily entries, local-first privacy, offline-capable use, and clinician-friendly exports when they choose to share.

I built PainTracker.ca because every mainstream pain-tracking app I tried made me want to throw my phone across the room.

Not because pain diaries are useless. The evidence for tracking is solid, and chronic pain is everywhere. But most "tracking" tools do not feel like care. They feel like surveillance systems wearing a wellness costume: cloud defaults, account gates, analytics, nagging prompts, and UX designed for compliance instead of capacity.

PainTracker.ca is a refusal of that trade.

It is a privacy-first, offline-capable, trauma-informed Progressive Web App that stores encrypted data locally by default and shares data only when the user deliberately exports it. The code is open-source, because privacy claims should not be marketing - they should be inspectable.

This essay argues that privacy-first, offline-capable, trauma-informed, open-source tools should become the default standard in digital health. They reconcile clinical usefulness with ethical obligations around data governance, user control, and psychological safety — without forcing people in pain to surrender their lives to someone else’s backend.

Two questions drive this essay

1. How does PainTracker.ca respond — architecturally, ethically, and experientially — to the failures of mainstream digital pain tools?

2. Can the combination of offline-first architecture, strict local storage, trauma-informed UX, and open-source transparency serve as a benchmark for digital health more broadly?

Method (brief, transparent)

This is a build-from-inside analysis: the PainTracker.ca architecture and design doctrine, the open repository, and the real constraints of tracking during flares, instability, and cognitive collapse — compared against published research on chronic pain prevalence, pain diaries, and privacy risks in health apps.

I. Chronic Pain and Why Tracking Still Matters

Claim: tracking helps — when it’s usable and safe.
Problem: most tools are neither.

A. Chronic pain is a structural public health crisis

Chronic pain isn’t a niche complaint. It’s a public health condition with gravity: function loss, disturbed sleep, depression, anxiety, relationship strain, and economic precarity.

Health Canada’s Canadian Pain Task Force estimates roughly one in four Canadians aged 15+ live with chronic pain — millions of people. They also emphasize what many patients learn the hard way: chronic pain is frequently entangled with mental health, substance use, stigma, and uneven access to care. Pain doesn’t sit beside inequity. It amplifies it.

Meanwhile, most health systems are still optimized for acute problems and short visits. Chronic pain doesn’t show up cleanly in a 15-minute appointment. It shows up as a month of unstable sleep, fog, medication shifts, activity limits, and flare patterns — compressed into a rushed “0–10 today?”

That compression isn’t just inconvenient. It shapes outcomes.

B. Why diaries and systematic tracking still matter

A well-structured diary changes the clinical conversation. A clinician sees a snapshot; a diary shows the movie.

When tracking is done well, it can:

• reveal patterns across sleep, stress, movement, weather, and medication

• surface triggers and pacing limits

• improve communication and credibility

• help justify treatment decisions, accommodations, and claims

This logic is old. Paper diaries existed long before apps. Tools like the University of Washington’s PainTracker questionnaire formalize this structure in clinic settings, monitoring pain, mood, sleep, and function over time.

The point isn’t “apps are the future.” The point is simpler:

Pain varies. Memory lies. Patterns matter.

C. Where paper and first-generation tools hit their limits

Paper is fragile and hard to analyze. Early electronic systems were often clunky and disruptive to workflow.

Smartphones looked like the fix: always-with-you devices, rich UI, cheap storage. In practice, many pain apps reproduced the old problems and added new ones:

• bright, high-glare screens

• dense layouts

• tiny tap targets

• long intake flows

• forced registration before you can log a single entry

• “helpful” notifications that feel like enforcement

During a flare — when pain spikes, sleep collapses, and cognition turns to fog — those aren’t mild annoyances.

They’re hard stops.

That contradiction is what pushed me toward building my own system:

We need tracking.
The tools we’re offered are often unacceptable.

II. What Breaks in Mainstream Pain Apps

Claim: the dominant pain-app paradigm is surveillance-first and capacity-blind.
Result: distrust, abandonment, and harm.

A. Surveillance becomes the default architecture

Most pain apps live inside commercial ecosystems. And commercial ecosystems tend to survive on data: analytics dashboards, behavioral insights, engagement funnels, partnerships, integrations, and centralized storage.

When the backend table becomes the design unit — not the person in pain — accounts, centralized databases, SDKs, and telemetry follow.

Research has shown that many health and wellness apps carry serious privacy failures: missing policies, insecure transmission, and mismatches between what they claim and what they do. Even when apps are “accredited,” the gap between policy and behavior can be wide.

Pain data is not step-count data. A pain diary can contain:

• medication history

• disability context

• work capacity patterns

• mental health signals

• trauma disclosures

• days where survival is in question

In hostile hands, that record can be used to deny benefits, undermine credibility, or surveil behavior. Asking people to centralize that data by default is not neutral.

B. Why people distrust these tools

Public concern about health app privacy is high. And for people living with chronic pain, disability, or trauma, distrust is sharper.

If you’ve been dismissed, disbelieved, or punished for telling the truth, the idea of pouring intimate detail into an opaque corporate system isn’t “paranoia.”

It’s pattern recognition.

So PainTracker.ca does not ask for trust. It removes the need.

No remote database.
No silent telemetry.
No hidden pipeline.

C. Trauma-uninformed UX becomes design harm

Even if privacy were perfect, most pain apps still fail on usability under stress.

Chronic pain brings fatigue and cognitive load. Trauma can bring hypervigilance, shame, avoidance, and sudden capacity drops. Tools that demand sustained attention, long sequences of micro-decisions, fine motor precision, or constant compliance don’t match the reality of living inside a flare.

Many apps also embed coercive patterns:

• streaks and gamification that treat lapses as failure

• “rate your pain now” prompts on the app’s schedule

• mandatory intake walls before any value is delivered

That’s not support. That’s behavior shaping.

Trauma-informed design is the opposite stance: choice, transparency, non-coercion, emotional safety, and respect for fluctuating capacity.

Pain apps rarely meet that bar.

D. Clinician tools: better governance, but still not patient-centered

Institutional tools like UW’s PainTracker generally have stronger governance than consumer apps. But they’re often designed to serve institutional workflow first: dashboards, metrics, billing, centralized storage.

The design question becomes:

How do we ingest structured data?

Not:

What does this feel like for someone living through it?

PainTracker.ca answers a different question:

How do we build something that primarily serves the person using it — and only secondarily, and on their terms, anyone else?

III. PainTracker.ca as a Countermodel

Claim: if you treat dignity as a constraint, the architecture changes.

A. Origin and non-negotiable constraints

PainTracker.ca began with a simple threat to myself:

If no existing app is livable, build one that is.

Hard constraints:

• works fully offline

• never sends data anywhere by default

• usable with low cognition and high distress

• transparent enough to verify

• built for lived reality, not “ideal user flows”

B. Offline-first, local-only: treat the device as the system

The central architectural move is blunt:

The device is the system.

PainTracker.ca runs as a PWA. The app shell can be cached for offline use. Data lives locally (IndexedDB or equivalent). Logs are encrypted locally.

The app doesn’t require connectivity to function. If you’re in a rural motel, a hospital basement, or anywhere signal is unstable, behavior remains the same.

Equally important:

The app does not silently transmit logs to a server.

This eliminates entire categories of risk:

• no centralized database to breach

• no vendor able to repurpose data later

• no bulk pain datasets to monetize

• no forced trust in shifting privacy policies

The trade-offs are real:

• no automatic cross-device sync

• no seamless EHR integration

• backups are user-controlled, not vendor-managed

That’s intentional. Convenience should not be bought with captivity.

C. Trauma-informed UX: design for “not okay” days

Architecture is the skeleton. UX is the nervous system.

The interface assumes the user may be:

• exhausted

• in pain

• fogged

• dissociated

• emotionally unstable

• operating one-handed

So the UI prioritizes:

• low glare, calmer visuals

• large tap targets

• shallow navigation

• minimal nesting

• fast logging paths

• optional detail, not mandatory walls

The rule is simple: remove friction that doesn’t add value.

D. Crisis-aware behavior without surveillance

One of the more experimental elements is a local crisis-detection engine.

I wanted the app to notice when I was struggling — without spying.

So the system looks only at local signals:

• spikes in pain

• missed entries

• patterns in user text (if enabled)

All computation stays on device. No cloud AI. No “send to model.” No phone-home.

When the engine flags possible crisis, it does not notify outsiders. It does not message clinicians or emergency services. It doesn’t escalate.

It adjusts the interface:

• fewer fields

• simpler language

• faster pathways to coping scaffolds the user chooses

The goal is not control. It’s support without coercion.

E. Open source as inspectability and accountability

I don’t expect anyone to trust a privacy claim because I said “trust me.”

So the code is open under the MIT license.

That means:

• anyone can confirm there are no hidden analytics SDKs

• anyone can inspect network behavior

• anyone can audit local storage and encryption handling

• the project is forkable by clinics, nonprofits, or communities

In a world where policies often diverge from actual behavior, inspectability isn’t a virtue signal.

It’s the ethical core.

IV. Strengths, Limitations, and Tensions

Claim: sovereignty improves safety — but challenges integration.

A. What PainTracker.ca gets right

• Architectural safety: no central hoard of pain data waiting to leak

• Psychological safety: honesty feels safer when nothing leaves the device by default

• Operational reality: offline-first works in the places people are actually suffering

A tool that fails without Wi-Fi is not “modern.”

It’s fragile.

B. Where the model is weak

The same choices that protect users make integration harder.

Clinicians can’t “just log in” and see your diary. Sharing requires deliberate action:

• show your device

• export a report

• print

• share a structured summary

That’s slower. It’s also more ethical.

Evidence is another gap. We have support for diaries in general, but we do not yet have direct trials proving that this particular combination — offline-first, local-only, trauma-informed UX — yields better adherence or outcomes versus typical cloud apps.

Accessibility is ongoing work. Open source makes improvement possible, but sustained funding and contribution are the bottlenecks — not feasibility.

C. Tensions that remain live

• Privacy vs population analytics: local-only design limits passive aggregation. Federated learning or privacy-preserving summaries could help, but can also re-centralize power if done carelessly.

• Inference vs autonomy: even local crisis detection is interpretation. To avoid “soft surveillance,” it must remain transparent, optional, minimal, and user-controlled.

• Open source vs regulation: current SaMD frameworks assume centralized vendors. Certifying and maintaining trust in open, forkable health tools is still an unresolved systems problem.

These tensions don’t invalidate the model. They keep it honest.

V. Why This Should Be the Default Standard

Claim: bioethics should be engineering constraints — not slogans.

A. Autonomy, turned into architecture

If autonomy is real, users must be able to:

• keep their data entirely local

• decide if and when to share

• revoke sharing without begging a vendor

A local-first, export-based model supports that by default.

B. Non-maleficence: remove structural harm

Pain tracking can help. But mainstream digital implementations add harms:

• breaches

• misuse

• coercive UX

• re-traumatization through surveillance patterns

When you treat harm reduction as an architectural requirement, “cloud by default” stops looking inevitable.

C. Justice: build for the people most harmed by surveillance

Chronic pain and surveillance both weigh hardest on marginalized groups.

Tools that are safer for those users are not “nice.”

They’re just.

Open licensing also supports justice:

• under-resourced clinics can deploy without per-seat fees

• communities can adapt the tool without permission

D. What the new baseline should be

For pain tools — and many other health tools — the default expectations should be:

1) Local-first by default

Data stored and processed on device. Any remote storage is opt-in, scoped, and revocable.

2) Trauma-informed UX

Design for fluctuating capacity. Reduce coercion. Ensure transparency and emotional safety.

3) Inspectability

Data flows and critical logic should be auditable. Where public trust is involved, open review should be normal.

PainTracker.ca is one working example of that baseline.

The technical barriers are lower than the cultural and economic ones.

VI. What Needs to Be Studied Next

If this approach is going to move from GitHub into mainstream use, it needs a research agenda:

• Head-to-head trials: local-only tools vs cloud apps on adherence, trust, privacy anxiety, and clinical outcomes

• Measuring trauma-informed UX: validated measures for perceived safety, cognitive load, and coercion effects

• Privacy-preserving interoperability: encrypted exports, privacy-preserving summaries, consent-first research pathways

• Equity and accessibility audits: participatory testing across disability types, languages, and communities

• Regulatory frameworks for open tools: certification models that don’t require central vendors or closed code

VII. Conclusion

Chronic pain shapes millions of lives. There is strong evidence that structured tracking and pain diaries can improve management and clinical communication.

But the current landscape is dominated by surveillance-heavy architectures and trauma-blind UX. People in pain are repeatedly asked to trade away privacy and autonomy for tools that often fail them when they need support most.

PainTracker.ca is a counterexample: proof that it is technically straightforward to build a serious health tool that does not spy.

By keeping data local, working offline, designing around crisis realities, and shipping as open source, it demonstrates a different standard — one aligned with user dignity instead of data extraction.

The stakes reach beyond chronic pain. The same logic applies to mental health apps, reproductive health trackers, HIV adherence tools, and any system where logs intersect with stigma and power.

Once we accept that at least one health tool can operate without hoarding intimate data, the old excuse — “this is just how digital health works” — stops working.

The question is no longer whether privacy-first, trauma-informed, open tools are possible.

The question is whether funders, regulators, and institutions are willing to choose them.

Works Cited

• CareClinic. “Pain Tracker – CareClinic.” Google Play Store. Accessed 1 Dec. 2025.

• CrisisCore-Systems. pain-tracker (GitHub repository). Accessed 1 Dec. 2025.

• CrisisCore Systems. “Building a Healthcare PWA That Actually Works When It Matters.” DEV Community. Accessed 1 Dec. 2025.

• CrisisCore Systems. “Building a Pain Tracker That Actually Gets It — No Market Research Required.” DEV Community. Accessed 1 Dec. 2025.

• CrisisCore Systems. “Trauma-Informed Design Left Everyone Asking: ‘How Does It Actually Know I’m Struggling without Spying?’” DEV Community. Accessed 1 Dec. 2025.

• Danquah, Ama, and Kobi Addae. “Why Trauma-Informed Digital Design Is Relevant in 2022.” Centric Community Research. Accessed 1 Dec. 2025.

• Health Canada. Chronic Pain in Canada: Laying a Foundation for Action (Canadian Pain Task Force, June 2019–May 2020). Government of Canada, Sept. 2020. Accessed 1 Dec. 2025.

• Jamison, Robert N., et al. “In-Clinic Use of Electronic Pain Diaries: Barriers of Implementation among Pain Physicians.” Journal of Pain and Palliative Care Pharmacotherapy, 2010. Accessed 1 Dec. 2025.

• Luong, Thanh-Tam, et al. “Unaddressed Privacy Risks in Accredited Health and Wellness Apps: A Cross-Sectional Systematic Assessment.” BMC Medicine, 2015. Accessed 1 Dec. 2025.

• News-Medical Life Sciences. “Using a Pain Diary.” 2019. Accessed 1 Dec. 2025.

• University of Washington. “PainTracker Patient Questionnaire.” UW Medicine Center for Pain Relief. Accessed 1 Dec. 2025.

• University of Washington. “PainTracker.” CoMotion. Accessed 1 Dec. 2025.

• Wiggers, Alex. “A Major Obstacle to Tech Companies Developing Health Apps: About 2 in 3 Adults Worry About Their Privacy.” Morning Consult Pro, 2021. Accessed 1 Dec. 2025.

• PainTracker.ca. PainTracker.ca. Accessed 1 Dec. 2025.

It starts there—L4–L5.
A clean clinical label. A scan result. A neat little diagnosis.

But then it spreads.
It migrates.
It leaks into your sleep, your relationships, your ability to feel like yourself in your own skin.

People talk about workplace injuries like they’re mechanical failures—
as if you replace a part, rest for a while, do physio, then return to normal.

That wasn’t my experience.

My experience was this:

The injury became a portal.
And on the other side of it, I was still alive—
but not intact.

Before / After

Before, I was an HVAC&R technician.
Not just “a job.” A trade. A craft.
A place where competence meant something.

I was the guy who could walk onto a site and know what to do.
Solve problems under pressure.
Read systems.
Improvise when reality didn’t match the manual.

I didn’t just work.
I functioned.

And then my back went.

And it wasn’t just pain.
It was the sudden loss of the one identity that gave me:

• momentum

• structure

• self-respect

When your body becomes unreliable,
it’s not only your spine that feels unstable.

Your entire life becomes unstable.

The floor: the smallest kind of exile

For four months, I slept on the living room floor.

Not for drama.
Not as a symbolic “rock bottom.”

Because the floor was firm,
and firm hurt less than a bed.

That’s how recovery started for me:

Not in a clinic.
Not with hope.
But with a tactical decision—

What surface hurts less to exist on?

The floor wasn’t comfort.
It was containment.

And when your world shrinks to a rectangle of carpet and pain,
something else happens:

You stop being a person living a life
and start becoming
a mind trapped in a body.

The isolation nobody warns you about

Before the injury, I had daily human contact—
worksites, coworkers, customers,
conversations that weren’t deep but still mattered
because they proved you were part of the world.

Then that went to zero.

Not “less social.”
Not “a quiet phase.”

Zero.

Four months of silence turns your own mind
into a closed room with no oxygen.

You can’t get away from yourself.
No rhythm. No reason to get dressed.
No proof that time is moving forward.

Just pain and hours.

And pain isn’t neutral.
Pain has gravity.
It pulls thoughts toward the worst places.

Medication doesn’t just treat symptoms

It changes the person

The depression got heavy.
Medicine responded the way medicine often does:

Increase dosage.

Seroquel.
Then more Seroquel.
Up to 150 mg every night.

Polite literature calls it stabilization.
What it felt like was being hit
with a pharmaceutical bat.

It didn’t just help me sleep.
It flattened me.

Personality. Humor. Softness. Nuance.
Muffled—like someone threw a heavy blanket over my soul.

And what’s left when you dull a human being to almost nothing?

Not peace.

Often, what survives sedation
is the primal stuff.

Anger survives.

So I became a horrifying version of myself:

Zombie-still most of the time…
but if something touched the wrong nerve,
rage erupted like it was the only emotion strong enough to move my body.

That’s the part people don’t understand about heavy medication:

Sometimes you don’t become better.
You become less human in a way that makes everyone around you feel unsafe.

And then you get blamed
for being someone
you barely recognize.

The Ritalin: the escape hatch that becomes a trap

Inside that deadened existence,
I started abusing my Ritalin.

Not to party.
To escape the feeling of being trapped
inside my own head,
watching my life rot in real time.

When isolation lasts long enough,
anything that changes your internal weather
feels like salvation.

Stimulants can feel like:

• movement

• focus

• purpose

• life returning

But when you use them just to survive the unbearable,
it stops being medicine
and becomes a lever.

And you keep pulling the lever
because the alternative is silence
and feeling everything.

How the injury reaches your marriage

This is the part that hurts most to write:

The injury didn’t just take work from me.
It took me from the people who loved me.

Because injury doesn’t only cause pain.
It causes:

• irritability

• hopelessness

• exhaustion

• shame

• withdrawal

• dependency

• identity collapse

And those don’t stay contained.
They spill—into conversations, trust, the emotional climate of a home.

Add sedation and chemical flattening on top of that,
and you don’t just struggle.

You become hard to live with.
Hard to reach.
Hard to recognize.

I believe—deeply—this is why
I don’t have my wife and son with me anymore.

And I hate that.

Not because it makes me look bad.
Because it cost me
the only things that mattered.

Two years away from the trade that made me proud

It’s been about two years since I worked in HVAC&R.

And that does something brutal to a person
who once took pride in competence.

The longer you’re away,
the harder it is to imagine going back.

You still have the Red Seal.
On paper, you’re qualified.

But confidence doesn’t live on paper.
Confidence lives in doing:

• daily reps

• small wins

• routine competence

• showing up

Without that,
your skills feel like they belong
to a past self you can’t reach.

And the loop becomes vicious:

You don’t go back because you lack confidence.
You lack confidence because you haven’t gone back.

The real haunting

What haunts me isn’t only the injury.

It’s realizing the injury
was the first domino.

And the rest of the dominoes
were my life.

I lost rhythm.
Contact.
Identity.
Family.

And I’m left with grief, guilt, and a question:

Was that version of me really me,
or what pain and medication did to me?

The answer is probably both.

Which is the hardest answer.

This isn’t a redemption post

If you’re expecting a tidy comeback,
a motivational ending,
a clean arc of rebuilding—

I don’t have it.

I’m writing from inside it.

What I do have is the truth:

Four months on the floor
didn’t just hurt my back.

It put me in psychological solitary confinement.
Changed my brain chemistry.
Changed my relationships.
Changed me.

And it’s haunted me ever since.

The only honest ending I can offer

I’m still here.

Not positivity.
Not a slogan.

Survival.

And maybe the smallest piece of hope is this:

The fact that I can name what happened
means the “zombie” part
isn’t permanent.

Monsters don’t tell the truth
about what they did.

They deny.
Blame.
Rationalize.

I’m not doing that.

I’m saying:

Pain, isolation, medication, and shame
turned me into someone I don’t recognize—

and I’m trying to find my way back.

Even if it feels far.
Even if I don’t know how yet.

The first post sounded clean. Cleaner than real life ever is.

Real life looked more like this:

Half-charged phone. Nowhere quiet. Body hurting in ways that don't show on the outside. Trying to remember dates and symptoms and conversations while your brain is busy just keeping you upright.

That's where this thing actually came from.

Not vision. Not ambition. Just the slow realization that if I didn't start writing things down, nobody would ever believe what was happening — and eventually I might not believe it either.

So I built something to remember for me.

Not in some company's cloud. Not behind a login I could lose. Just… here. On the device in my hand. Where nobody else gets to touch it unless I say so.

That decision wasn't technical. It was emotional. And honestly, a little paranoid. But the kind of paranoid you earn.

The part nobody puts in tech stories

Some of this code was written on days that had nothing to do with coding.

Days about court dates. Money stress. Places to sleep. Trying to stay steady enough to show up for my kid and not let him feel how close everything was to falling apart.

You don't think about architecture patterns in moments like that. You think about survival.

And weirdly… writing code helped. Because code is predictable. It either works or it doesn't. It doesn't gaslight you. It doesn't forget what you told it yesterday. It doesn't change the story halfway through.

Real life does.

So I kept coming back to the one place where cause and effect still made sense.

Why the privacy thing is so intense

People read "local-first" and think it's a design trend. It's not.

It's what happens when you've seen information move in directions you didn't choose and suddenly your own story isn't yours anymore.

Health data is the worst version of that. Because you can't change it. You can't rotate it like a password. Once it's out, it's out forever.

So yeah — I'm stubborn about it staying on the device.

Not because it's elegant. Because it feels safe. And safe is rare enough that you protect it hard.

The weird shift happening now

Something changed recently, and I don't totally know how to talk about it.

At first this was just… mine. A survival tool. Private. Small.

Now there's this quiet question sitting in the background:

What if other people actually need this?

That's heavier than building for yourself. Because if you screw up alone, it's just your problem. If someone else relies on it… different story.

So everything slows down. Decisions matter more. Shortcuts feel dangerous.

It stops being therapy through code and starts being responsibility.

I'm still getting used to that.

The one thing underneath all of it

There's a lot of complicated context around this project. Legal stuff. Housing stuff. Health stuff. History that doesn't fit nicely into a blog post.

But if I strip it down to the real core, it's simpler:

I have a son. He still looks at me like I'm supposed to be okay. Like I'm someone solid.

And when everything else felt unstable, building something real — something that worked — was one of the only ways to stay that person.

Not perfect. Just… still here.

So what does "after collapse" mean?

Not victory. Not some clean redemption arc. Life isn't a movie.

It just means this:

Things didn't end where they could have. Something useful came out of a period that mostly hurt. And the story kept moving instead of stopping.

That's it.

Nothing inspirational. Just true.

Pain Tracker — Private pain tracking that stays on your device. No cloud. No company. Just yours.

Shipping a health-adjacent tool is different from shipping a hobby app.

Reliability is part of care.

And when something breaks, the fix has to respect privacy while still being useful.

But “observability” in a privacy-first app must be handled carefully. The fastest way to betray trust is to quietly collect sensitive information in logs or analytics.

What you can observe without surveillance

A safe observability posture focuses on:

• app health (crashes, failed writes, migration failures)
• performance (slow screens, long operations)
• security-relevant events (without sensitive payloads)

And avoids:

• capturing raw notes
• capturing export content
• capturing entry payloads

Errors: make them useful, not revealing

Error handling should:

• show non-shaming messages
• preserve user work
• log only what you need to debug (operation name, error type, coarse counts)

If a log line could reconstruct a user’s health entry, it’s too detailed.

Analytics boundaries (if you ever add them)

In a privacy-first health context:

• default is no telemetry
• any analytics must be explicit opt-in
• analytics must be content-free (no Class A)

If you can’t describe the boundary clearly, don’t ship analytics.

Incidents: treat them as learning, not blame

An incident can be:

• data loss risk (migration bug)
• privacy risk (export confusion, unintended disclosure)
• reliability risk (save failures)

Small-team incident loop:

1) Triage: what happened and who is affected? 2) Contain: stop the bleeding (disable feature, add guardrails) 3) Recover: provide user-facing steps 4) Learn: add tests and update the checklist

Shipping quick check

1) Primary flows have explicit error states and recovery paths 2) Logs are redacted and non-reconstructive 3) No default telemetry; any analytics is opt-in and documented 4) A basic incident playbook exists 5) Releases are tested on at least one real device form factor

Next: Part 11 — From PWA to Native: When and How to Branch

Next, Part 11 defines when a PWA is enough and when native becomes worth it, plus how to structure code so you can branch without rewriting your product.

Private health tracking creates a paradox: you need privacy to track honestly, but you need to share data to benefit from clinical care. The resolution is not choosing between privacy and sharing—it is controlling the sharing process so that you decide what is shared, with whom, in what format, and for what purpose. PainTracker is designed around this principle of controlled disclosure.

Selective sharing means that different recipients get different views of your data. Your physiotherapist sees functional impact and exercise response data for the past month. Your prescriber sees medication-pain correlations over three months. Your insurance reviewer sees the WorkSafeBC-formatted timeline. None of them need or receive your complete unfiltered history.

Choosing what to share

Before exporting, consider what data is relevant to the recipient and purpose. For a medical appointment, include pain intensity trends, medication logs, functional impacts, and any patterns you have noticed. For an insurance claim, include timeline evidence, functional documentation, and treatment compliance records. For a second opinion, include a comprehensive summary.

Exclude entries that are irrelevant to the purpose. Personal notes, emotional processing, entries from unrelated health conditions, and data outside the relevant date range do not need to be in every export. PainTracker's selective export controls let you choose date ranges and data fields for each export independently.

Understanding export format security

Exported files—PDF, CSV, and JSON—are not encrypted by default. They are designed to be human-readable and clinically useful. This means that once you export a file, anyone with access to that file can read its contents. Treat exported pain reports with the same care you would give any medical document.

Do not email unencrypted exports over public Wi-Fi. Do not leave printed reports in shared spaces. Do not save exports to shared cloud drives unless you intend for others to access them. If you need to transmit data electronically, use a secure messaging platform or your clinic's patient portal if available.

Sharing with different stakeholders

For clinicians: print a PDF and bring it to your appointment, or share it through your clinic's secure patient portal. Doctors prefer PDF because it prints cleanly and can be added to your chart.

For insurance and WorkSafeBC: use the WorkSafeBC export template, which formats data according to documentation expectations. Share through the claims representative or your advocating lawyer, keeping a copy for your records.

For personal support (family, advocates): share only what you are comfortable sharing. A summary PDF covering a specific period may be appropriate. You are never obligated to share your complete tracking history with anyone.

Revoking and managing shared data

Once you share a file, you cannot revoke access—the recipient has a copy. This is why selective exports matter: share only what is appropriate for each situation, so that no single recipient receives more than they need.

Keep your own records of what you shared, with whom, and when. This audit trail helps you manage your health data disclosures over time and ensures you know exactly what information each provider or insurer has received. PainTracker's local-only architecture means your master copy always remains under your exclusive control.

Frequently Asked Questions

Can I share just part of my pain diary?

Yes. PainTracker's export controls let you select specific date ranges and data fields. You can create different exports for different recipients, sharing only what is relevant to each.

Are exported files encrypted?

No. Exported PDF, CSV, and JSON files are designed to be human-readable. Treat them as you would any medical document—handle and transmit them securely.

What is the safest way to send my pain report to a doctor?

The safest method is to print the PDF and hand it to your doctor in person. If electronic sharing is needed, use your clinic's secure patient portal or an encrypted messaging platform.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Recovery from injury is rarely linear. Pain levels fluctuate, good days alternate with setbacks, and progress can feel invisible when measured against yesterday. Structured tracking transforms this uncertain experience into a documented trajectory that shows real trends over time. When you look at a month of data, improvement that was invisible day-to-day becomes clear.

Recovery documentation also serves practical purposes. Insurance claims, return-to-work plans, and treatment justifications all require evidence of ongoing symptoms and functional progress. A structured pain diary created during recovery provides this evidence contemporaneously—far more credible than retrospective reports.

What to track during recovery

During recovery, track the basics—pain intensity, location, and quality—plus recovery-specific data: functional milestones (first day you could walk to the mailbox, first day you could work a full shift), activity tolerance (how long you can stand, sit, or drive before pain increases), and any setbacks (activities that caused regression, new symptoms, or flare-ups).

Medication changes are particularly important to document during recovery. As your condition improves, medication adjustments should be tracked alongside symptom levels to show whether improvements are genuine healing or simply better pain management. This distinction matters clinically and for insurance purposes.

Tracking non-linear progress

Recovery setbacks are normal and do not mean you are not healing. A week of increased pain after attempting a new activity does not erase months of progress—but without tracked data, it can feel that way. Your pain log provides objective evidence of your overall trajectory, helping you and your care team distinguish between temporary setbacks and genuine regression.

PainTracker's trend visualisations show your recovery arc: the overall trajectory from injury through healing, with flares and setbacks visible as temporary deviations from the improving baseline. This big-picture view is therapeutically valuable and clinically informative.

Documentation for return-to-work planning

Return-to-work planning requires evidence of functional capacity that goes beyond pain intensity numbers. Your employer, your doctor, and your WorkSafeBC representative all need to understand what you can and cannot do. Structured tracking of functional milestones, activity tolerance, and work-specific capacity provides this evidence in a format that all parties can interpret.

PainTracker's exports can document your functional progression alongside pain levels, showing reviewers that you are actively recovering and that your reported limitations are consistent with your daily tracking data. This consistency between self-report and tracked data strengthens your credibility throughout the return-to-work process.

When to stop tracking

There is no mandatory end date for recovery tracking. Some people stop when they feel their condition has stabilised. Others continue indefinitely because the data remains useful for managing residual symptoms or chronic pain. If your injury has resolved, you can export a final comprehensive report and stop tracking with confidence that your recovery is documented.

If symptoms persist beyond expected recovery timelines, your tracked data becomes invaluable. It documents the full timeline from injury through recovery plateau, providing your care team and insurers with evidence that ongoing symptoms are real, consistent, and documented from the beginning.

Frequently Asked Questions

When should I start tracking after an injury?

Start as soon as possible—ideally the day of injury. Early documentation establishes your baseline and creates a continuous record. PainTracker requires no setup time, so you can begin immediately.

Is it normal for recovery tracking to show ups and downs?

Yes. Recovery is rarely linear. Setbacks, flares, and daily fluctuations are normal. What matters is the overall trend over weeks and months, which PainTracker's trend visualisations make clear.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Physiotherapists assess treatment effectiveness through functional outcomes—what you can do, how much, and how pain responds to activity. A pain log that captures only intensity misses the functional context that PTs rely on. Recording what activities you attempted, how your pain responded, and whether prescribed exercises helped or worsened symptoms gives your physiotherapist the data they need to adjust your treatment plan.

PTs also use between-session data to monitor compliance with home exercise programs. If your physiotherapist prescribed daily stretches and your log shows consistent tracking alongside those exercises, it demonstrates engagement and provides objective data about whether the program is working.

Tracking exercise response

Record your pain levels before and after prescribed exercises. Note which exercises you completed, any modifications you made, and whether specific movements consistently worsen or improve symptoms. This exercise-response data is extraordinarily valuable for PTs: it shows not just whether you are doing the exercises, but how your body responds to them.

PainTracker's notes and tags fields let you annotate entries with exercise details. Over several sessions, patterns emerge: certain exercises may consistently reduce pain, while others may need modification. This data helps your PT fine-tune your program without waiting for you to recall details during an appointment.

Functional impact documentation

Document what you could and could not do each day. How long could you sit before pain increased? Could you lift, carry, or reach without aggravation? Did pain affect your sleep, driving, or household tasks? This functional data is what physiotherapists use to assess whether treatment is producing real-world improvements.

Functional progress may be invisible to intensity scores alone. You might rate your pain as the same 5 out of 10, but now you can sit for two hours instead of thirty minutes. Recording both intensity and function captures the full picture of your recovery trajectory.

Preparing your export for PT appointments

Before your physiotherapy appointment, export a report covering the period since your last visit. PainTracker's PDF export provides the summary statistics and trend charts that give your PT an instant overview. Highlight any changes in pain patterns, functional improvements or declines, and your response to prescribed exercises.

Bring the report printed or on your phone. Start the session by handing it to your physiotherapist with a brief verbal summary: "Pain has decreased on average since we started the new exercises, but I am still getting sharp pain in the left shoulder when I reach overhead." This combination of structured data and specific verbal context makes the appointment more productive.

Long-term PT outcome tracking

Physiotherapy courses often span weeks to months, and progress can be gradual. Daily tracking creates a continuous record that shows improvement trends even when individual appointments feel similar. Reviewing three months of data might reveal that your average pain has decreased from 6 to 4, your functional capacity has doubled, and flare frequency has halved—improvements that are obvious in data but imperceptible day to day.

This longitudinal evidence is also valuable for insurance claims and workplace return-to-work planning. Documented functional improvement supported by consistent data strengthens the case for ongoing treatment when coverage is reviewed.

Frequently Asked Questions

Should I track pain during physiotherapy exercises?

Yes. Recording pain before, during, and after exercises helps your PT assess whether specific movements are therapeutic or aggravating. Use PainTracker's notes field to record exercise-specific observations.

How do I share my PainTracker data with my physiotherapist?

Export a PDF report covering the period since your last appointment. Print it or show it on your phone at the start of your session. PainTracker's export format is designed for clinical readability.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

WorkSafeBC claims depend on documented evidence linking a workplace injury to ongoing symptoms and functional limitations. Without structured, consistent documentation, claims reviewers have only sporadic medical records and verbal statements to work with. A structured pain diary that tracks daily symptoms from the date of injury provides the continuous timeline evidence that strengthens claims and accelerates processing.

Claims that include structured symptom documentation alongside medical records are easier for adjudicators to evaluate. The documentation shows that symptoms are ongoing, that you are actively managing your condition, and that the functional limitations you report are consistent with your daily tracking data.

What to track for a WorkSafeBC claim

For WorkSafeBC documentation, focus on: daily pain intensity at the injury site, functional limitations affecting your work capacity, medications taken and their effectiveness, treatments attended (physiotherapy, specialist appointments), and any changes in your condition over time. PainTracker's structured entry fields capture all of these through quick, consistent daily logging.

Be factual and specific. Record what you can and cannot do, not how frustrated you are. Note specific work activities you were unable to perform, how long you could sit or stand, whether you could drive, and any modifications your employer provided. This concrete functional data is what WorkSafeBC reviewers examine most carefully.

Start tracking immediately after injury

Begin tracking on the day of your injury or as soon as possible afterward. Early documentation establishes the baseline and creates a continuous record from injury through recovery. Gaps in documentation can be interpreted as gaps in symptoms—even when they simply reflect a period when you were too overwhelmed to track.

PainTracker requires no setup time. Install the app, set your passphrase, and log your first entry in under two minutes. There is no account creation, no forms to fill out, and no waiting period. This zero-friction start is especially important in the aftermath of an injury when your capacity is reduced.

Using PainTracker exports for your claim

PainTracker includes export templates designed for WorkSafeBC documentation requirements. The export organises your data into a timeline showing symptom progression from injury date, consistent documentation of pain levels and functional limitations, medication management records, and treatment compliance evidence.

Share exports with your claim representative, your treating physician, and any specialists involved in your care. Each can add PainTracker's structured data to their own documentation, creating a consistent narrative across all the records associated with your claim.

Privacy protection during claims

Workers' compensation claims involve sharing health data with your employer's insurer—a context that requires careful privacy management. PainTracker's selective export controls let you include only data relevant to your workplace injury. Your complete tracking history, including entries unrelated to the claim, remains private on your device.

Because PainTracker stores data locally with no cloud backup, there is no company database that an employer or insurer can subpoena for your complete records. You control exactly what information enters your claims file, sharing only what supports your claim through deliberate, user-initiated exports.

Frequently Asked Questions

Will WorkSafeBC accept PainTracker reports as evidence?

PainTracker exports provide structured, timestamped documentation that supports your claim alongside medical records. The data format aligns with what WorkSafeBC reviewers expect to see in symptom documentation.

Can my employer access my PainTracker data?

No. Your data is encrypted on your personal device. There is no server or database to access. You control what is shared through selective exports.

How far back should I track for a WorkSafeBC claim?

Start tracking from the date of injury and continue throughout your claim and recovery. Continuous documentation from injury date forward provides the strongest evidence of ongoing symptoms and functional limitations.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

PainTracker is a Progressive Web App that installs directly from your browser—no app store required, no account needed. Visit paintracker.ca/app in Chrome, Safari, Edge, or Firefox on any device. On mobile, tap the browser's "Add to Home Screen" option. On desktop, click the install icon in the address bar. The app downloads to your device and works offline immediately.

There is no registration, no email verification, and no terms-of-service agreement for your data. You set a passphrase that encrypts your entries, and you are ready to start tracking. The entire setup takes under sixty seconds.

Set your passphrase

Your passphrase encrypts all health data stored on your device. Choose something memorable but not easily guessable—at least four random words or twelve characters. This passphrase is never sent anywhere and cannot be recovered if lost. Write it down and store it securely if you are concerned about forgetting it.

The passphrase is your only key. Without it, your data is permanently inaccessible—by design. This zero-knowledge approach means no one can access your records without your explicit authorisation.

Log your first pain entry

The entry interface is designed for speed and simplicity. Slide to set your pain intensity on the 0–10 scale. Tap the body map to mark pain locations. Select quality descriptors that match your experience—aching, burning, stabbing, throbbing, or others. Add optional notes if you want to capture context.

Your first entry establishes your baseline. Do not overthink it—record what you feel right now. Consistency matters more than precision. The structured inputs ensure that every entry is comparable to every other entry, building a dataset that reveals patterns over time.

Build your first week of data

Commit to logging one entry per day for your first week. Anchor it to an existing routine—after morning medication, before bed, or at a consistent break time. The goal is to establish the habit. After seven days, you will have enough data to see your first patterns in the analytics view.

On high-pain days, the minimal entry path—a single slider adjustment—takes seconds. On better days, add medication details, functional impact notes, and tags. Both levels of detail are valuable: the key is that you logged something every day.

Explore your analytics

After several entries, visit the analytics view to see your data visualised. Trend charts show pain intensity over time. Time-of-day breakdowns reveal whether mornings or evenings are worse. Body map heatmaps show your most common pain locations. All analysis happens locally on your device—nothing is sent to any server.

These early analytics are just the beginning. As your dataset grows over weeks and months, patterns become clearer: seasonal variations, medication correlations, trigger relationships, and recovery trajectories all emerge from consistent tracking.

Export your first report

After your first week, try exporting a report. Choose PDF for a clinical-ready document, CSV for raw data, or JSON for a complete backup. The export process runs entirely in your browser—nothing leaves your device until you choose to share the file.

Bring a printed report to your next medical appointment. Even a week of structured data gives your clinician more to work with than verbal recall. As your tracking history grows, your exports will become increasingly valuable clinical documents.

Steps

Step 1: Install the app

Visit paintracker.ca/app and use "Add to Home Screen" on mobile or the install icon on desktop.

Step 2: Set your passphrase

Choose a strong, memorable passphrase that encrypts all your health data locally.

Step 3: Log your first entry

Use the slider for intensity, tap the body map for location, and select pain quality descriptors.

Step 4: Track daily for one week

Log at least one entry per day at a consistent time to establish your tracking habit and baseline data.

Step 5: Review analytics and export

View your trends in the analytics dashboard, then export a PDF report for your next appointment.

Frequently Asked Questions

Do I need to create an account to use PainTracker?

No. PainTracker requires no account, email, or personal information. You set a passphrase to encrypt your data, and that is the only setup required.

What devices does PainTracker work on?

PainTracker works on any device with a modern web browser: iPhones, Android phones, iPads, tablets, laptops, and desktop computers. It installs as a Progressive Web App from your browser.

Can I use PainTracker without an internet connection?

Yes. After the initial installation, PainTracker works entirely offline. All features—entry logging, analytics, exports—function without any internet connection.

What if I forget my passphrase?

Your passphrase cannot be recovered because it is never stored or transmitted. If you forget it, your encrypted data is permanently inaccessible. Write it down and store it securely.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Privacy claims are only as trustworthy as their verifiability. When a health app says "your data is encrypted" or "we never share your information," you are trusting a marketing statement. When the app is open source, you can verify those claims yourself—or rely on the broader community of developers, security researchers, and privacy advocates who review the code.

PainTracker chose open source specifically because health data privacy claims should be verifiable, not aspirational. The code that encrypts your data, the code that does not phone home, the code that stores nothing on the server—all of it is publicly readable. Trust is earned through transparency, not asserted through policy.

Community security review

Open-source software benefits from many-eyes review. Security vulnerabilities, privacy violations, and implementation errors can be identified by anyone with the skills to read code. For a health application handling sensitive data, this community oversight is a significant advantage over closed-source alternatives where security depends entirely on the company's internal practices.

The open-source model does not guarantee that every line of code has been reviewed—but it makes review possible. Security researchers who specialise in health applications, privacy advocates, and other developers can and do examine the codebase. Any findings can be reported publicly, creating accountability that closed-source apps lack.

Long-term sustainability and data safety

Health data may remain relevant for decades. A closed-source app that shuts down takes your data access with it—or worse, sells your data as a business asset. Open-source software cannot be permanently killed: the code remains available for anyone to run, modify, or maintain, regardless of what happens to the original maintainers.

If PainTracker ever stops active development, your data is safe. The code remains public and forkable, the data format is documented, and the export tools continue to function. This structural guarantee of long-term data access is something that no closed-source health app can provide.

Contribution and community involvement

Open source means that users are not just consumers—they can be contributors. Feature requests, bug reports, accessibility improvements, and even direct code contributions from the community make the application better for everyone. For a health tool, community involvement ensures that diverse needs and perspectives shape the product.

PainTracker welcomes contributions in code, documentation, translation, accessibility testing, and security review. Every contribution makes the tool more robust, more inclusive, and more trustworthy. The project's Code of Conduct ensures that community interactions reflect the same respect and care that the application itself embodies.

Open source does not mean insecure

A common misconception is that publishing source code makes software less secure by revealing vulnerabilities to attackers. In practice, the opposite is more often true: security through obscurity provides weak protection, while transparent security implementations invite review, improvement, and community-driven hardening.

PainTracker's security relies on standard cryptographic algorithms and defence-in-depth architecture—not on keeping the implementation secret. The encryption is strong because the algorithms are strong, not because no one can see the code. This is a well-established principle in security engineering, and it applies with full force to health applications.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

People who most need pain tracking tools are disproportionately likely to have accessibility needs. Chronic pain conditions frequently co-occur with mobility impairments, visual difficulties, cognitive fog, and fatigue—all of which affect how someone interacts with digital tools. An inaccessible pain tracker excludes exactly the people it is designed to serve.

Accessibility is not an add-on feature or a compliance checkbox. It is a design commitment that shapes every interaction, from the size of touch targets to the language used in error messages. PainTracker treats accessibility as a first-class constraint: features are not shipped until they meet accessibility standards.

WCAG 2.2 AA: what it means in practice

PainTracker targets Web Content Accessibility Guidelines (WCAG) 2.2 at the AA conformance level. In practical terms, this means: all interactive elements are keyboard accessible, visual content meets minimum contrast ratios, touch targets are large enough for users with motor impairments, screen readers can navigate and interpret all content, and time-sensitive interactions provide sufficient time for all users.

Beyond technical compliance, WCAG 2.2 introduced criteria particularly relevant to pain tracking: minimum target sizes for touch inputs, focus appearance requirements for keyboard navigation, and accessible authentication flows. PainTracker's passphrase entry and daily tracking interface are designed to meet these updated standards.

Trauma-informed design principles

Chronic pain is frequently associated with trauma, and pain tracking can itself be emotionally challenging—requiring daily engagement with one's own suffering. PainTracker's trauma-informed design philosophy addresses this through several concrete practices: using gentle, non-judgmental language throughout the interface; providing user control over the tracking experience; reducing cognitive load through structured inputs; and offering quick exit mechanisms.

Error messages never blame the user. The interface does not pressure completion. Every interaction is designed with the understanding that the person using the app may be experiencing significant pain, distress, or fatigue at that moment. This is not just good UX—it is ethical design for a health tool.

Designing for reduced capacity

Pain flares reduce cognitive capacity, motor control, and tolerance for complexity. A pain tracker that is only usable on good days fails at its core purpose. PainTracker's interface is designed for worst-case capacity: large touch targets, minimal required interactions, clear visual hierarchy, and a one-swipe minimal entry path that captures essential data when you cannot manage more.

The application adapts to user preferences for text size, colour contrast, and motion sensitivity. These are not cosmetic settings—they are functional accommodations that determine whether the app is usable during a severe flare. Respecting the user's system-level accessibility preferences (reduced motion, high contrast, large text) is a baseline requirement.

Inclusive design as a competitive advantage

Accessible design benefits all users, not just those with identified disabilities. Larger touch targets are easier for everyone to use on a bumpy bus. Clear language helps everyone understand the interface faster. Keyboard navigation supports power users and users with temporary injuries alike.

For PainTracker, accessibility and privacy are both expressions of the same core value: respect for the user. Respecting someone's privacy means not taking their data without consent. Respecting someone's accessibility needs means not building tools they cannot use. Both are non-negotiable commitments, not feature requests.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

A threat model identifies who might want access to your data, how they might get it, and what protections are in place. For health data—especially chronic pain records that may affect employment, insurance, and legal matters—understanding threats is not paranoia; it is practical risk management. Different people face different threats, and security measures should match actual risks.

PainTracker's security architecture is designed around a specific threat model. Being transparent about what we protect against—and what we do not—helps you make informed decisions about whether our approach matches your needs.

Threat: data breaches and server compromise

Health data breaches are frequent and devastating. Once exposed, health information cannot be changed like a credit card number—your medical history is permanently compromised. Cloud-based health apps store data on servers that are attractive targets for attackers, and even well-funded healthcare organisations suffer breaches regularly.

PainTracker's defence: there is no server-side health data to breach. The server delivers static application code and has no database, no user data, and no API endpoints that receive health information. The attack surface for health data is reduced to zero at the server level.

Threat: employer or insurer access

Workers documenting injuries for compensation claims face a specific threat: employers or their insurers may seek access to health records to dispute claims. With cloud-based apps, a legal request to the app company could potentially expose your entire tracking history—including entries unrelated to the workplace injury.

PainTracker's defence: there is no company database to subpoena. Your data exists only on your device, encrypted with your passphrase. No legal process can compel PainTracker's developers to hand over data they do not possess. You control what is shared through selective exports.

Threat: device loss or theft

If your phone or computer is lost or stolen, someone gaining physical access to your device could potentially access your browser storage. This is a real threat that requires application-level protection beyond device security.

PainTracker's defence: all health data is encrypted at rest using your passphrase-derived key. Even with full physical access to the device and its storage, an attacker cannot read your pain entries without your passphrase. The encryption uses standard algorithms that resist brute-force attacks.

Threat: coercive situations and surveillance

Some patients track pain in situations where others—a controlling partner, an intrusive employer, a family member—monitor their digital activity. The mere visibility of a pain tracking app can be problematic in coercive domestic situations.

PainTracker's defence: panic mode allows quick dismissal of the application without leaving visible traces. The app runs as a Progressive Web App that can be named anything on the home screen. There are no push notifications that reveal pain tracking activity, no email receipts, and no calendar integrations that could expose health information through shared accounts.

Threats we do not fully address

Honest security requires acknowledging limitations. PainTracker cannot protect against a compromised operating system or malware with root access—these threats operate below the application layer and can intercept any data the browser processes. We cannot protect against physical coercion where someone forces you to reveal your passphrase. We cannot prevent a compromised browser from intercepting data before encryption.

If you face these specific threats, additional measures beyond any single application are necessary: full-disk encryption, dedicated secure devices, and operational security practices. PainTracker provides strong protection within the browser application layer but is transparent about threats that require system-level defences.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Local-only encryption means your data is encrypted and decrypted entirely within your browser, using keys that never leave your device. Unlike server-side encryption—where a company holds the keys and can decrypt your data—local-only encryption ensures that only someone with your passphrase can read your records. The application developer, the hosting provider, and anyone who might access the server infrastructure cannot decrypt your health data.

This is sometimes called "client-side encryption" or "zero-knowledge encryption." The key distinction is who controls the decryption key: you do, and only you. There is no "forgot password" recovery because there is no server-side copy of your key to recover.

How the encryption process works

When you set up PainTracker, you choose a passphrase. This passphrase is processed through a key derivation function that produces a cryptographic key. The derivation function is deliberately slow—it requires significant computation—which makes brute-force guessing attacks impractical even if someone extracts the encrypted data from your device.

Each time you enter a pain record, the application encrypts the entry using this derived key before writing it to IndexedDB. When you view your data, the application decrypts entries on the fly using the same key, which exists only in memory during your active session. When you close the app or lock it, the key is cleared from memory.

The Web Crypto API provides the underlying cryptographic operations. This is a browser-native library maintained by browser vendors and audited by security researchers worldwide. PainTracker uses standard algorithms through this API rather than implementing custom cryptographic code—a critical best practice in security engineering.

Why passphrase strength matters

Your encryption is only as strong as your passphrase. A short or common passphrase can be guessed through dictionary attacks, even with a slow key derivation function. Choose a passphrase that is long (at least four random words or twelve characters), unique (not reused from other accounts), and memorable to you but not guessable by someone who knows you.

PainTracker cannot enforce passphrase strength without storing information about your passphrase, which would compromise the zero-knowledge guarantee. The responsibility for passphrase quality rests with you—but the reward is genuine cryptographic protection that no policy or promise can provide.

What encryption does and does not protect

Local encryption protects against: unauthorized access to your stored data if your device is lost, stolen, or accessed by someone without your passphrase; extraction of readable health data from browser storage; and forensic recovery of health records from your device's storage.

Local encryption does not protect against: someone who knows your passphrase, malware or keyloggers that capture your passphrase as you type it, a compromised operating system that can read application memory, or a compromised browser that can intercept data before encryption. These are operating-system-level threats that no application can fully defeat.

Verifying the encryption yourself

PainTracker is open source, which means you—or a security professional you trust—can inspect the encryption implementation directly. The code that derives keys, encrypts data, and manages the encryption lifecycle is visible in the public repository. This transparency ensures that the encryption claims are verifiable rather than aspirational.

For users without technical background, the open-source nature provides indirect verification: security researchers, privacy advocates, and other developers can and do review the code. Any vulnerability or deviation from claimed security properties can be identified and reported publicly.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

PainTracker's security architecture is built on one principle: your health data should never exist anywhere you do not control. This means no server-side data storage, no remote databases, no cloud backups, and no analytics pipelines that touch health information. Every security decision flows from this principle—and every feature is evaluated against it before implementation.

The architecture follows a defence-in-depth model: multiple independent layers of protection so that no single failure compromises your data. Client-side encryption, Content Security Policy, secure storage isolation, session management, and minimal attack surface work together to provide comprehensive protection.

Client-side encryption

All health data is encrypted in your browser before being written to storage. PainTracker uses the Web Crypto API—a standardised browser cryptographic library—with keys derived from your passphrase through a key derivation function. The encryption key exists only in memory during your active session and is never persisted to storage.

This approach means that even if someone extracts the raw IndexedDB data from your device, they see only encrypted blobs. Without your passphrase, the data is computationally infeasible to decrypt. The encryption implementation is open source, auditable, and uses standard algorithms rather than custom cryptographic code.

Zero-knowledge architecture

Zero-knowledge means the application operator has no ability to read your data, even in principle. PainTracker's server serves static application files—HTML, CSS, JavaScript—and has no database, no API endpoints that accept health data, and no mechanism to receive information from your browser beyond standard web requests for application code.

There are no user accounts, no authentication tokens, and no session identifiers that link server requests to individual users. The server cannot distinguish between different users, much less access their encrypted health data. This is a structural guarantee, not a policy promise.

Content Security Policy and XSS prevention

PainTracker implements a strict Content Security Policy (CSP) that restricts which scripts can execute, which resources can be loaded, and which connections can be made. This mitigates cross-site scripting (XSS) attacks—a common web vulnerability that could theoretically be used to extract data from the browser.

The CSP configuration blocks inline scripts, restricts resource loading to known origins, and prevents the application from making unexpected network connections. Combined with secure coding practices and regular dependency auditing, this creates a hardened client-side environment that resists common web attack vectors.

Threat model and honest limitations

PainTracker defends against realistic threats: lost or stolen devices (at-rest encryption), XSS attacks (CSP plus secure coding), malicious browser extensions (limited plaintext exposure), shoulder-surfing (panic mode, minimal visible data), and coercive access attempts (user-controlled data, quick dismissal).

We do not claim to protect against compromised operating systems, root-level malware, hardware keyloggers, or physical coercion beyond in-app safety controls. No application-level security can defeat an adversary who controls the OS. Honest threat modelling means being transparent about what we protect against and what we do not.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Choosing a pain tracking app involves balancing several competing priorities: clinical utility, privacy protection, ease of use, offline capability, and long-term data ownership. Most apps excel at one or two of these while neglecting the others. Understanding your own priorities—whether privacy is non-negotiable, whether you need offline access, whether clinical export formats matter—helps narrow the field.

The most important question to ask any pain app is: where does my data go? Cloud-based apps store your health data on remote servers. Local-only apps keep everything on your device. Hybrid apps may store locally but sync or back up to the cloud. Each model carries different privacy implications that should inform your choice.

Common features across pain tracking apps

Most pain tracking apps offer core features: a numerical pain scale (usually 0–10), body location mapping, symptom quality descriptors, medication logging, and some form of trend visualisation. The differences lie in implementation quality—how quickly you can complete an entry, how clinically useful the exports are, and how well the app handles edge cases like flare days when your capacity is minimal.

More advanced features include weather correlation, mood tracking, sleep integration, clinical-grade export formats, and pattern analysis. PainTracker provides all of these while maintaining local-only data storage—a combination that most competitors do not offer.

Privacy as a differentiator

Privacy is where pain tracking apps diverge most significantly. Many popular apps collect analytics, require account creation, and store data on company servers. Some share data with third parties for research or advertising purposes—practices that may be disclosed in lengthy terms of service but are rarely highlighted to users.

PainTracker is built on a zero-knowledge architecture: no accounts, no servers receiving health data, no analytics collecting personal information, and no third-party SDKs with access to your entries. This approach is architecturally different from adding a "privacy mode" to a cloud app—when there is no server-side data store, there is nothing to breach, subpoena, or monetise.

Offline capability comparison

True offline capability means every feature works without an internet connection—not just data entry, but analytics, exports, and visualisations. Many apps that claim offline support actually require connectivity for key features or periodically sync data to servers in the background.

PainTracker is a Progressive Web App that functions entirely offline after installation. Entry logging, trend analysis, pattern recognition, and PDF/CSV/JSON export all run locally in your browser. This is not a degraded offline mode—it is the app's primary operating mode. Internet connectivity is only needed for the initial installation and subsequent code updates.

Clinical utility and export quality

An app's clinical value is largely determined by its export quality. Can you produce a report that a doctor will actually read and use? Apps that export only raw data or app-specific formats create extra work for clinicians. PainTracker's PDF exports follow clinical documentation conventions, with summary statistics, trend charts, and structured entries formatted for professional medical contexts.

WorkSafeBC-specific templates, medication response summaries, and functional impact reports set PainTracker apart for Canadian patients navigating healthcare and insurance systems. The exports are designed by studying what clinicians and claims reviewers actually need, not what looks good in a marketing screenshot.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Paper diaries have genuine advantages: they require no technology skills, no device, and no battery. For patients who are uncomfortable with technology or who find screens distressing during high-pain periods, paper remains a viable tracking method. There is no learning curve, no account creation, and no risk of data loss from software bugs or device failure.

Paper also offers unrestricted flexibility. You can draw, annotate, use your own shorthand, and organise entries however makes sense to you. For creative or visually-oriented patients, this freedom can make tracking feel more personal and less clinical.

The clinical limitations of paper

Despite its accessibility, paper has significant clinical limitations. Research on pain diaries has consistently shown that paper diary compliance is poor: patients frequently backfill entries days or weeks later, often just before an appointment. This retrospective entry defeats the purpose of contemporaneous tracking and produces data that is no more accurate than simple recall.

Paper diaries also resist analysis. A doctor reviewing handwritten notes must read through every entry to identify trends—a task that is impractical in a fifteen-minute appointment. There are no summary statistics, no trend charts, and no easy way to compare one month to another. The data exists but is locked in a format that resists clinical interpretation.

Advantages of app-based tracking

Digital pain diaries address paper's core weaknesses. Timestamped entries prevent backfilling. Structured inputs ensure consistent data capture. Automatic trend calculation and visualisation make patterns visible at a glance. Export tools produce professional reports that clinicians can review efficiently.

Apps also reduce tracking burden. A slider is faster than writing a number. A body map tap is more precise than describing location in words. Structured quality descriptors eliminate the challenge of finding the right vocabulary during a flare. PainTracker is designed so that a minimal daily entry requires no typing and fewer than four interactions.

Privacy comparison

Paper diaries are inherently private—they exist only as physical objects under your control. However, they can be discovered, read by anyone with physical access, and are not encrypted or protected in any way. A paper diary left in a bag, on a desk, or in a waiting room is immediately readable.

PainTracker provides stronger privacy through device-level encryption with passphrase protection. Even if someone accesses your device, your pain entries remain encrypted and unreadable without your passphrase. The trade-off is that this protection depends on technology rather than physical custody—but for most people, encrypted digital storage is more secure than an unlocked notebook.

Making the right choice

For patients who are comfortable with basic smartphone or computer use, an app-based diary provides better clinical data, higher compliance, stronger privacy, and richer analytical capabilities. For patients who genuinely cannot or prefer not to use technology, a structured paper template is better than no tracking at all.

Some patients benefit from a hybrid approach: using a paper template for daily capture and periodically entering the data into PainTracker for analysis and export. This combines the tactile simplicity of paper with the analytical power of structured digital data. The important thing is to track consistently, using whatever method you will actually maintain.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Human memory is poorly suited to identifying correlations across multiple variables over time. When you experience a pain flare, you naturally look for an immediate cause—but many triggers operate with a delay of hours or days. Weather changes may precede flares by 24 hours. Sleep disruption may not affect pain levels until the second night. Stress accumulates before manifesting physically. These delayed relationships are nearly invisible to retrospective recall.

Confirmation bias compounds the problem. Once you believe something is a trigger, you notice it before every flare and overlook the times it occurred without consequences. Structured tracking bypasses both limitations by recording potential triggers consistently, regardless of whether a flare follows, creating a dataset that reveals genuine correlations while filtering out coincidences.

Common pain triggers worth tracking

The most frequently identified pain triggers across chronic pain conditions include: physical overexertion, prolonged static postures (sitting, standing), sleep disruption or insufficient sleep, emotional stress, weather changes (barometric pressure drops, temperature shifts, humidity), dietary factors (alcohol, specific foods), hormonal fluctuations, and illness or infection.

PainTracker lets you record these potential triggers through tags, structured fields, and notes alongside your daily pain entries. The key is consistency: record the same trigger categories every day, not just on days when you think they might be relevant. This creates the complete dataset needed for meaningful correlation analysis.

Systematic trigger investigation

Rather than tracking everything simultaneously, investigate triggers systematically. Start with two or three candidate triggers based on your clinical suspicion and track them consistently for four to six weeks. Then review the data: do high-pain days consistently follow days with the suspected trigger? Is the relationship statistically meaningful or just occasional?

PainTracker's local analytics can help visualise these correlations on your device. Weather data integration shows barometric pressure alongside your pain entries. Time-of-day analysis reveals whether morning, afternoon, or evening pain dominates. Activity-pain correlation views show whether busy days predict worse pain the next day.

Weather as a pain trigger

The relationship between weather and pain is widely reported by patients but inconsistently supported by population-level research—likely because the relationship varies significantly between individuals. Some people are sensitive to barometric pressure changes, others to temperature, and many to combinations that are unique to their condition.

PainTracker integrates local weather data to automatically correlate your pain entries with barometric pressure, temperature, and humidity. This person-specific analysis can confirm or rule out weather sensitivity for you individually—a much more useful result than population-level studies that average across different sensitivities.

Using trigger data for proactive management

Identified triggers are actionable. If prolonged sitting consistently precedes higher pain, you can schedule movement breaks. If barometric pressure drops predict flares, you can pre-medicate or adjust your schedule on forecast-change days. If poor sleep reliably increases next-day pain, sleep hygiene becomes a concrete pain management intervention rather than generic lifestyle advice.

Share your trigger findings with your care team. A clinician who knows that your flares follow a specific pattern can tailor treatment recommendations, suggest targeted interventions, and help you develop a proactive management plan based on your personal trigger profile rather than generic guidelines.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Chronic illness flare-ups often feel unpredictable—sudden escalations of symptoms that disrupt daily life without obvious cause. But research and clinical experience show that most flares have identifiable triggers or precursors, and consistent symptom tracking is the most reliable way to find them. What feels random in the moment often reveals patterns when viewed across weeks or months of data.

A flare is not a single data point—it is a pattern of elevated symptoms over hours or days, often preceded by warning signs and followed by a recovery period. Tracking the full arc of a flare—onset, peak, duration, recovery—provides richer clinical information than recording only the worst moment.

Documenting flare severity and duration

Consistent severity measurement during flares is critical for comparing one flare to another. Was this flare worse than last month's? Longer? More disabling? Without structured tracking, these comparisons rely on memory, which is unreliable during periods of high pain and distress. PainTracker's daily intensity recording creates a continuous timeline that makes flare comparison objective.

Duration matters as much as peak severity for clinical assessment and self-management. A flare that peaks at intensity 8 but resolves in two days may be less functionally disabling than one that peaks at 6 but persists for two weeks. Recording daily data through flares captures both dimensions.

Identifying flare triggers

Common flare triggers include physical overexertion, sleep disruption, emotional stress, weather changes, dietary factors, hormonal fluctuations, and illness. The challenge is that triggers often precede flares by one or two days, making the connection invisible without tracked data that you can review retrospectively.

PainTracker's tagging and notes system lets you record potential triggers alongside your daily entries. After several flares, review the days preceding each one: what activities did you do, what was the weather, how did you sleep, what was your stress level? Patterns typically emerge within two to three months of consistent tracking.

Flare management and pacing

Once you identify your triggers, tracking supports proactive flare management. If you know that exceeding a certain activity level reliably triggers a flare two days later, you can pace your activities accordingly. If weather changes are a consistent trigger, you can pre-medicate or adjust your schedule. Data transforms reactive suffering into proactive management.

Tracking also supports pacing—the practice of balancing activity and rest to avoid the boom-bust cycle common in chronic illness. By recording activity levels alongside symptoms, you can identify your sustainable activity threshold and learn to stay within it most of the time.

Communicating flare patterns to your care team

When you can show your doctor a three-month timeline with flare events marked—including triggers, severity, duration, and treatment response—the clinical conversation becomes much more productive. Instead of describing flares verbally, you are presenting objective data that supports treatment decisions.

PainTracker's export tools let you create reports that highlight flare periods within the broader context of your daily tracking. This contextualised view shows your care team not just what happens during flares, but what your baseline looks like, how quickly you recover, and whether flare frequency is changing over time.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Migraine management relies heavily on pattern recognition. Attack frequency, duration, severity, associated symptoms, and treatment response are all data points that guide clinical decisions about preventive medications, acute treatments, and lifestyle modifications. Without consistent tracking, both you and your neurologist are making decisions based on incomplete and potentially inaccurate recall.

A migraine diary also provides critical evidence for diagnosis. The International Classification of Headache Disorders uses attack frequency, duration, and symptom characteristics to distinguish migraine subtypes and differentiate migraine from other headache disorders. Structured tracking data supports accurate diagnosis and appropriate treatment.

What to track for migraine management

For each migraine attack, record: onset time, pain intensity at peak, pain location (unilateral vs bilateral, specific areas), associated symptoms (nausea, photophobia, phonophobia, aura), duration until resolution, and acute medications taken with their timing and effectiveness. PainTracker's structured inputs capture all of these through taps and selections rather than free-text entry.

Between attacks, track potential triggers: sleep patterns, dietary factors, weather changes, hormonal timing, stress levels, and physical activity. Consistent inter-attack tracking is what reveals trigger patterns—information that is nearly impossible to identify retrospectively. A month of daily tracking typically reveals two or three triggers that you can then systematically test and manage.

Monitoring medication effectiveness

Preventive migraine medications can take weeks or months to show full effect, and subtle changes in attack frequency or severity may be imperceptible without tracking data. A structured diary that records attacks alongside medication history provides the objective before-and-after comparison that you and your prescriber need to assess whether a treatment is working.

Acute medication tracking is equally important. Recording what you took, when you took it relative to attack onset, and how effectively it relieved symptoms helps optimise your acute treatment strategy. Many patients discover through tracking that they are consistently medicating too late for optimal effectiveness—a pattern that is easy to correct once identified.

Recognising warning signs and patterns

Many migraineurs experience prodromal symptoms—mood changes, food cravings, neck stiffness, yawning—hours or days before an attack. Tracking these pre-attack symptoms alongside attacks can help you recognise warning signs earlier, potentially allowing pre-emptive treatment or activity modification.

Seasonal patterns, menstrual cycle correlations, and weather-related triggers also emerge from longitudinal tracking. PainTracker's local analytics can highlight these temporal patterns without sending your sensitive health data to any server—an important consideration when tracking involves hormonal and mental health data.

Sharing migraine data with your neurologist

Neurologists managing migraine patients want concise, structured data: attack frequency per month, average severity, medication use patterns, and any changes in headache characteristics. PainTracker's PDF export provides this clinical summary along with trend charts that show attack patterns over time.

If you are being evaluated for chronic migraine (fifteen or more headache days per month), a detailed diary is not just helpful—it is diagnostically necessary. Three months of consistent tracking provides the evidence your neurologist needs to confirm diagnosis, justify treatment changes, or support referrals to headache specialty centres.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.

Fibromyalgia is more than a pain condition. The diagnostic criteria explicitly include widespread pain, fatigue, sleep disturbance, and cognitive difficulties. Tracking only pain intensity misses at least half of the clinical picture. Effective fibromyalgia management requires a multi-dimensional tracking approach that captures the full symptom constellation.

PainTracker's structured entry system supports this multi-symptom approach. Beyond the core pain fields—intensity, location, quality—you can use tags and notes to consistently record fatigue levels, sleep quality, cognitive fog severity, and other symptoms relevant to your specific fibromyalgia presentation. This comprehensive data gives your rheumatologist or pain specialist the full picture they need.

Tracking widespread pain with body mapping

Fibromyalgia pain is characteristically widespread and often migratory—it may be concentrated in different areas on different days. The body map in PainTracker lets you record exactly where pain is located each day, building a visual history that shows distribution patterns, migration trends, and whether new areas are becoming involved.

This location tracking is clinically valuable for distinguishing fibromyalgia from other conditions with more localised pain patterns. It also helps identify whether treatments are reducing the number of affected areas (a sign of improvement that intensity scores alone might not capture).

Fatigue and sleep tracking alongside pain

Fatigue in fibromyalgia is not ordinary tiredness—it is a profound exhaustion that does not resolve with rest. Tracking fatigue alongside pain reveals important relationships: whether fatigue follows high-pain days, whether poor sleep predicts both fatigue and pain the next day, and whether medications affect fatigue independently of their pain relief.

Sleep quality data is particularly important because non-restorative sleep is both a symptom and a driver of fibromyalgia. Recording sleep duration, quality, and the number of awakenings alongside morning pain levels can reveal whether sleep interventions are affecting your overall symptom burden.

Identifying flare patterns and triggers

Fibromyalgia flares can seem random, but consistent tracking often reveals patterns that are invisible to memory. Weather changes, hormonal cycles, stress events, overexertion, and sleep disruption are common triggers that emerge from tracked data. Identifying your personal triggers allows proactive management—adjusting activity levels, pre-medicating before known triggers, and communicating patterns to your care team.

PainTracker's local analytics can highlight time-of-day patterns, day-of-week variations, and correlations between pain levels and tracked variables. Because all analysis happens on your device, you can explore sensitive patterns—like the relationship between workplace stress and symptom severity—without worrying about who else might see the data.

Communicating fibromyalgia data to clinicians

Fibromyalgia remains a condition that some clinicians are sceptical about, partly because traditional clinical assessments often appear normal. Structured, consistent symptom data provides objective evidence of your symptom burden that supports your lived experience. A four-week export showing daily pain levels, fatigue scores, sleep data, and functional impacts is far more convincing than a verbal report.

When preparing for appointments, export data that covers the period since your last visit. Highlight medication changes and their apparent effects, new patterns you have noticed, and any functional changes. This structured presentation facilitates productive clinical conversations about treatment adjustments.

Try PainTracker free — offline, encrypted, clinician-ready pain tracking.