Project Overview & Vision
PhysicianConnect is a centralized platform that simplifies communication between patients, physicians, and receptionists. We aim to reduce administrative friction, improve communication, and make it easier to manage appointments, billing, prescriptions, referrals and patient data in one place.
Physicians can set their availability, review pre-visit notes, and handle post-visit tasks like writing prescriptions, making referrals, and logging follow-ups all in one place. Patients can easily book appointments, receive updates, and access their medical information. Receptionists gain tools to coordinate visits, handle billing, and keep the clinic running smoothly.
Fast, focused, and secure, PhysicianConnect cuts through the complexity of traditional EMRs so clinics can stay organized and deliver better care with less time spent on paperwork and more time focused on people.
Intended Users
Physicians, who need quick access to patient records, appointment schedules, prescribe medicine, managing patient referrals and internal messaging.
Receptionists, who handle appointment management, billing tasks, internal messaging and act as a bridge between patients and medical professionals.
Major Functionality
- Calendar-based schedule management with availability blocks
- Instant syncing of patient-booked appointments
- Pre-visit notes & history at a glance
- Medication prescription with dosage instructions
- Notification & alert system for doctors and patients
- Post-visit documentation: notes, prescriptions, and referrals
- Live messaging/chat between doctors and patients
- Billing & invoicing with patient-level detail
- Profile management for staff and users
- Secure, role-based data separation for doctors & patients
- Receptionist view with limited admin access
Feature Demo
Contributors
- Gagandeep DollaThroughout the project, I focused a lot on maintaining clean Git workflows, managing feature branches, resolving tricky merge conflicts, and keeping our history organized. I also worked on writing meaningful tests using JUnit, which helped improve reliability as we added more features. Since we were working as a team, I got to apply what I’ve learned from past courses and work experience about writing modular, testable code and making sure my changes integrated smoothly with everyone else’s work. This project really helped me sharpen those collaboration and debugging skills that matter in real-world development.
- Mohammad Islam MujahidulTaking the summer version of 3350 gave me a good idea of how teams usually work day to day, since we were putting in hours similar to a normal job. Working with tight deadlines brought out a level of productivity in me I didn’t know I had. I learned most about persistence from 3350, since I didn’t take 3380. I also got a much better understanding of why testing is important and how to actually do it properly, something I almost completely ignored in older projects. In terms of implementing features, while my mindset was initially focused more on just building things, I gradually shifted toward writing code that followed solid principles. Planning features with user stories helped me structure ideas better, something I will keep using as a tool for future projects. I also got solid experience with Git, like handling branches, fixing merge conflicts, and working in a shared repo.
- Pankaj Jhanji I think for me it would definitely have to be learning to get into a more leadership role/ QA role. Learning to go through other people’s code and leave feedback as a TA but this time around I was able to have a back and forth with them which was very nice, alongside that there was also the idea of finding bugs and assigning tickets, having to jump into various parts of the project to help out wherever I could. All these were very fun skills that I think developed further.
- Arjun SarkarOne specific development skill I gained through this project would be learning how to manage and fuse feature branches effectively in a team environment. Even though I was familiar with Git before, through this project it taught me how to manage more complex workflows that involve working with multiple contributors, code reviews and merge conflicts. I am getting better at writing cleaner commits, discussing merge conflict issues with the team and structuring branches logically. Another useful experience I gained working in this project is working with a variety of user types such as physicians, and receptionists (and patients too but time didn’t permit us to do so). It is cool to view each user’s unique views and permissions. To me, testing and building these user types assisted me into thinking deeply about access control, user interface, authentication and overall user experience. It made me think critically about how each feature as well as user stories should behave depending on who is using it.
- Ibrahim MammanThis project gave me a much stronger understanding of how Git works in a real team setting. Before this, I had only used Git in a basic way, but now I feel confident using branches, resolving merge conflicts, and contributing to a shared repo. I also learned a lot about teamwork—how to communicate effectively, coordinate tasks, and make sure everyone's changes fit together. On top of that, I really came to appreciate the software development cycle, especially Agile. I liked the rhythm of working in sprints, writing user stories, and regularly checking in to adapt our plans. It made the whole process feel more organized and productive.
Development Post‑mortem
What was the overall architecture of your system (particularly if it is different from the
demo system)?
Our system followed a MVC (Model-View-Controller) structure, which means we kept the logic, the
interface, and the data in their own parts, which made it easier to update and test. It was more
organized than the basic demo system we saw in class.
What went right in the development process?
We did really well at communicating as a team and keeping each other updated through daily
check-ins. Our Git branches were well-named, our commits were clear, and we were careful about
testing before merging code into the main project.
What went wrong in the development process?
At first, we ran into problems with merge conflicts because we didn’t always test or review things
before merging, which caused bugs and delays.
What would you do differently, if you had the chance to start over?
If we could go back, we would plan out all the user roles, features, and implementations in more
detail before we started building, so technical debt would have been much less than it was.
How large is the project (number of methods, classes, etc)? How much of this is (roughly) devoted to each major system component? And any other quantifiables (e.g. if you have a record of hours spent on tasks).
Overall Project Size
Total Classes: approximately 60 - 65 classes
Total Methods: approximately 200 - 250 methods
Major Components: 4 Main System Components
Component Breakdown
Presentation Layer (~40% of codebase)
UI Components (Panels, Windows, Dialogs)
Main classes: PhysicianApp, ReceptionistApp, LoginScreen
UI Utilities: UITheme, UIConfig
Various specialized panels for different functionalities
Persistence Layer (~30% of codebase)
Database implementations (SQLite)
Stub implementations for testing
Classes: AppointmentDB, PhysicianDB, MessageDB, etc.
Factory classes for persistence management
Business Logic Layer (~20% of codebase)
Manager classes: AppointmentManager, PhysicianManager, ReceptionistManager
Service classes: MessageService
Validation classes: PhysicianValidator, PrescriptionValidator
Domain Objects (~10% of codebase)
Core business entities: Physician, Receptionist, Appointment, Prescription, etc.
Supporting objects: TimeSlot, ServiceItem, Invoice, etc.
Key Features Implementation
Appointment Management
Physician/Receptionist Management
Messaging System
Billing and Invoicing
Prescription Management
Referral System
Notification System
Architecture Patterns:
MVC (Model-View-Controller) pattern
Repository pattern for data access
Factory pattern for object creation
Observer pattern for notifications
Testing Coverage
Test classes present for UI components
Mock implementations for testing
Unit tests for core functionality
What took the most time? The least? Any surprises?
Appointment Slot Management and Notifications were the most time consuming features in our project.
Creating the notification feature was surprisingly a big hassle, and although its functionality
worked, we were not able to make it work across two separate instances of the application at once
and had to resort to creating two.
Are there any particular design smells, or brilliant design decisions?
One glaring design issue is that our physician and receptionist app components in the presentation
layer are handling too much logic, which violates the Single Responsibility Principle. To address
this, we plan to refactor them to better follow SOLID principles, improving maintainability and
separation of concerns.
Are there any outstanding bugs?
To test messaging and notifications, we currently open two account dialogs within a single instance
of the application. This setup leads to duplicate messages and alerts across the board. We haven’t
yet found a way to share the database across multiple instances of the app, which would better
reflect a real-world scenario where different users run the app independently.
Did any features work better than expected?
Yes, our appointment slot management views have been a valuable addition to the project and are
truly one of its standout features. They provide an amazing interface for managing availability,
scheduling appointments efficiently, and minimizing conflicts—making them central to the overall
functionality and user experience of our application.
Are you using any technologies other than what was required (e.g. JMock, GUI builders,
etc.)?
No, we adhered to the required technologies and did not use any additional tools or frameworks
beyond what was specified.
Are you using any specific techniques covered in the course (TDD, pair programming, scrums,
etc)?
We used test-driven development (TDD) for key parts of the logic, pair programming for trickier
sections, and Scrum ideas like sprints and weekly check-ins to stay organized.
How did the project change from your initial (iteration 0) vision or stories, or did it work
out as predicted?
Initially, we planned to design our app for both physicians and patients. However, upon feedback, we
realized it didn't make sense for patients to use such a system directly. Hence we shifted our focus
to creating an app for physicians and receptionists. This led to the development of features like
billing and an overall appointment view of all physicians, and we modified some existing
patient-related functionalities to better suit the receptionist's role.
What did you learn about team or large project development? What will you start doing, keep
doing, or stop doing next time?
We learned that it’s super important to break down tasks, keep communication strong, and avoid big,
risky changes late in the process.
Can you draw any conclusions from what you’ve done?
In the end, we learned that with solid teamwork, good planning, and patience through challenges like
bugs and merge issues, it’s possible to build something useful and reliable as a group.