Project: Neuroanatomy Atlas Industry: Medical education Services: Application modernization, custom software development, database architecture, admin tooling, DevOps Live application: Explore the Neuroanatomy Atlas
A working prototype proves an idea. A sustainable product needs to do more: it must support changing content, new use cases, and ongoing development without making every update an engineering project.
The Neuroanatomy Atlas began as an interactive teaching application for exploring MRI slices across three anatomical planes — axial, coronal, and sagittal. Students and clinicians could identify highlighted anatomical structures and test their knowledge through a quiz. The original interactive viewer, developed by Cody Lee, MD, demonstrated the educational value of the concept.
But its content lived in JavaScript files. MRI images were added manually, anatomical overlays were represented by hand-authored SVG paths, and quiz behavior was largely hard-coded. Updating the atlas meant changing source code and deploying it again.
Our goal was not to replace a successful teaching experience. It was to remove the engineering bottlenecks around it.
The challenge: every content change was a development task
The original application was a single-page JavaScript viewer built with Konva. A central manifest defined the image sources, structure overlays, mapline positions, and quiz-eligible structures. It was a practical design for an initial release, but difficult to extend.
There was no administrative interface, no image uploader, no browser-based overlay editor, and no persistent record of quiz attempts. The application was tied to one brain MRI atlas. Even editing a structure’s outline required working directly with SVG path data.
The central question was straightforward: What if the medical educator — not the developer — could manage the atlas?
The solution: separate the educational content from the code
We rebuilt the application as a Nuxt 3 and TypeScript platform, backed by PostgreSQL and Prisma. Konva remained part of the viewer, preserving the interactive imaging approach while also powering a new visual authoring experience.
Instead of storing anatomical content in a JavaScript manifest, the platform now represents atlases, MRI slices, structures, overlays, and assessment data in a database. The public viewer, administrative interface, and API run together in one application.
This architectural change made possible several concrete improvements.
1. Draw anatomical structures in the browser
Previously, defining an overlay meant manually writing SVG path coordinates. The new administrative editor allows an authorized user to trace a structure directly on an MRI image, upload or paste an SVG, and refine curves with Bézier handles.
That changes the workflow. A subject-matter expert can create and adjust anatomical annotations through a graphical interface rather than handing the task to a developer.
The most meaningful feature is not the drawing tool itself. It’s the transfer of routine content ownership to the people who know the anatomy.
2. Support multiple atlases without building multiple applications
The original viewer was wired to one brain MRI dataset. The new data model supports multiple atlases, each with its own images, structures, overlays, and quiz settings.
This provides a path to additional anatomical subject areas without rewriting the application around each new dataset. The brain MRI atlas remains the starting point; the architecture is no longer limited to it.
3. Turn a temporary quiz into a persistent assessment experience
The original quiz kept progress in browser memory. In the modernized platform, quiz attempts and individual responses are stored in PostgreSQL, with partial progress saved automatically.
Educators can configure question counts, randomization, hints, incorrect-answer behavior, and scoring behavior by atlas. Individual structures can be marked as quiz-eligible and assigned difficulty levels.
This makes the assessment experience configurable through content and settings rather than a new development cycle.
4. Give administrators control over publishing and site content
The admin suite now supports atlas publishing, MRI image uploads, slice ordering, structure management, overlay editing, quiz configuration, user administration, and site content updates.
Even pages such as Home, About, and Credits can be managed through database-backed content blocks instead of direct HTML edits.
The result is a clear division of responsibility: educators manage educational material, while engineers can focus on extending and maintaining the platform.
The engineering beneath the experience
A useful admin interface needs dependable systems behind it. We also modernized how the application is packaged, deployed, and updated.
The platform runs in Docker containers with PostgreSQL and Caddy. Versioned releases are delivered through a Git-based CI/CD pipeline to DigitalOcean. Database migrations are tracked and applied as part of deployment, with persistent storage, health checks, and log rotation supporting operations.
Just as important, an idempotent migration process imported the original structures, overlays, and quiz-eligibility data into the new database. The modernization preserved the educational work already invested in the original application.
Before and after
| Capability | Original application | Modernized platform |
|---|---|---|
| Educational content | Hard-coded JavaScript manifest | Database-managed content |
| Atlases | One fixed brain atlas | Multi-atlas architecture |
| Anatomical overlays | Hand-authored SVG paths | Browser-based drawing and editing |
| MRI image management | Developer-managed files | Administrative uploads and ordering |
| Quizzes | Hard-coded settings; in-memory attempts | Configurable assessments; persistent attempts |
| Site pages | Static HTML | Editable, database-driven content blocks |
| Administration | No admin interface | Dedicated management suite |
| Releases | Static-file deployment | Containerized, versioned CI/CD |
The outcome: an application its educators can extend
The most important change isn’t the framework, database, or deployment pipeline. It’s that ordinary content work no longer has to be software development work.
The Neuroanatomy Atlas retains the interactive MRI exploration that made the original viewer valuable. Around that experience, it now has tools for authoring content, organizing additional atlases, configuring assessments, preserving student progress, and deploying changes through a repeatable release process.
That is the difference between a prototype built around one use case and a platform designed to accommodate what comes next.
What this means for other organizations
Many organizations have software that works — until the effort required to maintain or expand it begins to slow them down. Sometimes the right answer is not to throw away the original application. It is to preserve the proven experience and modernize the architecture and workflows around it.
At Phillips WDC, we build the systems businesses and organizations run on: custom applications, integrations, administrative tools, and the infrastructure that keeps them maintainable.
Have an application that has outgrown its original design? The next step may be a better platform, not another workaround.
Explore the live Neuroanatomy Atlas
Project credit: The original interactive Neuroanatomy Atlas viewer was developed by Cody Lee, MD. This case study covers Phillips WDC’s modernization and expansion of that application.