A New Project: DoctorConnect

Welcome back!

Today I’m introducing a new project- again, mostly to help me learn stuff.  This one is a little more complex and will actually involve at least 2 and probably 3 sub-projects.  I call it DoctorConnect.

The theory is this: Assume that a Doctor’s office wanted to enable its patients to do some basic tasks online without having to call and wait for a nurse to call them back.  We’ve all had to do that, right?  You’re puking your guts out, and you have to wait for the nurse to call you back before you know if they can see you today (saving you $$$) or if you have to go to some Doc-in-a-Box Urgent Care place.

So: DoctorConnect.

It will be a system in 3 parts: A database (SQL Server 2008 R2), an internal web application (haven’t decided on MVC or Web Forms, yet) and an external web page.  After all that’s done, I may also design a mobile-app for the project: so users could schedule an appointment on-the-go.

This is a big project for me, and I’m going to have to master some things that I haven’t mastered yet before I get it right.

First: The DB.  I’ll need to map my DB tables to Objects.  This is complex enough a data model (more on that in another post) that I don’t fully trust EF, and I don’t trust my own skills at Linq-2-SQL enough.  So I’ll be looking at various ORM options to determine the best way to go.

Second: Membership.  Unlike the Issue Tracker, this will require a custom membership provider: I’ll need to know not only if someone is an authenticated user, but exactly what things they should be able to see.  On the internal application, that may be role-based, but on the external application, it will have to be something else- some hierarchy model that allows for a Responsible Party to see all the accounts for which he (or she) is responsible, but let other patients see only their own accounts.

Third: Polymorphic Data.  What I mean is this:  A patient, when scheduling an appointment, doesn’t need to know all the information about a specific doctor, just their name, specialty (so they don’t go see an OB/GYN about their prostate), and availability.  On the other hand, the Office Staff need to know just about everything about a patient.  How should I handle that?

Fourth: Scheduling.  I’ll need a way to set an appointment for a doctor and validate it against other scheduled events: we don’t want patients to be able to schedule an appointment during lunch, for instance, or while that doctor is on vacation.  So I’ll need to figure that out.

All in all, this is shaping up to be a big project.  So let’s start eating this elephant: one bite at a time.  Next up: the data model.