DentalCase Connect: Designing a Clinical Mentorship Platform
Ans Ali
Verified
DentalCase Connect
Designing a secure clinical mentorship platform for dentists, specialists and training communities
DentalCase Connect is a clinical mentorship platform designed to help early-career dentists discuss complex patient cases with experienced dental specialists in a more structured, secure and professional environment.
The product was created to solve a problem that already existed in everyday clinical practice.
Junior dentists frequently relied on WhatsApp groups, personal contacts and informal messages when they needed a second opinion. Images, radiographs, patient details and treatment questions were often spread across different chats, making cases difficult to follow and raising concerns around privacy, consent and clinical accountability.
DentalCase Connect brought that process into one dedicated platform.
The system connected mentees, verified mentors, dental groups and platform administrators through a responsive web application and native mobile experience. It supported structured case submission, DICOM and 3D dental files, threaded clinical discussion, private consultations, payments, subscriptions and secure document access.
I worked across the product strategy, information architecture, user flows, UX/UI design and the wider web and mobile application direction.
Project overview
Client
DentalCase Connect
Project lead
Waqar
Industry
Dental technology, clinical education and professional mentorship
Product type
Multi-role dental mentorship marketplace and clinical case review platform
Primary users
Junior dentists, dental residents, early-career clinicians, specialist mentors, training groups and platform administrators
Platforms
Responsive web application, native iOS app and native Android app
Services
Product strategy, information architecture, UX/UI design, design system development, mobile app design, web app design, clinical workflow design, mentor marketplace design and product handoff
The background
In dentistry, many difficult decisions are made under time pressure.
A clinician may need guidance on:
Implant planning
Endodontic complications
Oral surgery
Orthodontic treatment
Restorative cases
Periodontal conditions
Radiographic findings
Treatment sequencing
Prosthodontic planning
Post-operative complications
Less experienced clinicians often ask senior colleagues for support, but those conversations usually happen through informal channels.
A case may begin with a WhatsApp message, continue through separate image attachments and end in a phone call. Important information can become buried, files may be shared without proper context and there is often no permanent record of the clinical reasoning.
The issue was not the lack of willing mentors.
The issue was the lack of a proper system.
DentalCase Connect was designed to move clinical communication away from fragmented chat groups and into a platform built specifically for dental case review.
The product vision
The product was based on a simple idea:
A dentist should be able to prepare a case, upload the relevant clinical files, choose an appropriate specialist and receive structured guidance without relying on personal connections or unorganized messages.
At the same time, experienced dentists needed a way to:
Offer paid mentorship
Review cases efficiently
Build professional credibility
Manage private learning groups
Run consultations
Share educational feedback
Earn from their specialist experience
The platform therefore needed to function as several products at once:
A clinical case submission system
A mentor marketplace
A secure communication platform
A dental file-viewing environment
A paid consultation system
A private community platform
An education and professional development system
An administrative compliance dashboard
The main design challenge was making all of those functions feel like one connected product rather than a collection of unrelated features.
Understanding the users
Mentees
Mentees included dental residents, junior dentists and early-career clinicians looking for support with real clinical cases.
Their main needs were:
Quickly creating a case
Uploading radiographs, images and reports
Finding the right specialist
Understanding the mentor’s expertise
Knowing the expected response time
Discussing the case in one place
Receiving clear, documented feedback
Managing consultation payments
Tracking active and completed cases
Protecting patient information
For this group, the interface needed to feel guided and reassuring.
A user might be submitting a complicated case for the first time, so the application could not assume that they understood how to organize every clinical detail.
Mentors
Mentors were verified senior dentists and board-certified specialists providing case reviews, consultations and educational support.
Their needs were different.
They needed to:
Present credentials and specialties
Define consultation fees
Set response-time expectations
Accept or reject submitted cases
Review clinical files
Respond inside structured case discussions
Request additional information
Manage active cases
Run paid private groups
Schedule consultations
Track earnings and payouts
Build ratings and professional reputation
The mentor experience had to support serious clinical work without feeling like a generic freelancer marketplace.
Administrators
Administrators were responsible for maintaining platform trust, compliance and daily operations.
Their dashboard needed to support:
Clinician verification
Credential review
User moderation
Case monitoring
Payment oversight
Platform commissions
Group and subscription management
File access controls
Dispute management
Audit logs
Reporting
Notifications
Content and policy management
The admin experience required significantly more control than the mentee and mentor applications, while still following the same underlying design system.
The core problem
The project needed to solve five connected problems.
1. Informal clinical communication
Clinical questions were being discussed through general messaging applications that were not designed for structured healthcare communication.
Important details could become disconnected from the images or files they related to.
2. Difficulty finding the right mentor
Junior dentists often depended on whoever was already in their personal network.
There was no simple way to search specialists by discipline, experience, availability, language, pricing or response time.
3. Complex clinical file handling
Dental cases can include much more than ordinary images.
The platform needed to support:
DICOM scans
STL files
PLY files
JPEG and PNG images
PDF reports
Radiographs
Treatment plans
Supporting documents
The experience needed to make these files understandable and manageable without turning the product into a full hospital imaging system.
4. Lack of structured accountability
In informal conversations, there is often no clear timeline showing:
When a case was submitted
When a mentor accepted it
What files were reviewed
What questions were asked
What recommendations were provided
Whether additional information was requested
When the review was completed
DentalCase Connect introduced a structured case history and discussion timeline.
5. No clear commercial model
Specialist mentors were already providing valuable guidance, but the process was usually unpaid or handled manually.
The platform needed to support:
Per-case pricing
Mentor-defined fees
Platform commission
Paid private groups
Subscription access
Escrow-style payment handling
Mentor payouts
Refund and dispute scenarios
This commercial structure had to feel integrated into the mentorship workflow rather than placed on top of it.
Product strategy
Moving clinical conversations away from WhatsApp
One of the central product goals was to create a genuine replacement for informal messaging.
This did not mean simply rebuilding WhatsApp with a dental interface.
The platform needed to preserve the speed and familiarity of messaging while adding the structure required for clinical work.
Every discussion was connected to a specific case.
That case contained:
Patient context
Clinical question
Relevant specialty
Uploaded files
Consent status
Assigned mentor
Payment state
Discussion thread
Case timeline
Review status
This gave every message a clear context.
A mentor did not need to search through old chats to understand which scan or patient a comment referred to.
Designing around the case
The case became the central object within the entire product.
Almost every major feature connected back to it.
A case could be:
Drafted
Submitted
Awaiting payment
Sent to a mentor
Accepted
Rejected
Under review
Waiting for more information
Completed
Disputed
Archived
This status system helped users understand exactly what was happening without needing to ask for updates manually.
The case detail view included three main areas:
Discussion
Attachments
Timeline
This structure kept communication, documents and activity history separate but connected.
Case submission workflow
Creating a guided clinical submission
Submitting a dental case could not feel like uploading a general support ticket.
The form needed to collect enough information for a mentor to provide meaningful guidance.
The submission process was divided into manageable steps.
Patient and case information
The mentee could provide:
Patient age
Relevant medical history
Dental history
Presenting complaint
Clinical findings
Previous treatment
Treatment objective
Specific question for the mentor
Patient identification was deliberately minimized.
The product encouraged anonymized case information rather than storing unnecessary personal details.
Selecting the specialty
The case could be categorized by areas such as:
Implantology
Endodontics
Orthodontics
Periodontics
Prosthodontics
Oral surgery
Restorative dentistry
Paediatric dentistry
Oral medicine
General dentistry
This helped the system recommend suitable mentors.
Uploading clinical files
Users could upload a combination of:
DICOM studies
CBCT scans
STL models
PLY files
Intraoral photographs
Radiographs
PDF reports
Treatment plans
Supporting documents
The upload experience needed to communicate file type, upload status, file size and access permissions clearly.
Large medical imaging files required different handling from standard image attachments, so the interface was designed to show progress, processing state and availability.
Consent and confidentiality
Before submission, the user had to confirm that:
The patient had provided appropriate consent
Identifying information had been removed where required
The submission was for educational or consultative purposes
The platform did not replace emergency or direct clinical care
The user accepted confidentiality and professional responsibility requirements
These were not hidden inside a long terms page.
They were part of the submission workflow itself.
This helped make privacy and responsibility visible at the moment the case entered the system.
Selecting a mentor
The user could either choose a mentor directly or allow the system to recommend one.
Mentor profiles included:
Specialties
Qualifications
Credentials
Years of experience
Languages
Consultation fee
Response-time tier
Ratings
Number of reviewed cases
Professional introduction
Group or course offerings
This gave mentees enough information to make an informed decision.
Response-time tiers
Different cases required different levels of urgency.
The platform included response-time options that mentors could support, such as standard or priority review.
A faster service could have a different fee.
The interface made the expected response window visible before payment, helping reduce uncertainty after submission.
Mentor verification
Trust was one of the most important parts of the product.
A mentor could not simply register and begin charging for clinical advice.
The onboarding process required professional verification.
Mentors could be asked to submit:
Dental registration details
Specialist credentials
Professional certificates
Identification documents
Practice information
Areas of expertise
Supporting professional profiles
The application clearly separated:
Unverified users
Verification under review
Verified clinicians
Rejected or incomplete applications
Verified status was visible in mentor profiles and case interactions.
This helped mentees understand who they were working with and gave administrators control over who could offer paid mentorship.
DICOM and 3D dental file experience
Supporting clinical imaging
Dental case review often depends on imaging that cannot be represented through ordinary screenshots.
The platform therefore needed to support DICOM studies and 3D dental files.
The design included a viewer environment for:
DICOM series
CBCT studies
STL models
PLY models
Standard clinical images
The goal was not to recreate every function of a hospital-grade PACS system.
The viewer focused on the actions most relevant to remote mentorship and review.
DICOM viewer direction
The DICOM experience included space for:
Image series navigation
Zoom
Pan
Slice navigation
Window and level controls
Orientation labels
Image metadata
Full-screen viewing
File download controls
Mentor comments
The design kept the viewer visually focused because clinical images needed to remain the main object on the screen.
Supporting information and conversation could be accessed without covering the scan.
STL and PLY viewer direction
For implant, restorative and orthodontic cases, 3D models could provide essential context.
The 3D viewer experience supported:
Rotation
Zoom
Pan
Reset view
Model visibility
File information
Full-screen mode
Download permissions
The user experience used familiar controls and clear visual feedback, especially for mobile and tablet users.
Secure file access
Clinical files could not be treated as public media.
The platform required:
Authenticated access
Role-based permissions
Case-level access control
Secure storage
Time-limited access links
Download restrictions
Access logging
Automatic deletion rules
The planned retention policy included automatic removal of clinical files after a defined period, such as 30 days, depending on case status and platform policy.
This reduced unnecessary long-term storage of sensitive data.
Discussion and case review
Threaded clinical communication
The case discussion was designed as a structured thread rather than an open chat.
Messages could include:
Text responses
File references
Image attachments
Mentor recommendations
Requests for more information
Clinical observations
Treatment considerations
Follow-up questions
Users could reply to specific comments, making longer discussions easier to follow.
Reactions and status updates helped acknowledge messages without adding unnecessary replies.
Mentor actions
A mentor could:
Accept a case
Reject a case
Request more information
Add clinical feedback
Reference specific attachments
Schedule a live consultation
Mark the review as complete
Provide a final summary
Rejecting a case required a reason, such as:
Outside the mentor’s specialty
Insufficient information
Conflict of interest
Urgent care required
Case complexity
Availability
This prevented silent rejection and gave the mentee a clearer next step.
Final case summary
Completed cases could include a structured final summary.
This might cover:
Key observations
Possible treatment considerations
Risks
Recommended next steps
Additional investigations
Limitations of the review
Follow-up recommendations
The final summary did not replace the conversation.
It gave the mentee a clear conclusion after a potentially long discussion.
Mentor marketplace
Finding the right specialist
The mentor directory allowed users to search and filter specialists.
Useful filters included:
Specialty
Experience
Language
Fee
Availability
Response time
Rating
Consultation format
Group membership
The experience was designed to feel professional and clinical.
It avoided marketplace patterns that would make mentors appear interchangeable or price-driven.
Credentials and expertise were more prominent than promotional language.
Mentor profiles
Each profile provided enough detail for a clinician to evaluate professional suitability.
The profile could include:
Professional title
Biography
Qualifications
Specialist areas
Clinical interests
Registration status
Verified badge
Languages
Consultation fees
Response-time options
Ratings and reviews
Cases completed
Private groups
Courses or educational content
The design separated verified professional information from self-written promotional content.
Payments and mentor earnings
Per-case payments
Users paid before a mentor began the review.
The proposed payment workflow followed an escrow-style model.
The payment was authorized when the case was submitted and released according to the platform’s completion rules.
This helped protect both sides.
The mentee had confidence that payment was connected to a real service.
The mentor had confidence that funds were secured before investing time in the case.
Platform commission
DentalCase Connect could retain a percentage of each consultation payment.
The financial dashboard needed to make the following clear:
Case fee
Platform commission
Taxes where applicable
Mentor earnings
Payment status
Refund amount
Payout status
This transparency was particularly important for mentors managing several cases.
Paid groups and subscriptions
Mentors could also create private learning groups.
These groups allowed senior clinicians to build ongoing communities rather than only reviewing individual cases.
A group could include:
Monthly subscription pricing
Discussion channels
Shared cases
Educational posts
Live sessions
Documents
Group announcements
Member management
Mentor moderation
Payment enforcement was handled through the subscription system.
Users without an active subscription would lose access according to the group policy.
This introduced a recurring revenue model for mentors and the platform.
Groups and communities
Moving professional groups into a clinical environment
Dental professionals frequently participate in informal chat groups centred around hospitals, specialties, training programmes or departments.
The product considered scenarios such as a group for a particular ward, cohort or training community.
Instead of unstructured messages, DentalCase Connect groups could include:
Topic-based channels
Shared clinical discussions
Files
Announcements
Mentor-led sessions
Member roles
Subscription status
Moderation tools
Searchable history
Cases discussed inside a group could still follow the platform’s privacy and consent requirements.
This kept educational communities connected to the same clinical standards used elsewhere in the product.
Scheduling and consultations
Some cases required a live conversation.
The platform included scheduling functionality for:
Video consultations
One-to-one mentor calls
Group sessions
Case follow-ups
Educational events
The scheduling experience showed:
Mentor availability
User timezone
Session duration
Price
Case connection
Confirmation status
Meeting details
A consultation could remain linked to a case so users did not need to repeat the background during the call.
Ratings and professional reputation
After a case was completed, mentees could review the experience.
Ratings needed to be useful without reducing clinical mentorship to a popularity contest.
The review model could focus on:
Clarity of feedback
Responsiveness
Professionalism
Relevance of expertise
Overall experience
Only users who completed a paid interaction could leave a review.
This reduced fake or unrelated feedback.
Mentors could build reputation through verified activity, completed cases and consistent professional conduct.
Web app design
Role-based dashboards
The web application did not use one generic dashboard for everyone.
Each role saw a different product entry point.
Mentee dashboard
The mentee dashboard focused on:
Active cases
Draft cases
Mentor responses
Upcoming consultations
Inbox messages
Recommended mentors
Recent group activity
Payment status
The main call to action remained clear: create or continue a case.
Mentor dashboard
The mentor dashboard prioritised:
New case requests
Accepted cases
Cases waiting for response
Upcoming consultations
Group activity
Earnings
Response-time performance
Reviews
This helped mentors quickly understand what required attention.
Admin dashboard
The admin dashboard included:
Pending mentor verifications
User activity
Active cases
Disputes
Payments
Platform revenue
Reported content
File retention status
System notifications
Audit activity
The dashboard prioritised risk and operational actions rather than decorative analytics.
Authenticated-only product structure
DentalCase Connect was designed as an authenticated platform.
There was no need for a public content-heavy homepage inside the application itself.
Unauthenticated users were directed to login or registration.
Authenticated users were routed to role-specific dashboards.
This kept the product experience focused and avoided mixing the marketing website with the clinical application.
Mobile app design
Why the mobile app mattered
An actual mobile application was important because clinicians already used their phones for quick communication.
A web-only product would have made the switch away from WhatsApp more difficult.
The mobile app supported the actions dentists were most likely to perform away from a desktop.
These included:
Capturing a new case
Uploading chairside photos
Viewing radiographs
Recording patient notes
Receiving mentor responses
Replying to discussions
Checking case status
Joining consultations
Managing notifications
The goal was not to place every administrative feature into the mobile app.
The app prioritised clinical capture and communication.
Chairside capture
A dentist could begin documenting a case during or immediately after the appointment.
The flow supported:
Basic anonymized patient details
Clinical notes
Camera capture
Image upload
Radiograph attachment
Case categorization
Draft saving
Later completion from another device
This reduced the chance of important information being lost before the case was formally prepared.
Cross-device continuity
A case could begin on mobile and continue on web.
For example:
A dentist captured images and notes during the appointment.
The draft was saved to the cloud.
The dentist opened the same case later on a laptop.
Additional DICOM files and reports were added.
The case was submitted to a specialist.
This cross-device workflow made the product more practical in real clinical environments.
Notifications
Notifications were necessary, but they needed to be carefully controlled.
Users could receive updates for:
Case acceptance
Case rejection
New mentor response
Request for additional information
Payment confirmation
Consultation reminder
Case completion
Group activity
Subscription renewal
Verification status
Notifications were grouped by importance.
A clinical response required more visibility than a general community update.
The settings allowed users to control push, email and in-app notifications.
Privacy, permissions and clinical responsibility
Role-based access
Users only had access to the information required for their role.
A mentor could not browse unrelated cases.
A mentee could not access another user’s submission.
Group content was limited to active members.
Administrators had expanded access, but sensitive actions were logged.
Attribute-based policies
The platform also considered more detailed access rules beyond simple user roles.
Access could depend on:
Case assignment
Verification status
Group membership
Payment status
Subscription status
Case state
File retention period
Administrative permission
This created a more reliable access model for sensitive clinical content.
Audit trail
Important actions could be recorded, including:
Case creation
File upload
File access
Mentor assignment
Payment changes
Status changes
Administrative review
Deletion
Dispute actions
This gave the platform a clearer operational and compliance history.
Clinical disclaimer
The product was designed as a mentorship and consultation platform.
It did not replace emergency care, direct patient examination or the clinician’s own professional responsibility.
This distinction was communicated during:
Registration
Case submission
Mentor acceptance
Final case review
Terms and policies
The goal was to support clinical reasoning without presenting remote mentorship as a guaranteed treatment decision.
Design system
Creating consistency across a complex product
DentalCase Connect included several different product environments:
Marketplace
Case management
Messaging
Imaging
Payments
Groups
Scheduling
Administration
A reusable design system was essential.
The system included components for:
Navigation
Buttons
Form fields
Status badges
Case cards
Mentor cards
File attachments
Discussion threads
Timelines
Alerts
Payment summaries
Empty states
Modals
Filters
Tables
Mobile bottom navigation
Notifications
The design language remained calm, clinical and professional.
The product needed to feel trustworthy without becoming visually cold or overly institutional.
Status language
Clear status labels were particularly important.
The user needed to understand the difference between:
Draft
Submitted
Awaiting payment
Awaiting mentor
Accepted
Under review
More information required
Completed
Rejected
Disputed
Archived
Each state used consistent language and visual treatment throughout the application.
This reduced confusion across dashboards, case pages and notifications.
Responsive behaviour
The web application was designed to work across:
Desktop
Laptop
Tablet
Mobile browser
Different workflows were prioritised at different screen sizes.
Desktop was better suited for:
Detailed DICOM review
3D model viewing
Long case discussions
Administrative operations
Earnings and reporting
Mobile was better suited for:
Case capture
Messaging
Notifications
Quick file review
Consultation access
Tablet layouts were particularly important for clinicians who might review cases inside practices or teaching environments.
Development direction
Web-first architecture
The product direction prioritised a responsive web application for the full platform experience, while native iOS and Android apps supported clinical capture and day-to-day communication.
The architecture needed to support:
Shared user accounts
Cloud database
Secure file storage
Role-based authentication
Cross-device login
Payment integration
Push notifications
Scalable APIs
DICOM and 3D file processing
Admin moderation
Activity logging
The initial product direction considered rapid web development tools while keeping the system structured enough for a future migration into a more custom React-based architecture as the platform scaled.
Secure storage
Clinical files required separate handling from ordinary profile assets.
The backend needed to manage:
Large uploads
Upload progress
File validation
Processing status
Secure object storage
Signed access links
Scheduled deletion
Download restrictions
Backup policy
Access logs
The interface communicated each file state clearly so users knew whether an upload was still processing or ready for review.
Supporting the business
It would not be accurate to claim that the product design alone created revenue or user growth.
The value of the work was in transforming the concept into a platform that could support a real dental mentorship business.
Creating a clear marketplace model
The platform connected demand from junior clinicians with specialist expertise.
This gave the business a clear transaction model through consultation fees and platform commission.
Introducing recurring revenue
Paid groups and subscriptions gave mentors a way to build ongoing communities.
This also gave DentalCase Connect a recurring revenue opportunity beyond individual case payments.
Improving trust
Professional verification, structured case records, consent gates and secure file handling made the platform more credible than informal messaging.
Trust was essential for both clinical adoption and commercial growth.
Supporting mentor retention
Mentors had access to:
Paid cases
Group subscriptions
Scheduling
Earnings
Professional profiles
Ratings
Educational tools
This gave senior clinicians more reasons to remain active on the platform.
Supporting mentee retention
Mentees could use the product repeatedly as their clinical work developed.
Case history, trusted mentor relationships, group access and ongoing learning created reasons to return beyond a single consultation.
Creating a scalable platform
The product could later expand into:
Continuing education credits
Structured courses
Institutional subscriptions
Hospital or university groups
Dental practice accounts
Specialist networks
Research communities
Practice software integrations
The initial design system was created to support that future expansion.
The outcome
The final product direction turned DentalCase Connect into more than a messaging app for dentists.
It became a structured clinical mentorship ecosystem built around cases, verified expertise and secure professional communication.
The product included:
Multi-role onboarding
Clinician verification
Mentor marketplace
Guided case submission
Consent and anonymization workflow
DICOM file support
STL and PLY model support
Clinical image and document upload
Threaded case discussion
Case timeline
Mentor acceptance and rejection
Paid consultations
Escrow-style payments
Platform commission
Mentor earnings
Ratings and reviews
Paid private groups
Subscriptions
Scheduling
Notifications
Web dashboards
Native mobile app direction
Admin moderation
Secure file access
Automatic file retention controls
Responsive design system
The result was a clearer, safer and more commercially viable alternative to informal dental case discussions.
DentalCase Connect gave junior clinicians a structured way to access specialist knowledge, while giving experienced mentors a professional platform to teach, consult and earn from their expertise.
Services delivered
Product strategy
Competitor and workflow analysis
Information architecture
User-role definition
Mentee journey design
Mentor journey design
Admin workflow design
UX design
UI design
Responsive web app design
iOS app design direction
Android app design direction
DICOM viewer UX
STL and PLY viewer UX
Clinical case workflow design
Mentor marketplace design
Messaging and discussion design
Payment flow design
Subscription and group design
Scheduling experience
Design system
Developer handoff
Product QA support
Like this project
Posted Jul 13, 2026
Designed DentalCase Connect, a mentorship platform for dentists, focusing on secure, structured clinical communication.
Likes
0
Views
0
Timeline
Feb 11, 2026 - Mar 16, 2026
Clients
Dent & Go Ltd
