← All projects
Minha Doutora

Minha Doutora

Creator · Personal project, in development

My health records should be in my hands

Minha Doutora began with my girlfriend asking for my test results. It became a personal health vault built around ownership, sharing, and care.

My girlfriend is a doctor. She would ask me to send her my medical exams and laboratory results, and I would start looking through different places, trying to remember where each file had ended up.

It was a small, recurring frustration. It also made a larger problem visible: laboratories had my health data in their systems, but I did not have a useful, organized copy of it in my own hands.

I wanted one place where I could keep those records and share them with someone helping me. I thought doctors would value that too. So I started building something for myself and my girlfriend.

A personal vault, built around the person

The project became Minha Doutora — “My Doctor” in English.

Its starting point is ownership. The person whose health the documents describe should be able to find them, understand what is stored, and decide who can see them.

That can mean a doctor preparing for an appointment, a family member helping with care, or someone you trust who needs access to a particular document. Sharing should be understandable enough that people can make that choice with confidence.

The motivation is personal. I want it to be easier for people to care for each other.

Keep the records, choose who can see them

The core flow is a document vault:

  1. Add medical documents to your own collection. The application keeps the original file.
  2. Find the document again through its information and searchable text.
  3. Choose whether to share selected documents or invite someone to your vault.
  4. Let the recipient accept the invitation, then review or revoke access when needed.

The code distinguishes sharing a selection of files from sharing a vault that includes current and future documents. The interface also supports links, QR codes, and invitations. Opening an invitation does not itself grant access.

Family groups add another way to organize care. A person might have access through a direct invitation and through a group. Removing one of those relationships should preserve another valid grant. The access logic keeps track of those separate sources.

These details matter because “share my data” should have a meaning that the owner can understand.

The AI possibility starts with useful records

Part of the original motivation was that I could not easily make my records available to my own AI tools. I wanted to be able to decide what to do with the data, including exploring future uses with agents.

Using personal agents with these records is a direction I want to explore. The current project starts with the foundation: keeping documents, controlling access, and making their contents easier to organize and review.

The repository also contains an optional extraction pipeline. It can classify a document and extract structured information from it, keeping links back to the source. Original files, extracted information, and accepted corrections are separate. A later processing run should not silently replace something a person has already reviewed.

A small product layer over established tools

I built the application around Paperless-ngx, using it for document originals, OCR, search, and document permissions. The product layer focuses on the person, the vault, and the relationships around it.

Part Implementation
Application Next.js, React, and TypeScript.
Identity Better Auth with email sign-in and Google support.
Document system Paperless-ngx for originals, OCR, search, and permissions.
Product data PostgreSQL for accounts, invitations, grants, processing jobs, and review state.
Optional extraction DeepSeek, document text and page images, structured validation, and source references.
Deployment Docker Compose on a Raspberry Pi, with Cloudflare Tunnel serving the application.
app/       → interface, identity, sharing, processing
design/    → visual and interaction rules
docker/    → services, workers, deployment
docs/      → product decisions and operating notes

The architecture keeps permission checks close to document access. Product records, groups, or links do not independently grant access to a file. Reads must still match the current document permissions.

Background jobs handle work that takes longer than a page request, including document processing and keeping sharing relationships in sync. PostgreSQL stores the job state so work can be retried after an interruption.

The optional extraction path is also designed to preserve uncertainty. Values and dates need support in the source document. A reviewed value remains distinct from a new extraction, and the original is preserved. This gives the person reviewing a result a way to check where it came from.

Making care a little easier

The project started with someone I love asking for a file. That remains a useful test for every new idea: will this make it easier to find the right information and share it with the right person?

I want my data to be something I can use and care for. I want the people helping me to spend less time waiting for it. Minha Doutora is my attempt to make that a little more natural.

Want to talk about what you’re building? Get in touch