Discuss on ERD about skeleton HOT 11 CLOSED

Hey, @deepu9 simply put, I built reliqui to help my local hospital to provide the easiest service for outpatients. https://reliqui.github.io

The problem that often occurs in the hospital is the outpatient spend a lot of time waiting for the queue to meet with the doctor. so I think the good solution is to make an appointment with the doctor, but it's not as easy as we imagine when dealing with hospital procedures.

After conducting studies to several hospitals, I found the same pattern of procedures so I found some workable solutions.

• Physical Appointment: Schedule a physical meeting with a doctor.
• Multiple Healthcare Provider: The hospital can have branches in each area so that the patient's data is more centralized.
• Health History: doctors can prepare what to do before dealing with outpatients. so it can save service time.

After a deeper dive, I found a more complicated problem when the patient used insurance. outpatients should be verified with difficult forms and other verification. In my local hospital case, always have thousands of reasons that the technology is so expensive for them to apply.

So what we should try to do is offer a solution for the hospital, clinics, small health services, so they can provide the best and easiest service to society.

from skeleton.

@deepu9 I think Laravel framework actually creates relationships for you ? I'm not sure I'm really out of the loop with this project hoping to jump back in asap.

from skeleton.

Hmm, It's a bit complicated. Correct me if I'm wrong.
As you all know database tables will have relationships using foreign keys. Those are the real relationships.
What Laravel does is add an ORM layer/wrapper to communicate with database tables. So if database tables have relationships, then Laravel ORM should also follow the same relationships in order to do CRUD operations on the database.

from skeleton.

Hey, @deepu9 are you really run reliqui on your local dev? and already tried existing features?

from skeleton.

Yes I did. Please find the screenshot

from skeleton.

Hi David,
Can you share with us the vision of Reliqui. In addition to it, can you also provide the list of MVP features. This will let us know more about Reliqui. Thanks

from skeleton.

Hi David,
Correct me if I'm wrong.
Entities:

• Doctors
• Patients
• Staff - Includes administration and non-administration staff, but not doctors.
• Health Histories
• Appointments

May I know why we need the following entities:

• Specialties - When you say specialties, are you referring to Hospitals/Clinics?
• Invitations
• Schedules
• Groups

Not sure about the following entities:

• User - I think this is for Admin/Super Admins

Can you let me know. Thanks

from skeleton.

Hey @deepu9

• Specialties: No, doctor belongs to 'specialities' not to hospital/clinic.

• Invitations: to store invitation data.

• Schedules: doctor hasMany schedules

• Groups: for multiple hospital/clinic

• Users: to store all users for authentication purpose.

P.S. patients not always user, user can have multiple 'patient form' for register their family like my grandpa, grandma, etc.

from skeleton.

Thanks @davidhsianturi
When you say doctor belongs to 'specialties', you mean the doctor has specialties, is that right. If that's the case, don't we store those data in doctors table?

Can you explain why we use Invitations in reliqui?

When you say doctor hasMany schedules, you mean many appointments, if that's the case, we have a separate table for appointments.

May I know why you have named Groups for multiple hospital/clinics. Can't we name the table more descriptive like Hospitals.

Doesn't patients table store username and password? If we store just username and password in Users table and remaining data in Patients table, it will involve another SQL query and resources to pull the data for a user/patient.

You also refer Patient form, may I know what do you mean by it?

Sorry to ask too many questions. Without a full understanding of the system, it's hard for me to build a feature or fix a bug. Thanks for answering my questions.

from skeleton.

Hey @deepu9
yes, we do not know what specialties the doctor has for the hospital, so let the hospital provide the data.

Every user should be invited by the owner, if not how the owner has staff?

Yeah, honestly naming that's table is easy-hard, I prefer groups because usually, the health service consists of groups that have many branches in each region.

Of course, that's approach can be done. in order to always remain consistent, we only need one table for user authentication.

Like I said before, patients not always the user, a user can have multiple patient form to register their family like my grandpa, grandma, etc. and the data is stored into the patients table.

Yeah, thanks for you, this issue is very helpful, at least newcomers can understand what we are trying to build here.

from skeleton.

@davidhsianturi
I understand hospital will know their staff specialities, but that has nothing to do with Hospital table. Don't worry about who adds data to the platform. When we discuss database tables, we should be looking more at how a table store data, what relationships does it have with other tables. Don't worry about who does the data entry.

For this, I think we don't need a separate table for Specialities, as they will get stored in Doctors table. Am I right?

May I know what you mean when you say Owner? To my knowledge the only users this platform has Admin, Super Admin, Doctor, Patients and Staff(Administration). So who is this Owner and what's the role in this platform?

What's the difference between Appointments and Schedules? I think they both are same.

May I know what do you mean by health service consists of groups that have many branches in each region? Health services have branches, I understand that but what is a group?

When you say patient form, I think you are combining View with database tables. Patient form registration is View stuff and this has nothing to do with Patients table.

Take your example of a user can have multiple patient forms to fill their family members, so you mean to say a user admitted his/her family members. Then we don't discuss the user who fills the form, as he isn't the patient. We only care about the patients(user family members) and store their data instead.

Thanks for your patience in answering my questions.

from skeleton.