Motivation
Important health information is often distributed across relatives, remembered imprecisely, or only reconstructed when a medical professional asks about family history. I built MediTree to help a closed family collect that knowledge in a structured way while preserving who reported something, how certain it is, and who is allowed to see it.
MediTree collects statements. It does not diagnose conditions, calculate disease risk, interpret genetic findings, or provide medical advice.
Product
The bilingual German/English MVP combines a biological family tree with structured health contributions. Family members can:
- Build person profiles and parent-child relationships across generations
- Record diagnoses, symptoms, laboratory values, and other observations as individual statements
- Attach provenance, certainty, timing, and visibility to a contribution
- Invite relatives through limited and revocable access flows
- Claim their own profile and collaborate inside a closed family
- Edit or withdraw their own contributions
- Export their personal or family data where permitted
The graph is designed around pedigree relationships rather than being a generic social network. Duplicate suggestions and controlled merging help families improve the tree without silently rewriting its history.
Privacy and authorization
Health and family data require stricter boundaries than an ordinary collaborative application. MediTree therefore combines several layers:
- Passwordless email authentication with secure server-side sessions
- PostgreSQL row-level security and tenant-scoped family authorization
- Explicit visibility for health contributions
- Hidden contributor identities when a source should not be revealed
- Ownership-aware editing and withdrawal rules
- Application-layer encryption for family, person, and health payloads
- EU-region infrastructure, no public profiles, and no advertising tracking
Living people are protected by default, and an unknown living status is treated with the same caution as a living person. Demo entries owned by other fictional family members remain visible but cannot be mutated by the current user; that boundary is enforced in database policies and functions rather than only hidden in the interface.
Implementation
I built the application with Next.js, React, TypeScript, Supabase Auth, PostgreSQL, React Flow, Zod, and Tailwind CSS. The work spans product design, bilingual UX, graph layout, authentication, database modeling, row-level authorization, encrypted application data, consent and audit foundations, invitation lifecycle management, and deployment on EU infrastructure.
What I learned
MediTree made privacy a product and data-model concern rather than a final compliance layer. Seemingly small choices - whether a contributor is named, who may describe a living relative, or what happens when someone leaves a family - affect the UI, encryption model, authorization rules, and lifecycle operations together. Building those boundaries coherently has been as important as building the visible family tree itself.