If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > Clinic Management System

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
Clinic Management System

Below are the steps of how my basic clinic management system will flow. Please help to comment.

Clinic Flow Chart:

1. Patient approach the counter (manually)
2. Patient provides IC to the nurse (manually)
3. Nurse searches the patient details (automated)
4. If the patient details is found
4.1 Nurse add the patient to the waiting list (Red Color) (automated)
4.2 The patient visits the doctor (manually)
4.3 The doctor reviews the patient history (automated)
4.4 The doctor prescribes the medication for the patient (manually)
4.5 The nurse records the information (automated)
4.5.1 The waiting list is updated (Yellow Color)
4.6 The patient approach the counter and make payment (manually)
4.7 The nurse provide the patient with the receipt & MC (automated)
4.7.1 The waiting list is updated (Green Color)
5. If the patient detail is not found
5.1 Nurse add new patient record (automated)
5.2 Nurse add the patient to the waiting list (Red Color) (automated)
5.3 The patient visits the doctor (manually)
5.4 The doctor reviews the patient history (automated)
5.5 The doctor prescribes the medication for the patient (manually)
5.6 The nurse records the information (automated)
5.6.1 The waiting list is updated (Yellow Color)
5.7 The patient approach the counter and make payment (manually)
5.8 The nurse provide the patient with the receipt & MC (automated)
5.8.1 The waiting list is updated (Green Color)

Manually: 7 Automated: 9

Your help is kindly appreciated.

Thank You.
Reply With Quote
  #2 (permalink)  
Old
World Class Flame Warrior
 
Join Date: Jun 2003
Location: Ohio
Posts: 12,556
My comment is that you are making the all too common mistake of modeling the process before modeling the business.
Build your application upon a process model and it will be obsolete whenever the process or requirements change. Build it upon a data model and you can handle whatever processes the client requests.
__________________
If it's not practically useful, then it's practically useless.

blindman
www.chess.com: "sqlblindman"
www.LobsterShot.blogspot.com
Reply With Quote
  #3 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
Well actually this is part of the business requirement:
1. Identify the Business Problem
2. Modularization (Hierarchical chart)
3. Use case - (diagram, expended, high level) UML

The information I have given "Clinic Flow Chart" is the flow of the business. Some of the steps in the flow can be automated to solve the business problem.

Last edited by solomon13000; 07-16-09 at 13:22.
Reply With Quote
  #4 (permalink)  
Old
Resident Curmudgeon
 
Join Date: Feb 2004
Location: In front of the computer
Posts: 14,742
The business' problem is that they don't seem to understand their own business. If they are hiring a consultant with a business requirement like that, then they are as clueless as some of the folks that I've seen trying to teach IT and business analytics courses without ever having worked in an actual business.

Since their requirement is focused on things discussed in textbooks instead of actual business needs, I suspect that whoever drew up the requirements has little or no understanding of the business process and is merely mimicing what they were taught in an introductory class. I'm sure that they mean well, but dealing with a business like that is dangerous to your professional reputation. I would avoid them at any cost, including being willing to simply tell them that they need to hire another consultant because I can't help them.

-PatP
__________________
In theory, theory and practice are identical. In practice, theory and practice are unrelated.
Reply With Quote
  #5 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
Build it upon a data model and you can handle whatever processes the client requests.

But this will fall under the analysis and design stage right. Then the nerds can pick up the deliverables and make a program out of it.

Last edited by solomon13000; 07-16-09 at 13:50.
Reply With Quote
  #6 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
The "Clinic Flow Chart" is just a personal understanding of how the business is running manually. This data can be collected using interview, observation and so on. Creating a business is a different. But in this case it's about introducing business process automation to an existing clinic that does their work manually.

The business' problem is that they don't seem to understand their own business.

To much of paper usage can be considered a business problem as an example.
Archiving to many patients record in a cabinet can be a business problem.
Searching a patients record in a bulk of files in a cabinet can be a business problem.
Creating duplicate copy of the patients information can be a business problem.
Human error can be a business problem.
.............

Last edited by solomon13000; 07-16-09 at 14:04.
Reply With Quote
  #7 (permalink)  
Old
World Class Flame Warrior
 
Join Date: Jun 2003
Location: Ohio
Posts: 12,556
Quote:
Originally Posted by solomon13000
Build it upon a data model and you can handle whatever processes the client requests.

But this will fall under the analysis and design stage right. Then the nerds can pick up the deliverables and make a program out of it.
...and you will end up with a process-based application that will be a very limited, very crappy design.
__________________
If it's not practically useful, then it's practically useless.

blindman
www.chess.com: "sqlblindman"
www.LobsterShot.blogspot.com
Reply With Quote
  #8 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
so what is your proposal for requirement gathering?.
Reply With Quote
  #9 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
The UML concept - that is the use of use cases indicate the action to be performed by the user of the system as well as the response from the system as a result of the user action. It is a process and will be done during the requirement gathering stage. Therefore will this make the analysis and design stage:

very limited, very crappy design.
Reply With Quote
  #10 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
My comment is that you are making the all too common mistake of modeling the process before modeling the business.

Modeling the business?
Reply With Quote
  #11 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
Business Problem

1. Use lots of paper to keep the patient information.
Need space (Cabinet for filing)

2. Problem in searching the patient records.
Wrong placement of information

3. Human error
Wrong patients detail entered (DOB)
Patient re-registration

4. Doctor’s availability
Schedule (Date & Time)

5. Security problem.
Patients privacy

6. List of patience in the waiting list
Preferential treatment

7. Information Sharing
Communication between clinics

8. Standardization
Documentation (Invoice & MC)

Goals to Achieve

1. Store information into database
It can store million of information
Data is stored in a more organized manner

2. Provide the ability to search the information base on criteria
Use IC number to search patient records

3. Less typing of information
Select information from combo box

4. Provide the schedule
Doctor’s in duty

5. Provide restriction for information access
Provide the username and password

6. Organize patients in a sequential order
First In First Out

7. Provide information sharing
Patient information

8. Provide standard documentation
Document Format
Reply With Quote
  #12 (permalink)  
Old
World Class Flame Warrior
 
Join Date: Jun 2003
Location: Ohio
Posts: 12,556
Quote:
Originally Posted by solomon13000
My comment is that you are making the all too common mistake of modeling the process before modeling the business.

Modeling the business?
Think Entities (Doctors, Patients, Schedules, Facilities, Treatments...)
Think Attributes (Names, Addresses, Dosages....)
Think Relationships (Nurses belong to Hospitals, Doctors may server multiple facilities, Hospitals have many patients, Patients receive many treatments....)

1) Design a Logical Entity Relationship Diagram to describe the business model.
2) Transform the Logical ERD into a Physical ERD and implement it in a database.
3) Create and application to enable the user to navigate and manage the data in the course of their duties.
This is data-centric development, and is much more robust than starting with Use Cases and Wireframes.
__________________
If it's not practically useful, then it's practically useless.

blindman
www.chess.com: "sqlblindman"
www.LobsterShot.blogspot.com
Reply With Quote
  #13 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
I am using the waterfall model:

1. Business problem & Goals to be achieved
2. Analysis & Design
3. Implement
4. Testing
5. Maintainance

Base my UML reading I found that when we are doing the analysis, we can come up with the use case diagram, expended use case and high level use case. This can be prepared by the business analyst who is probably a highly sociable person. After doing this then we do the design such as class diagram, pseudo code, flow chart and so on to describe the business problem.

Also during the Business problem & Goals to be achieved stage, we can perform modularization of the business problem. Each modules can be represented in the use case diagram under the analysis stage.

Please comment.

Last edited by solomon13000; 07-17-09 at 22:56.
Reply With Quote
  #14 (permalink)  
Old
Registered User
 
Join Date: Oct 2006
Posts: 29
This is data-centric development, and is much more robust than starting with Use Cases and Wireframes.

So after creating the ER diagram and implementing it in the database, then I can start with the use case diagram, expended use case and so on?.
Reply With Quote
  #15 (permalink)  
Old
World Class Flame Warrior
 
Join Date: Jun 2003
Location: Ohio
Posts: 12,556
That is what I would recommend. If you design your model correctly, it should be able to support all your use cases with little or no modification or enhancement.
__________________
If it's not practically useful, then it's practically useless.

blindman
www.chess.com: "sqlblindman"
www.LobsterShot.blogspot.com
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On