PHP代写：BIOM9450Web-basedMedicationManagementSystem

使用PHP代写一个医疗管理网站，对病人、药品、医生、预约情况等，进行管理。

Tasks

In this project you are required to design a web-based medication management
system that would be suitable for use by a nurse or qualified health
practitioner in an aged-care facility. You will not be given in-depth details
on how the tasks are to be achieved: that is up to your ingenuity, creativity
and perseverance. The medication database, as well all web pages in your
application should be your own design. However, essential user information
must be entered and validated and the referential integrity of the data
maintained. In addition, patient confidentiality is to be maintained via a
secure login feature.
As a starting point, your database design should include at least three
tables: a Medications table, a Patient table, and a Practitioner table. You
will very likely need other tables to tie all the information together - but
this is by your design!
The conceptual way such a system works is that a Web service running on a
remote pharmacy dispensing system populates the Medications table for all
residents in the aged-care facility for the upcoming week. The pharmacy also
delivers (in blister packs) the medications for each patient for each
medications round for the upcoming seven days. There are three medications
rounds: morning, afternoon and evening. The process is as follows:

1. A practitioner logs onto the system
2. A medications round (morning, afternoon or evening) for a particular day is selected.
3. A patient is selected from a list (possibly also displaying their picture).
4. Each medication for this patient is viewed and prepared and the medication name, dosage, route of administration (as a minimum) are displayed. The practitioner dispenses and acknowledges delivery of EACH medication for the patient. Medications do not always have to be given, so the system should record such options as: given, refused, fasting, no stock, ceased. The system should also naturally record the name of the dispensing practitioner.
5. Step 4 is repeated for each medication for this patient.
6. Steps 3-5 are repeated for all patients in the facility for which the practitioner is caring.
   It should also be possible for the practitioner to administer ‘Nurse Initiated
   Medication (NIM)’. A list of medications that are available for practitioners
   to administer, without a doctor’s order, should also be setup in a table.
   These drugs (such as panadol, anginine, gastrogel) should also be recorded for
   each patient if administered.
   It should be assumed that the medications data is available (i.e. has been
   sent automatically from the pharmacy). For the sake of this project you should
   choose to manually pre-populate the medications table with data for the
   upcoming week. You should also include data for the previous week and have
   dispensed the medications to various (at least four) patients by at least two
   practitioners. This will allow us to test the system and generate reports on
   medications usage.
   If you do not know about types of medication you can browse the web. Many
   medication databases are proprietary but there are some open source
   collections, e.g. http://medlibrary.org/drugs/index.html
   The practitioner table should include a user name and a password for each
   practitioner/administrator in the system. It can be assumed that this data
   already exists in appropriate tables (i.e. you do not need to create web forms
   to do this data entry). Besides patient name and a photo, the patient table
   should also include a field to describe what room the patient resides in the
   aged-care facility. The above patient data is to be entered into the database
   via an appropriate web page form.
   Practitioners should be able to insert new patient data into the database, as
   well as search, browse and edit data. In addition, practitioners should be
   able to view a flexible medications summary report that can be configured for
   either all patients or a single patient and can be retrospective (for past
   week) or prospective (for the upcoming week). This report should also be able
   to be sub-categorised by practitioner. A sample report from a significantly
   more complex web-based system is shown below to give you some ideas on report
   layout.
   Finally in order to track practitioner workload, you should include at least
   one chart (using TeeChart) showing an aspect of medication dispensing (for
   example, the number of patients each practitioner has seen each day over the
   past week). To do this download the TeeChart package from Moodle
   (TeeChart.zip), unzip it and place it in your G: drive. There is no
   installation required, as it only contains a bunch of PHP files for graphing.
   However, you will need to include some of these files using the following
   command, using a relative path from your PHP file: require_once("../TeeChart/sources/libTeeChart.php") ;
   If you are unsure about what directory PHP is working from (the directory from
   which relative paths are defined), use the command echo getcwd(); to display
   the current working directory on the page. It will be the directory of the PHP
   file which is running the PHP code. A sample php file to plot a very simple
   chart is included on Moodle to get you started.
   Server side validation of data should be performed using PHP. You may choose
   to also perform some client side data validation using JavaScript.

Report

You are expected to hand in a complete report detailing the tasks undertaken
and the approaches adopted, including database design and user interface
descriptions. This should include a brief “user’s manual”. It is not necessary
to print your PHP code (unless there are particular code snippets that you
want to make mention of as we will be accessing this from the server). Please
clearly explain which web page(s) to access to run your project. Also ensure
you include in your report the username and password of practitioners.
Ideally, the system should be complete and bug free. If sections of your
program do not work as expected, you should explain where and why the bug(s)
occurred, and what attempts you have made to track the source of the error.
Marks will be allocated for functionality, data entry checking, integrity
checking, innovative design, error free operation, etc.. If you develop the
system outside of the GSBmE computer lab you MUST check the full functionality
of the system on the GSBmE computer system (including database, web server and
browser). Many times we have had projects submitted that fail to work as
expected due to incompatibility issues.
Please make sure as part of the user manual you provide sample login usernames
and passwords so we can easily check your design. NB: A non-plagiarism
declaration form must be attached to your hand-in report.
Zip everything up and submit your files on Moodle but also leave the current
copy on your G: drive. All by the due date.
Proposed Marking Rubric (Total 100)

• Database (20)
  • Required data structures and data (8) [should be giveaway marks]
    • Patient (2)
    • Practitioner / Password protection (2)
    • Medications (2)
    • Prepopulated medication data for two weeks (second week not dispensed) (2)
  • Table design (6)
    • Normalisation, layout, overall design (2) [a general feel]
    • Data type selection (2) [using appropriate data types]
    • Constraints (2) [primary key, field constraints]
  • Relationships (3)
    • Justification (3) [a brief discussion in the report]
• Web functionality (30)
  • Login (3)
    • Username / password check (1)
    • Logout (1)
    • Behaviour, overall security (of all pages) (1)
  • Medication administration and dispensing (10)
    • Dispensing round (7)
    • Nurse initiated medications (3)
  • Practitioner tasks (10)
    • Inserting patient data (2)
    • Search/browse/edit data (2)
    • Display patient photo (may be pre-loaded into table) (3)
    • Medications report (3)
  • TeeChart plot or tabulation (4)
  • Navigation (3)
• Error checking and validation (15)
  • PHP server validation (and optional Javascript) of key fields (10)
  • SQL error handling (2) [1 for no SQL errors encountered, 1 for correct handling]
  • General user-friendliness of messages (3) [general feel]
• Web interface, design, presentation (20)
  • Web (15) [mainly a general feel for the interface, use of CSS, etc.]
  • Code (5) [style, comments, etc.]
• Report (15)
  • Tasks undertaken / approaches (5)
  • Website user manual (10)
  • (Note also 3 marks allocated for a description of the justification of the database/structures/normalisation in the Database section above)