This document describes the development of a database for a laboratory entity within a hospital's electronic medical record system. It includes an introduction outlining the need for efficient medical databases. It then provides background on the business rules and attributes of the laboratory entity. An entity relationship diagram shows the relationships between entities. The document discusses using the system development life cycle methodology and describes the planning, analysis, design, implementation, and maintenance phases of developing the backend and frontend databases. It concludes by recommending future improvements.

1. 1
Final Project Report: Laboratory Entity
by
Nicholas Eastman
MI 5130: Database Systems in Health Care
Instructor: Arif M. Rana, Ph.D., Ed.S., M.S.
CRN XXXXX
Nova Southeastern University
College of Osteopathic Medicine
Biomedical Informatics Program
Fall 2014

2. 2
TABLE OF CONTENTS
SECTION NAME PAGE
I Introduction……………………………………………………………………………….. 3
II Background…………………………………………………………….………………..… 4
III Entity Relationship Diagram……………………………..………………………... 6
IV Development Methodology……………………………..…………………………. 7
V Backend Database…………………………………………………………………….... 9
VI Frontend Database……………………………..……………………………………... 14
VII Future Recommendations……………………….……………………………….... 18
VIII Conclusions……………………………………………………………………………...... 18
IX References…………………………………………………………..………………........ 18

3. 3
SECTION I: INTRODUCTION
There is no mystery as to where the future of medical record keeping is heading. More
and more Health Care Organizations have made the switch from conventional paper records,
inefficient remote care and communication, and costly methods of imaging and image storage to
much better practices like electronic record keeping, patient-centered medical communication,
and remote server and cloud-based imagineaccessing. Quick,integratedmethods of information
retrieval can be crucial in improving the quality of care of the current healthcare atmosphere. At
the very heart of this information retrieval are properly-created and well-maintained databases.
Proper database architecture is essential for successful implementation and continual
functioning of electronic medical record systems.

4. 4
SECTION II: BACKGROUND
When a patient visits a hospital, they can either be admitted or not. If admitted, the attending
physician will most likely order tests to be performed in the hospital’s laboratory (though on rare
occasions, this is not the case). These tests may include blood tests, urine tests, stool tests,
wound cultures, and a variety of other tests. The LABORATORY entity is vital to a proper
electronic medical record database because it easily and efficiently conveys data about
laboratory studies, which assists the physician(s) in properly diagnosing an ailment and
effectively treating it. The business rules associated with this entity are as follows:
1.) One patient may or may not be admitted.
2.) One patient may be admitted more than once
3.) An admitted patient may or may not have laboratory tests run
4.) An admitted patient may have multiple laboratory tests run
This LABORATORY entity will contain seven attributes. The primary key for this entity will be a
requisition identification number (lab_req), which will uniquely identify each laboratory test to
be performed on the patient. The patient will be identified using the admission identification
number (AID), a foreign key derived from the ADMISSION entity (which derives the patient’s
personal identification number – PID – from the PT_DEMO entity, created upon first arrival at
the hospital). The other attributes stored in this entity will help to describe each instance of a
performed test. Because patient demographic information is stored within the PT_DEMO
attribute, it would be redundant to create attributes that relay that information within the
LABORATORY entity. Instead, this entity’s non-key attributes should provide data only regarding
information obtained in the hospital’s laboratory. It is important to know which Physician
ordered each lab test to be performed. Usually, within a hospital’s database, the LABORATORY
entity would draw this information from a separate entity, using a Physician ID foreign code, but
for the purposes of this exercise, it will be entered by the user. This attribute will be called
“lab_ord_phys” for “lab ordering physician”. This attribute cannot be null, and must use
characters, with a string limit of 20. Next, it important to describe which test is being performed.
The physician must know what type of sample was obtained and what test was performed.
Again, this must be described by characters and the string will be limited to 50, in case of more
complicated or intricate tests. This also cannot be null. This entity will be called “lab_desc” for
“lab description”. While some lab tests result in numbers (white blood cell count, red blood cell
count, glucose,bacterial sensitivity,etc.), some labtests may be simply positive or negative(fecal
leukocytes, pregnancy, rapid strep test, etc.). Therefore, there may be one of two attributes that
will be null for each instance. There could be a “lab_pn” attribute describing whether the test
was positive or negative and a “lab_amt” which describes the actual concentration of the
substance that the physician is testing for, which would produce the need for a “lab_flag”
attribute, describing whether this concentration is abnormal. However, because a positive (e.g.
astrep test)or negative (e.g.protein deficiency) result may be abnormal and both entities require

5. 5
the same metadata, in the interest of integrity, the “lab_pn” attribute can be combined with the
“lab_flag”attribute to tell whether the overall result is abnormal. This attribute willjust be called
“lab_flag”. This attribute may be null only in the case of a normal “lab_amt”. “lab_flag” will be
constrained to a character limit of 1, with possible data entry being “P” for positive, “N” for
negative, “H” for high, “L” for low, and “F” for failed (in the case of an unclear result). As
aforementioned, it can be null. The “lab_amt” attribute can be null, and it will be constrained to
integers only (characters may be preferred due to possible results in decimal places, but could
not be utilized for derivative calculations). Lastly, it is important to know the units of
measurements for a not null “lab_amt”. Though, most physicians know the expected
concentrations of each lab study, a number without units is meaningless in terms of medicine.
This attribute will be called “lab_units”, it may be null in the case of a positive/negative test, and
will be constrained to a character sting of 5 (two letters, a slash, and two more letters). It is very
important to note that a “lab_range”attribute would be particularly effectivein this entity, which
could be used to autofill the “lab_flag”attribute. However, deriving data from data is beyond this
scope of this project.
SECTION III: ENTITY RELATIONSHIP DIAGRAM
Entity Attribute Data Type Primary Key Foreign Key NULL
PT_DEMO
PID INT yes NO
PT_F_NAME CHAR (50) NO
PT_L_NAME CHAR (50) NO
ADMISSION
AID INT yes NO
PID INT yes NO
LABORATORY
lab_req INT yes NO
AID INT yes NO
lab_ord_phys CHAR (20) NO
lab_desc CHAR (50) NO
lab_amt INT YES
lab_units CHAR (5) YES
lab_flag CHAR (1) YES

6. 6
PT_DEMO
has
ADMISSION
AID PID
PT_F_NAME
PID
PT_L_NAM
E
includ
es
LABORATORY
Lab_req
AID
lab_ord_phys
lab_desc
lab_flag
lab_amt
lab_units
ThisEntity-RelationshipDiagram(ERD) describesthe relationshipsbetweenhospitalentities. As
shown, one patient may be admitted multiple times. That admission may include multiple
laboratorytests. The various attributes are listed for each entity, while the keys attributes for
each entity are underlined

7. 7
SECTION IV: DEVELOPMENT METHODOLOGY
In this section, provide an explanation of the used development methodology, i.e. System
Development Life Cycle (SDLC) or Database Life Cycle (DBLC) as it relates to the work you did in
completing the project. These methodologies can be found in Chapter 9.
The system Development Life Cycle (SDLC), an essential history of an information system,
describes a larger picture view of the process by which the database is designed and developed.
It involves five major steps, described in the following:
Planning:Thefirst portion of the planning process involves the question, “Does this process need
to be done differently?” In this particular project, the database is essentially emulating current
EMR databases, but simplifying them on a very low level. Most medical databases are flawed in
design in some way, despite years of database design evolution and successful implementation
into various Health Care Organizations, which begs for alternate ideas and designs. Even this
project’s architecture should be improved upon. The best possible project infrastructure
alteration should balance most beneficial cost of implementation and maintenance, including
resource allocation, with cutting edge technological advancement. In the caseof this project, the
architectural cost is essentially free, but the level of technological input is quite low.
Analysis: The requirements of this system’s end users are fairly straightforward. There are five
user-entered boxes for strings of data, and one designated for choice. These boxes are very
simple to use, because they ask for fairly simple points of data. Unfortunately, with the strict
number of attributes required for this project, and the lackof knowledge limiting the user queries
(I.E. the lack of required data entries), this database design could be much more user-friendly in
terms of a resulting GUI when presenting the data in the designed table. However, there is very
little user knowledge necessary to utilize the database, and it should function properly under any
input.

8. 8
Detailed system design: The necessary steps to the database’s functional design are presented
in the following figures, step by step. The php file is shown in the executable program “Notepad
++”, a program which may be used to properly debug an improper code via error messages and
line numbering. It may be utilized even further with a debugging software like “Eclipse”, which
allows each line to be run at a time, ensuring that the programmer will know exactly when an
error is occurring. As of now, the database queries for this project run smoothly.
Implementation: The large scale implementation of this software may take several weeks, in
order to properly fix any type of bug or improper coding that may be present. For example, as
you will see in the coming pages, a user’s entry that is left blank, does not necessarily translate
to a ‘null’ entry. In the case of the attribute ‘Amount’ box is left blank, the coding will translate
the entry as a ‘0’ value, as opposed to a ‘null’ value. These are the types of problems that the
implementation stage would attempt to correct before a project’s final launch. It is also
important to assure that this database runs properly on all consoles. This portion usually takes
the most time out of all of the SDLC processes.
Maintenance: Now that the infrastructure has been properly implemented and tested
thoroughly, the system’s functions must be monitored for unaccounted problems and potential
future upgrades. For example, if there was some problem with a compatibility issue with this
project’s database that the implementation step did not account for, the maintenance teammust
quickly, efficiently correct this problem in order to keep a smooth business environment. Note
that the process may be iterative in the cases of improvements being discovered, or outdated
infrastructure being indicated.

9. 9
SECTION V: BACKEND DATABASE
For this section, provide detailed explanation of how the database was built, along with the SQL
statements. Screen shots can be submitted for each step you took with a brief write-up.
Step 1: Apache and mySQL are turned on by typing ‘cd c:xamppxampp-control.exe’ and
executing the command:
Step 2: Connect to the databasemanagement systemby typing ‘cd c:xamppmysqlbin and then
mysql –u root’.

10. 10
Step 3: Change the name of the PHP file to LABORATORY.php and save it under C:xampphtdocs
Step 4: Create database named ‘mi_5130_db’ with the shown sql command:
Step 5: Connect to database ‘mi_5130_db’

11. 11
Step 6: Using SQL commands, create the PT_DEMO table, with its three attributes. Auto-
increment the Primary keys shown:
Step 7: Using SQL commands, insert a minimum of 10 records into the PT_DEMO entity:

12. 12
Step 8: Using SQL, create ADMISSION entity with its attributes. Auto-increment the primary
key. Specify the foreign key, using the same commands from the ‘PT_DEMO’ table (see step 6).
Step 9: Using SQL commands, insert a minimum of 7 records into the ADMISSION entity

13. 13
Step 10: Create the Laboratory entity via sql commands, with the seven attributes you created.
Auto- increment the primary key:
Step 11: Insert a minimum of 5 records into the created laboratory entity using the INSERT INTO
command (this may not look exactly like one would want, but it is correct and will look correct
to the user):

14. 14
SECTION VI: FRONTEND DATABASE
For this section, provide the description of the developed PHP codes used for the frontend
application. This should also include the SQL statements that are embedded in the PHP codes.
For example, inserting data into the database will require the use of SQL INSERT statements as
part of the PHP codes.
After editing the .php file, display the data of your assigned table/entity. Provide a minimum of
three screen shots with a brief description of each:
Front End step 1: The titles of each attribute are clearly stated. Note on lines 96 through 102,
that each title corresponds to each back end attribute. Lines 107 through 113 are the sql
attribute names that each attribute title corresponds to. Notice that each is case sensitive, and
each corresponds to the sql attributes.

15. 15
Step 2: This step represents the creation of a user input section. In lines 40-47 notice that there
are titles for each input section, each input type, and which attribute each input option
corresponds with. Most are text inputs, but the last attribute (‘Flag’) represents a box with
selectable options. There are a few issues with this layout, which will be explained near the end
of this section:

16. 16
Step 3: Line 58 is the command prompt command to connect to sql. Line 61 is the mysql
command to connect to this project’s database “mi_5130_db”. Lines 62 through 69, the reader
should recognize, are the mysql commands to insert the various values selected into the
‘laboratory’ table.
The following is the web browser’s interpretation of the php file. This is shown by typing
‘http://localhost/LABORATORY.php’, which shows that Data as is:

17. 17
Note that some entries are null (which were done so on purpose). This becomes important in
the next few figures. When the user clicks the “Add a New Record” Hyperlink, he or she should
see the DATA ENTRY SCREEN:
The user will then enter the information:
If the php file and created sql table were constructed properly, the user should have successfully
submitted the query, and the resulting new page should look similar to this:

18. 18
Note that the Laboratory Requisition ID is 8 as opposed to the expected 6. This is due to two
previously deleted instances of this table performed by the architect. Also, not that the amount
defaults to ‘0’ when no value is entered, instead of a ‘null’ value. This is due to a php coding
anomaly, which would be remedied by an “if-then” statement, which is beyond the scope of this
project. As is, this table would need correction because an amount of ‘0’ would NOT translate to
a positive. However, for the purpose of demonstrating php file reading, this entry is valid.
SECTION VII: FUTURE RECOMMENDATIONS
As mentioned, the major issue with this particular project is the absent entry translating into an
integer of ‘0’ rather than a null entry. This could most likely be remedied by creating a variable
out of the entry and creating an “if-then” clause in the case of an absent entry. Unfortunately,
that particular problem is beyond the scope of this experiment. Secondly, the Graphic-User
Interface of the database via the web browser is very bland and dull. Graphics, pictures, colors,
and other effects would be attractive to users, and may be implemented with the use of proper
php coding, but are, again, beyond the scope of this project.
SECTION VIII: CONCLUSIONS
This project has taught this author the value of proper coding when constructing a database,
whether it be at the backend with sql, or the forehand with php. It was a very enjoyable
experience and this author hopes to continue learning all he can about databases with the
coming project. Though this is just a microcosm of what is being done in the modern age of
database design and maintenance, it is always very important to understand the building blocks
before properly designing a magnum opus. It is something to be proud of.
SECTION IX: REFERENCES
Babson University (1997). “Note on Data Structure Analysis: Entity-relationship diagrams”.
http://faculty.babson.edu/osborn/mis7510/readings/erd.htm
Chapple, Mike (2014). “Deleting Data from an SQL Table”. Databases. About.com.
http://databases.about.com/od/sql/l/aadeleting.htm
Coronel, Carlos & Morris, Steven (2013). Database Systems: Design, Implementation, and
Management. Cengage Learning. Stamford, CT. USA.