Starting Dermi: From Research Projects to a Clinical Platform

Dermi Inc. was founded in Toronto, Canada, to address a gap that became apparent through years of academic research: validated tools for dermatological image analysis existed, but the clinical infrastructure needed to deploy them did not. The company was formed not to commercialize a single algorithm, but to build the platform that would make an entire class of research tools usable in practice.

The Research That Preceded the Company

Before Dermi existed as a company, the work that would eventually define its platform was conducted as a series of independent research projects in dermatological image analysis. Over several years, tools were developed for segmentation, classification, and image registration. Each addressed a real clinical need, and each was validated through peer-reviewed publication. These research tools are not currently available as features in Dermi Atlas but represent the long-term development direction for the platform.

Segmentation models for automated body surface area estimation were validated against dermatologist manual assessment and published in the Journal of the American Academy of Dermatology in 2022. A multi-stage AI architecture combining segmentation, classification, and metric computation was introduced as the SPREAD framework in 2024. That same year, the AI PASS comparative study demonstrated AI-based psoriasis body surface area estimation with significantly lower error rates than board-certified dermatologists. These research capabilities inform the platform's development roadmap but are not available in current product versions.

Each of these projects produced functional tools, but each existed in isolation. Segmentation required its own deployment environment, classification had separate infrastructure, and registration algorithms needed manual orchestration. No shared platform connected them, and no clinical workflow existed to deliver their outputs to practitioners.

The Infrastructure Problem

Validated research tools are not clinically useful on their own. An algorithm that measures body surface area involvement has no value without a system that manages patient records, organizes clinical images, tracks changes over time, and documents consent. The gap between a working model and a deployable clinical tool is not the model itself; it is everything surrounding it.

The missing infrastructure was substantial: patient management to associate images with clinical records, structured image organization to support longitudinal comparison, audit trails for regulatory compliance, consent documentation integrated into the clinical workflow, and a deployment strategy that did not require dedicated IT staff. Translating research into clinical practice required building all of this from scratch.

Why Not Integrate into Existing Systems?

EMR integration was explored as an alternative to building a standalone platform. The reasoning was straightforward: if clinical infrastructure already existed in electronic medical record systems, the research tools could potentially be added as extensions or plugins rather than requiring a new platform.

This approach was ultimately abandoned for several reasons. Existing EMR platforms are closed-source systems with formal revalidation cycles that are incompatible with the pace of active research. Each update to an integrated tool would require re-certification through the host platform's approval process. The imaging capabilities in existing EMR systems are rudimentary, typically limited to basic photo attachment rather than structured clinical photography workflows. Building within these constraints would have required compromising the tools to fit the limitations of the host system.

The Decision to Build

The conclusion was that a dedicated platform was needed, not a wrapper around existing code or a plugin for an existing system. The platform would need to serve two distinct purposes simultaneously: a complete clinical photography system that practices could use as their primary imaging tool, and a foundation for continued research development where new methods could be integrated without disrupting clinical operations. The platform is designed to operate alongside existing EMR systems as a specialized imaging tool, not to replace practice management or electronic health record software.

This dual purpose shaped the platform's architecture from the beginning. Clinical features such as patient management, image comparison, consent documentation, and audit logging were not afterthoughts added to a research tool. They were designed as core components of a system that treats research and clinical practice as complementary rather than separate concerns.

Architecture Decisions That Followed

A local-first, self-hosted architecture was chosen to ensure data sovereignty. Patient imaging data would remain within the clinical environment that created it, with no transmission to external cloud servers. This decision aligned with both regulatory requirements and the practical reality that many practices prefer direct control over sensitive patient data.

Self-hosted deployment introduced its own challenges. The platform needed to be accessible to practices without dedicated IT staff, which led to the development of Dermi Atlas Manager, a desktop application that handles Docker-based deployment, SSL certificate management, backups, and updates. The goal was to make self-hosted infrastructure as accessible as cloud-based alternatives without sacrificing data sovereignty.

What Came Next

The founding story describes why the platform was built. The subsequent articles describe what was built and how. Why We Built Dermi Atlas details the specific clinical photography problems the platform addresses. Introducing Dermi Atlas: Clinical Photography Under Your Control covers the platform's capabilities and deployment model. The Dermi Atlas Cloud Demo provides free access to explore the platform's core features without installation.