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
)