T-PHEDS

DESIGNING FOR WHEN THE DETAILS ACTUALLY MATTER

T-PHEDS — Transplant Pulmonary Health Entry Data System — is a web-based health tracking application I designed and built from scratch following my own transplant procedure. Not a concept. Not a class project. A real tool built to solve a real problem with real consequences if the data was wrong.

What This Was

Over roughly a year and a half, T-PHEDS evolved from a single-user personal utility into a multi-user PHP and MySQL application spanning product strategy, UX design, information architecture, front-end behavior, back-end development, security scoping, and medically informed feature logic developed in consultation with one of the top pulmonary transplant teams in the United States.

THE TOOLS THAT EXISTED WEREN'T BUILT FOR THIS

Post-transplant care requires repeated daily tracking across multiple health metrics — pulmonary volume readings, glucose levels, weight, and other time-sensitive indicators. The challenge isn't just collecting data. It's collecting it consistently, preventing fragmentation, and presenting it in a way that remains readable and trustworthy over time.

The Gap

Generic note-taking tools and standard health apps weren't built around the specific demands of pulmonary transplant aftercare. What was needed was a system designed around actual monitoring behavior — not bloated with ads, not locked behind a subscription, not integrated into forums built for a different kind of patient.

END TO END. NO HANDOFFS.

Product strategy, UX and workflow design, information architecture, front-end implementation, PHP and MySQL back-end development, authentication and session handling, responsive design, debugging, data integrity logic, and security scoping.

This was not a handoff project. I owned both the product thinking and the implementation.

THE QUESTIONS THAT SHAPED THE BUILD

T-PHEDS wasn't about storing inputs in a database. It was about translating a medically repetitive, high-friction process into a stable and understandable product experience. That meant working through questions that don't appear in a brief:

The Hard Questions

How should repeated submissions on the same day behave? What makes a summary trustworthy in a health context? How do you make tables usable on mobile without destroying readability? How do you allow customization of medically relevant thresholds without encouraging careless changes? How do you make a shared-hosting PHP app more robust when the environment itself is limiting what patterns you can use?

The answers shaped both the experience and the architecture.

FIVE DECISIONS THAT DEFINED THE PRODUCT

Multi-User Architecture

Converted from a single-user tool to a full account-based system. All records scoped to the logged-in user through user_id. Authentication standardized around session-based logic. This made T-PHEDS viable as a product rather than a personal utility.

Smarter Daily Entry Model

Implemented a check-then-update-or-insert pattern so multiple submissions on the same date update a single daily row instead of creating duplicates. Improved data integrity, summary accuracy, editability, and long-term readability — and aligned the system with how people actually log health data across a day.

Safer FEV1 Summary Logic

Replaced unsafe comparison logic that could incorrectly match null values with a validated helper function. Corrected stats calculations to ignore nulls and zero placeholders. Made the interface more trustworthy and reduced the risk of misleading visual emphasis on critical health data.

Personalized FEV1 Minimum Override

Added a user-level override system for minimum acceptable FEV1 values. Because of the medical implications, I designed a two-step confirmation flow with additional warning language and a reset path back to automatic calculation. Flexibility balanced against responsible UX.

Full Edit-Page Rebuild

The hosting environment didn't support mysqli_stmt->get_result(). I rebuilt the entire edit workflow using bind_result() patterns, explicit column selection, and stronger ownership checks — resolving a date formatting bug and establishing a more maintainable query architecture in the process.

BUILT FOR WHERE HEALTH TRACKING ACTUALLY HAPPENS

Daily health tracking doesn't always happen at a desk. I fixed broken CSS selectors, duplicate rules, layout conflicts, and table overflow behavior across devices. Moved the interface toward a compress-and-wrap strategy. Reworked form layouts for mobile stacking.

Device-First Thinking

Added a touch-device orientation warning built on device interaction characteristics rather than pixel-based assumptions. The interface had to work under real-world conditions — tired, post-medication, on a phone at 6am — not just in a desktop browser.

OWNERSHIP AS A CORE PRODUCT REQUIREMENT

All select queries scoped to the logged-in user. Inserts include user_id. Updates and deletes verify both record ID and user_id. Production login uses a whitelist-based access model.

Privacy Roadmap

Future: AES-256 field-level encryption with per-user key handling and password reset support.

Personal health data isn't an edge case. It's the whole product.

WHAT IT BECAME

A single-user tracker became a multi-user health data platform with secure account-scoped access, consolidated daily entry logic, reliable pulmonary summaries, a rebuilt editing workflow, improved mobile usability, customizable threshold logic, and a stronger architectural foundation for future privacy enhancements.

WHY THIS PROJECT MATTERS IN A PORTFOLIO

T-PHEDS represents the kind of work I find most meaningful — product design grounded in real use, real constraints, and real consequences when the details are wrong.

I wasn't designing screens or patching code in isolation. I was identifying friction, rethinking workflows, improving trust in the data, debugging environmental limitations, and building a better system around a genuine health management need.

The Complete Picture

It's a complete demonstration of how I work across UX, product strategy, and implementation — not as separate disciplines, but as one continuous act of problem solving.