Transplant Pulmonary Health Entry Data System

Designing a health tracking platform for post-transplant care

Overview

T-PHEDS is a web-based health tracking system I designed and built shortly after my own procedure to support the daily realities of post-transplant monitoring. The product was created to solve a practical, personal problem: tracking critical pulmonary and health data after transplant in a way that is organized, usable, mobile, and easy to review over time.

Over the course of roughly a year and a half, I evolved T-PHEDS from a simple single-user utility into a more complete multi-user PHP and MySQL application. The work spanned product strategy, UX design, workflow design, front-end behavior, back-end architecture, debugging, responsive design, security scoping, and medically informed feature logic from one of the top pulmonary transplant teams in the United States.

This project reflects how I approach product development when the problem is real, the environment is constrained, and trust in the interface matters.

---

The Problem

Post-transplant care often requires repeated daily tracking across multiple health metrics, including pulmonary volume readings, glucose levels, weight-related values, and other time-sensitive health indicators. The challenge is not just collecting data. It is collecting it consistently, keeping it organized by day, preventing fragmentation across entries, and presenting it in a way that remains understandable and useful later.

Generic note-taking tools recommended such as paper and pen along with standard health tracker apps were not built around the specific needs of typical pulmonary transplant aftercare. What was needed was a system designed around actual monitoring behavior and the need to quickly review trends, thresholds, and daily values with confidence. A system not bloated with ads, integrated into support forums, or requiring a subscription fee.

---

My Role

I led the project end to end, including:

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

---

Goals

The core goals for T-PHEDS were to:

---

Product Thinking

T-PHEDS was not just about storing inputs in a database. It was about translating a medically repetitive, high-friction process into a more stable and understandable product experience.

That meant thinking through questions like:

• 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 to those questions shaped both the user experience and the architecture.

What I Built

1. A multi-user architecture

One of the biggest shifts in the project was converting T-PHEDS from a single-user tool into a multi-user application.

I reworked the system so all records were tied to the logged-in user through user_id, with data reads, writes, edits, and deletes all scoped accordingly. Authentication was standardized around session-based logic using $_SESSION['user_id'], replacing inconsistent legacy patterns.

This made the system viable as an account-based product instead of just a personal utility.

2. A smarter daily entry model

Originally, repeated submissions could create duplicate rows or split related data across multiple records. I implemented a check-then-update-or-insert pattern so that multiple submissions on the same date update a single daily row instead of creating duplicates.

That change improved:

• data integrity
• summary accuracy
• editability
• long-term readability

It also aligned the product with how people actually log health information across the day.

3. Better time-aware input

I updated date fields to use datetime-local inputs with current date and time prefilled. This improved precision and made the record structure more useful for time-sensitive monitoring.

4. Safer FEV1 summary logic

A major piece of refinement involved how FEV1 data was summarized and highlighted.

I replaced unsafe comparison logic that could incorrectly match null values with a safer helper function that validates values before comparing them. I also corrected stats calculations so they ignored nulls and zero placeholders rather than treating them as real readings.

This made the interface more trustworthy and reduced the risk of misleading visual emphasis.

5. Personalized minimum acceptable FEV1 feature

I added a user-level FEV1 minimum override system. By default, the app calculates a minimum acceptable value at 90% of the user’s historical best FEV1. Users can manually override that value when medically appropriate, and the system visually indicates when a manual override is active.

Because of the medical implications, I designed a two-step confirmation flow with additional warning language and a reset path back to automatic calculation.

This feature was a good example of balancing flexibility with responsible UX.

6. A full edit-page rebuild

The hosting environment did not support mysqli_stmt->get_result(), which caused fatal errors in the original edit workflow. I rebuilt edit.php using bind_result() patterns, explicit column selection, and stronger ownership checks.

That rewrite also resolved a date formatting bug that displayed records as 12/31/1969, and reinforced a more maintainable approach to query design.

---

Responsive and Mobile Design

Because daily health tracking does not always happen at a desk, mobile usability mattered.

I fixed multiple CSS and layout issues that were making the app brittle across devices, including broken selectors, duplicate rules, layout conflicts, and table behavior that forced awkward overflow.

I moved the interface toward a compress-and-wrap strategy rather than relying on horizontal scrolling. I also reworked form layouts so labels and inputs stack appropriately on smaller screens, improved nav alignment, and added a touch-device orientation warning that relies on device interaction characteristics instead of crude pixel-based assumptions.

These changes made the system more practical for actual daily use.

---

Technical Challenges

This project involved substantial debugging under real hosting constraints.

A few recurring lessons shaped the build:

• shared hosting limitations meant get_result() was unavailable, so queries had to use bind_result() and fetch()
• bind_result() required an exact one-to-one match with returned columns, making explicit query design essential
• SELECT * created unnecessary fragility and was replaced with explicit column lists
• duplicate HTML IDs caused JavaScript targeting issues
• dynamically injected navigation required scripts to run only after the DOM content was actually inserted
• loading a shared script twice caused duplicate UI behavior

Each of these issues required root-cause debugging rather than surface-level fixes.

---

Security and Privacy Direction

Because T-PHEDS deals with personal health-related information, I treated ownership and access control as core product requirements.

I ensured:

• all select queries were scoped to the logged-in user
• inserts included user_id
• updates and deletes verified both the record ID and user_id
• production login used a whitelist-based access model

I also defined a future privacy roadmap involving AES-256 field-level encryption with per-user key handling and support for password reset scenarios.

---

Outcome

By the end of this phase, T-PHEDS had matured into a much more stable and useful system.

It evolved from a simple tracker into a more complete health data product with:

• multi-user account support
• secure user-scoped data access
• consolidated daily entry logic
• more reliable pulmonary summaries
• a rebuilt editing workflow
• improved mobile usability
• better navigation behavior
• customizable threshold logic
• stronger architectural foundations for future privacy enhancements

---

Reflection

T-PHEDS represents the kind of work I enjoy most: product design that is grounded in real use, real constraints, and real consequences when the details are wrong.

I was not just designing screens or just patching code. I was identifying friction, rethinking workflows, improving trust in the data, debugging environmental limitations, and building a better system around a real health management need.

It is a strong example of how I work across UX, product strategy, and implementation to make complex workflows more usable and more dependable.