Mongodb schema review and suggestion needed(I am new in document DB)

Hey, I am very new to NoSQL. I have made a model for my college project. I just want a critical review of that model.

Project Description

Simple appointment app for N number of doctors/patient/lab/medical and get an appointment. moreover, doctors and patients should be able to search for medicine and lab test in medical and labs.

Here Are Project Requirements

End-User

  1. Doctor
  2. Patient
  3. Medical
  4. Laboratory

Doctor

  1. manage appointments detail for patients, I am assuming each patient will take 15 min in basic diagnosis. som this will be their Appointment. after arriving at the doctor’s clinic they don’t need to wait more than 15 min.

  2. get information about patients like reports, medicine, an old visit from other doctors. this will be each patient profile. I am thinking of making a profile sub-doc and diagnosis collection.

  3. if doctors got into an emergency they could simply click a button to let know the appointed patient that they will be late for rescheduling the appointment auto(the doctor will let know how much time he/she is at emergency as per that time).

Patients

  1. Search and Find a Doctor/medicine/lab nearby them as per their need, see info about the doctor like specialty, time, is he/she free for an appointment, fees.

  2. add family members. and pay for them.

  3. find medical that has all the medicine patients need.

  4. find a lab that has test patient needs.

Medical

  1. inventory for their own store. allow patients to access this store’s inventory only as read mode.

  2. there are N stores and each store has N medicines.

  3. get an order from the patient.

labs

  1. each lab has a test list for its own lab. allow patients to access this list only as read mode.

  2. there are N labs and each store has N tests

  3. get an order and appointment from the patient. the patient can get an appointment for a test. or each patient could have an appointment for multiple tests.

Download My Model

Download Software to Open File

Hi @Owais_Qureshi ,

Welcome to MongoDB community.

Thanks for the detailed explanation on the application requirments as this is the main thing we need to consider when designing a schema, the relationship between the different users and the needed data + the access patterns.

I will provide my idea of the high level schema that I am thinking off for your use case and you can followup.

I will recommend to consider MongoDB Atlas and MongoDB realm services when designing such applications due to the multiple features they allow : Authentication and rule based access, easy database management, triggers, Atlas full text search and serverless capabilities and end points… Read more here:

Overall the schema you defined looks more relational in its concepts than a MongoDB like design.

I believe you should define the following collections and embed some of the data in those collections rather than referncing everything, I might not fully understand the meaning of collections and documents but I believe you should use the document datatypes as embeeded documents in collections.

Let me specify my collections :

Users

{
_id : ...,
username : ...,
password : .SHA256(...) ,
user_type : ["doctor"] // In case a user can have several roles, 
profile : {
   email : ... ,
   
} ,
address : [ ],
related_users : [ { userId : ... , username : ... , "relationship" :  ... } ... ],
// Next fields are existing per usertype
doctorAvailability : [ { clinicId : ... , "clinicName" : ... , "close" : ... , "open" : ... , "days" : [ "monday" ] } ... ],
latest10Appointments : [ { appointmentId : ... , legal_name : ... , clinicName : ... , date : ... } ... ],
...
}

As you can see all the users in your schema has related data and has some relationships with a distinguish by type of user. Obtaining that type in the login flow will push everyone to a different data access layer to get the relevant pages for them.

For example a doctor can see his upcoming appointments and when he has emergency scheduled by query of “appointments” or “EmergencyInfo” and editing them.

Patients can have their upcoming schedules and an option to search for available doctors/labs or medicals based on the address geo field.

Appointments

{
_id : ... ,
doctor : { 
   userId : ... ,
   legal_name : ..., 
  address :  []
}, 
// or lab
service :
 { 
   userId : ... ,
   legal_name : ..., 
  address :  []
},
paitiantId :  ... ,
date: ... ,
summary : ... ,
orders : [ { labId : ... , testId :  ... , } , { medicineId : ... , precription :  [ {} ] } ]
...
} 

Appointments closes the relationship between a located doctor/lab. a closed appointment can have the orders provided to that user from that appointment. Those could be medicine or test required.

EmergencyInfo

{
 _ id : ... ,
 doctor : { 
   userId : ... ,
   legal_name : ..., 
  address :  []
},
emergencyStart : <DATE>,
emergencyEnd. : <DATE>
}

Whenever the application tries to book an appointment it checks that there is no appointment booked on the timeframe of the requested time and that there is no emergency document that intersect with that time.

medicalProducts

{
   _id : ... ,
  name : ... ,
  type : ... , 
  company_name : ... ,
  <OTHER DETAILS>
}

Since medical products such as testNames and their propose or medicines are probably shared across institutions it make sense to store them externaly and use “extended reference” to embed some basic information in a service inventory or provided service.

ServiceInventory

{
_id. : ...
serviceProviderId :  <ID LAB/MEDICAL>
type : "labTest",
availability :   [ { clinicId : ... , "clinicName" : ... , "close" : ... , "open" : ... , "days" : [ "monday" ] } ... ],
price: ...,
address :  []
}
// For medicine it will look:
{
_id. : ...
serviceProviderId :  <ID LAB/MEDICAL>
type : "medicine",
quntantity : 100, 
price: ..., 
address :  []
}

This holds the inventory for available medical products classified by their provider (Medical or Lab).

testResults:

{ _id : ...,
doctor : { 
   userId : ... ,
   legal_name : ..., 
  address :  []
}, 
testOrderId : ... ,
paitiantId :  ... ,
service : {
  "labId" : ..., 
   "labName" : ...,
},
result : [ { ... } ]
}

A test results hold the provider output per a patient and the doctor information to inform the doctor on the results if needed. Doctor can locate also possible results by their ID.

Let me know if this schema make sense to you.

I suggest to read:

Thanks
Pavel

The Green ones are subdocuments and the blue ones are collections.

  1. me & my team have decided to make the REST API and then implement it to create a web App.

  2. this web app is considered an e-commerce app.

  3. in this app all doctors/lab/medical will provide some service. whereas the patient is a consumer.

  4. doctor/lab will provide an appointment. whereas medical is only used for searching if the medicine is available or not. and if the medicine is available patients can order them and pick them up by themselves ( yes no delivery system . it’s just a college project, not the real world. :sweat_smile:)

  5. each medical could have multiple medicines they will repeat. should we allow multiple?

  6. my question is if we embed documents in the parent document should not be concerned about the 16 MB limit.

@Owais_Qureshi ,

If you make sure not to inflate documents (having lots of elements in arrays ) why should you reach 16mb limit?

Please read on the outlier pattern to have better perspective:

Thanks
Pavel