Transmy

• 

About the project

This project started from a simple observation: in many social and medico-social organizations, daily transmissions are still fragmented across paper notes, spreadsheets, emails, generic chat tools, or expensive proprietary platforms.

Yet these transmissions are essential. They allow professionals to share observations, important events, follow-up actions, and information needed to ensure continuity of care and support.

I wanted to explore whether a modern, secure, self-hosted, and open-source alternative could be built for these teams.

The goal is not to create another general-purpose messaging application. The project is designed specifically around the workflow of social and medico-social professionals: structured transmissions, handovers between shifts, acknowledgements, follow-up tasks, role-based access, organizational segmentation, and full auditability.

Inspiration

I work in an environment where security, traceability, infrastructure constraints, and data protection are part of everyday technical decisions.

I was inspired by the gap between the importance of medico-social transmissions and the tools sometimes available to professionals. Small organizations may not have the budget, technical resources, or freedom to deploy large commercial platforms. At the same time, using an unsuitable tool for sensitive information creates obvious security and privacy risks.

This led me to define several core principles for the project:

• free and open source;
• self-hostable;
• deployable with Docker Compose;
• no mandatory cloud dependency;
• no telemetry by default;
• individual user accounts;
• strict separation between organizations, services, and teams;
• backend-enforced permissions;
• detailed audit logs;
• no real personal or health data used during development.

I also wanted the project to remain lightweight enough for a small organization to test, understand, and operate without requiring a large infrastructure team.

How I built it

I developed the project using Visual Studio Code, Git, GitHub, Docker, and Docker Compose.

OpenAI Codex was used as a development partner throughout the process. I used it to help:

• structure the initial requirements;
• challenge architectural decisions;
• generate and review parts of the code;
• create documentation;
• identify security risks;
• improve the data model;
• design tests;
• analyze errors during local development;
• keep the project organized as it grew.

Rather than asking the model to generate the entire application at once, I tried to work incrementally. I first described the real-world workflow, then separated the project into functional areas such as authentication, users, organizations, supported persons, transmissions, acknowledgements, tasks, and audit events.

The application is packaged as a reproducible Docker Compose environment so that a contributor can clone the repository, configure the required environment variables, and start the stack locally.

The architecture was designed with separation of concerns in mind:

• a web interface for professionals;
• a backend API containing the business and authorization rules;
• a relational database for structured and auditable data;
• isolated configuration and secrets;
• infrastructure definitions stored alongside the source code;
• automated checks and tests where possible.

The current project is a prototype and a technical foundation. It is not presented as a certified medical device or as a production-ready replacement for an official electronic user record system.

What I learned

The most important lesson was that this type of project is not primarily a user-interface problem.

The difficult questions are about information boundaries:

• Who is allowed to see a transmission?
• Should access depend on the establishment, service, unit, profession, or assigned person?
• What happens when an employee changes teams?
• Can an author edit a transmission after it has been read?
• How should a correction be recorded without destroying the original history?
• Which events must be logged?
• How can the application remain usable without weakening security?

I learned that authorization must be treated as a central business feature, not as an additional layer added at the end. Hiding an element in the frontend is not sufficient; every backend operation must independently verify the user's permissions.

I also learned the value of writing documentation and threat models before adding too many features. Codex was particularly useful for reviewing assumptions, identifying edge cases, and turning broad ideas into concrete technical tasks.

Finally, I learned to use AI more effectively as an engineering tool. The best results came from giving it context, constraints, acceptance criteria, and small reviewable tasks—not from asking it to build an entire product autonomously.

Challenges

Designing useful permissions

The biggest challenge was creating a permission model that is secure without becoming impossible for organizations to configure.

A simple administrator/user distinction is not enough. Access may need to depend on several dimensions at once: organization, establishment, service, team, professional role, and the people being supported.

The project therefore required a more granular role and scope model, with permission checks enforced on the server.

Protecting sensitive information

A transmission platform may process personal, social, behavioral, and potentially health-related information. This changes the way every feature must be designed.

Logging, exports, attachments, backups, notifications, session management, and administrator access all require careful consideration. Even a useful feature such as an email notification can become a privacy issue if it includes sensitive content.

For this reason, external notifications are intended to remain generic, and the project does not require sending data to an external AI service.

Keeping the deployment accessible

I wanted the application to be deployable by smaller organizations and homelab-style environments, while still following sound security practices.

Docker Compose makes deployment easier, but it does not automatically make a system secure. The documentation therefore needs to clearly explain HTTPS, secret management, backups, updates, network exposure, authentication, and production hardening.

Avoiding excessive scope

It was tempting to add medication management, scheduling, family portals, mobile applications, artificial intelligence summaries, and integrations with national healthcare systems.

I chose to focus first on a smaller and clearer objective: reliable transmissions and shift handovers.

Keeping this boundary was one of the most important product decisions.

Why open source

Open source is important for this project because organizations should be able to inspect how their data is handled, deploy the software on infrastructure they control, adapt it to their workflows, and contribute improvements.

It also allows developers, security professionals, and medico-social workers to discuss the design openly.

My ambition is not only to publish code, but to create a project that can eventually be reviewed and improved by people with complementary expertise: software development, cybersecurity, data protection, accessibility, and medico-social practice.

Next steps

The next stages of the project include:

• validating the workflows with medico-social professionals;
• strengthening automated authorization tests;
• improving accessibility and mobile usability;
• documenting secure production deployment;
• adding backup and restoration procedures;
• carrying out a formal security review;
• improving audit and incident-management features;
• building a clear contribution process for the open-source community.

Before any real-world deployment involving sensitive data, the project will require further security testing, legal and regulatory assessment, and validation by qualified professionals.

What Build Week enabled

Build Week gave me the motivation to transform an idea into a concrete, versioned, and documented project.

Codex helped reduce the distance between functional ideas and implementation. It allowed me to move faster while still reviewing the generated changes, testing the application, and remaining responsible for the architectural and security decisions.

The result is an early but tangible foundation for an open-source transmission platform designed around the real needs of social and medico-social teams.

Built With

• codex
• gpt
• sol