Docmize
Software Developer InternAI Hospital Management System
At Docmize I build frontend interfaces and dashboards for an AI-integrated hospital management system covering appointments and patient workflows. It’s the one project on this page where I didn’t choose the architecture, and that’s exactly what makes it valuable to me.
Everything else here I specced and built myself. This is the environment where I have to translate product requirements into someone else’s codebase, coordinating with backend and design, and it has made me a better spec writer than any project where I got my own way.
- Client product — access on request
Screens pending client clearance
01 / 09
Problem
Hospital software has a density problem. A lot of information, several roles, clinical consequences for a confusing screen, and users who are mid-task and not in a position to explore an interface.
Appointments and patient workflows are where that density concentrates. The engineering problem is making dense information legible; the product problem is deciding what a given role needs on screen and what is noise to them.
02 / 09
Goal
Product goal
Interfaces and dashboards for appointments and patient workflows where the AI-assisted parts are legible to the person using them — not opaque suggestions on a busy screen.
Engineering goal
Translate product requirements into modular, scalable healthcare workflows that fit the existing architecture rather than working around it.
Collaboration goal
Coordinate with backend and design so the frontend is a shared contract, not a set of assumptions.
03 / 09
Architecture
This is a team codebase and the architecture predates me, so what follows is my layer rather than the system.
Frontend layer
Interfaces and dashboards for appointments and patient workflows, built as modular components so healthcare workflows can be composed and extended rather than rebuilt per screen.
AI-assisted experience layer
Product requirements for AI-assisted features translated into user-facing flows — the work being to make the AI legible and interruptible in a clinical context, not just present.
Integration surface
The contract with backend services, agreed with the backend team rather than inferred from response shapes.
Fuller architectural detail isn’t mine to publish.
Screens pending client clearance
04 / 09
Key features
Appointment interfaces
Scheduling and appointment workflows in the frontend
Patient workflow dashboards
Dense clinical information rendered legibly
AI-assisted experiences
Product requirements for AI features turned into usable flows
Modular workflow components
Scalable, reusable healthcare workflow pieces rather than per-screen builds
05 / 09
Technical decisions
The system-level decisions on this project aren’t mine to claim. Within my layer:
Modular composition over per-screen implementation.
Healthcare workflows repeat with variation — the same appointment logic appears in several places with different roles and constraints. Building composable workflow components rather than screens means variation is configuration, and the next requirement is a change rather than a rewrite.
Fit the existing architecture rather than work around it.
The tempting move as a new contributor is to build alongside what’s there in a way you find cleaner. Working within the established patterns costs some short-term speed and is the reason the codebase stays maintainable by the people who’ll have it after my internship.
Treat the API contract as a coordination artefact.
The interface between frontend and backend is where assumptions become bugs. Agreeing it explicitly with the backend team, rather than inferring it from a response shape, is the cheapest debugging I do.
06 / 09
Challenges
Working inside decisions I didn’t make.
Every other project on this page, I chose the structure. Here I inherit it, and my judgment about what’s better is frequently missing context about why something is the way it is. Learning to ask before improving is the actual skill.
Density without simplification.
Clinical users need a lot on screen. You can’t solve that by hiding things — hidden information in a clinical workflow is a hazard. The problem is hierarchy, not reduction, and it’s harder.
AI features in a context with consequences.
An AI suggestion in a consumer app that’s wrong is an annoyance. In a patient workflow it’s something else. The interface has to make it clear what’s a suggestion, where it came from, and how to override it.
Coordination cost as a feature of the job.
Working with backend and design is slower than deciding alone and produces things that survive after I leave. Recalibrating my sense of “productive” around that took a while.
07 / 09
Lessons learned
Requirements read differently when you’ll implement them.
Reading someone else’s requirements and building against them has changed how I write my own. I’m more specific about edge cases and less casual about phrases like “handle appropriately.”
Constraints you didn’t choose are the useful ones.
My own projects reflect my preferences. This one doesn’t, and working inside someone else’s structure has taught me more per week than greenfield does.
Legibility is the product in high-stakes software.
A hospital dashboard that’s beautiful and ambiguous is a worse product than one that’s plain and unmistakable. This has permanently changed how I think about interface polish.
“Modular and scalable” is a claim about the future.
The test of whether a component was well designed is what the next requirement costs. Nothing else.
08 / 09
Future improvements
Framed as what I’d want to push for, not as decisions I own:
Instrument the appointment and patient workflows so requirement debates are settled with usage data.
Make AI-assisted suggestions consistently traceable — source and confidence visible at the point of use in every flow.
Extend the modular workflow components as coverage grows, with the next-requirement cost as the test of whether they’re right.
Push interface-contract agreements earlier in the cycle, before implementation rather than during it.
09 / 09
Technologies used
Named in the résumé for this project
- Frontend interfaces and dashboards
- AI Workflow Design
- Modular, scalable workflow architecture
In the global skills list, not attributed to Docmize
- React
- Next.js
- TypeScript
- JavaScript
- REST APIs
- Agile & Scrum
- Jira
- Notion