Amber Beebe

Michael Janes
Ericka Koyama
Justin Thomas
5/26/20

Project 1 Part One: Data Design

The goal of this project was to design a simple, scalable, backend system for a data entry
application. We have to identify all relationships and required columns while recognizing
potential design flaws when writing queries in Java. We wanted to make the database as
flexible as possible, while also having it as normalized as possible.In order to achieve that we
broke down some of the major databases into sub databases, such as having the contract text
be in its own databases ince the info will be accessed infrequently. The final result of our work is
a relational diagram which demonstrates how this data will be stored, updated, and accessed by
the users and applications which interface with it.

The relationships between all of the entities were one-to-one, one-to-many, and in some cases
many-to-many. In the case of many-to-many relationships, we used a linking table in between
both entities, so that each entity could have a one-to-many relationship with the linking table.
We noticed that each doctor can have many patients, but one patient only had one primary. This
doesn’t exclude patients that may have specialty doctors like an ENT (ear nose throat
specialist). We decided that a primary care doctor is different from a specialist and this company
was only interested in primary care physicians. Another key concept we decided on using
varchar instead of an integer for phone numbers; we used varchar to accommodate the
formatting for parts of the phone number, like the parentheses around the area code and
potentially international formats. This should also help when querying and joining on this value
since we can just use a regular string format.

A shared concept we standardized across all tables was a unique key index in addition to
possible primary keys such as social security number. Although each doctor’s and patient’s ssn
was a uniquely identifying attribute, we decided to use an auto-incremented ID column and use
that as a primary key. This allows us to query for an item with revealing the social security
number as a primary key. The final result allows all items to be unique and auto incremented.
An important takeaway from this project was to include naming convention and schema design
as a part of the group planning. There was variance amongst the names of tables, keys, and
indexes in each model produced by a different group member. Something that might have
become a complicated issue when trying to build modular code for the front-end application.
Project 1 Part Two: Web Application

Our goal for part two was to implement the normalized schema we created for part on and
create a web application that can be used with sample data. The web project was developed
using a combination of Java and Spring Boot Tool. The pattern used was MVC where the model
represented results from a query passed to the view. The view was html that displayed the
model, and the controller was used for connecting and querying the database. Input is given in
the view from the user, passed to the controller - where the database was queried - and the
controller created a model based on the results which was then passed to the view to be
displayed. To test all the functionality, we created a home page that listed all the pages where
user input was needed.

We faced multiple challenges during the implementation phase of the web application. The first
issue some of us faced was dealing with a new development environment and tools such as
Spring Boot. This was just a learning process, but took a little bit of time to understand how to
successfully use the tool. The second issue we faced was undefined requirements that are
necessary for the application to function correctly. Prescription number was a requirement that
was undefined, for this we used a combination of doctor_id, patient_id, and drug_id. This
allowed us to query the required tables for filling the prescription and was combined using ‘-’ for
parsing reasons. Once the drug_id was parsed, we had to find the pharmacy that the patient
wanted to use the prescription at. This was also undefined so we assumed during the
prescription creation that the customer would have a preferred pharmacy that indicated the
pharmacy where they want to pick up the prescription. Normally the doctor would ask where to
fill the prescription at and a directory listing would appear for the doctor to select. This wasn’t
part of the project scope so we defaulted to a preferred pharmacy when looking up the drug
price. Because of the restricted sample data, there may be instances where the preferred
pharmacy doesn’t have the drug in stock; however, this would not happen given a fully
populated database.

More challenges were discovered as the project was implemented which included additional
columns and dosage amount for the drugs. Since each drug can come in different dosage
amounts this means an additional entry for each drug is required. We had an option to input the
dosage in a separate column; this option seemed the most logical for a deployable database,
but since this project wasn’t being extended we decided to put the dosage in the trad_name -
since it is unique. While one of our members was implementing the drug quantity reports, they
noticed that our tables didn’t track the amount of drugs requested in the prescription. In addition
to tracking the quantity, we realized we needed to track the refills used and refills authorized in
addition to the total refills available. If we only tracked the refills available we would never know
how many refills were used if the max amount was less than six. Therefore we need to add a
total of four columns to the prescription table to complete the assignment. These columns
included quantity, refills_authorized, and refills_used.
The prescription table gave us the most trouble and requires three separate queries for a
prescription to be created, given the format we decided which was doctor_id-patient_id-drug_id.
We discussed alternatives, but this solution was the most practical in the long run. An
alternative that didn’t work was to use SSN’s in the prescription, but due to privacy and security
issues, this didn’t make sense.

Web App Screenshots

Figure 1​: New Prescription

Figure 2​: Successful Create New Prescription

Figure 3​: Fill New Prescription Input

Figure 4​: Fill New Prescription Confirm Details

 Figure 5​: Fill New Prescription Success

Figure 6​: Prescription Quantity by Pharmacy Input

Figure 7​: Prescription Quantity by Pharmacy Results

Figure 8​: FDA Reports Input

 Figure 9​: FDA Reports Results

Figure 10​: Refill Prescription

Figure 11​: Refill Prescription Success

Figure 12​: Refill Prescription Error (Max Refills)

Figure 13​: Home
Figure 14​: Updated EER