Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    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.

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,566
    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

  3. #3
    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.

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    14,910
    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.

  5. #5
    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.

  6. #6
    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.

  7. #7
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,566
    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

  8. #8
    Join Date
    Oct 2006
    Posts
    29
    so what is your proposal for requirement gathering?.

  9. #9
    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.

  10. #10
    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?

  11. #11
    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

  12. #12
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,566
    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

  13. #13
    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.

  14. #14
    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?.

  15. #15
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,566
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •