The intelligence of a database design begins with the intelligent approach in which the developer focuses on the particular need the database is to fulfill. It is especially important to constrain, or specialize, a database used in health care, else the database can quickly grow beyond the bounds of efficiency. Efficiency can be found directly from table design, and it can be further achieved with business rules and logic. Designing a database for storing patients’ medical records also has some risk of increasing the likelihood of medical errors and statistical incongruities if done improperly; therefore, a qualified database administrator should be consulted (Campbell, 2004; McGlynn, Damberg, Kerr, & Brook, 1998). However, a preliminary needs assessment can be accomplished by asking a few simple questions: Who? What? Where? Why?
Who needs to use the database? For whom is the data useful? By identifying the scope, or domain, of each database user, the developer can gain a sense of which data points are important (McGlynn et al., 1998; Thede, 2002). For instance, in health care, a purely diagnostic database should efficiently offer comparative differential diagnoses to aid a physician in caring for patients; however, a database of this type will not offer much to the administrative arm of the practice. By understanding the relationship between physician diagnosis and billing, relational techniques can serve to ensure greater accuracy in billing procedures.
What data needs to be stored and retrieved? By listing the specific data to be stored, the developer has an opportunity to optimize the storage methods by creating an efficient and normal relational table foundation (Kent, 1983; Sen, 2009). A patient care reporting database, for instance, must be able to store patient identifying information, or demographics. Depending on the specific needs of the practice, demographic data can usually be stored in a single table. Other relational tables could be used to store references between the patient demographic record and pertinent medical information, thereby minimizing duplication (Thede, 2002).
From where does the data need to be accessed? Does this database require authentication for use on a local area network or a complex security policy for wide area network access (Campbell, 2004; McGlynn et al., 1998)? More importantly, however, is portability of the data. If the data is going to be replicated in a large composite database, the data needs to meet the specifications of the repository. This is often achieved by the publication of a template, or a clear set of directives on how data is to be formatted before transmitting data to the repository. An example of this is the Medicare electronic records requirements set forth in the Health Insurance Portability and Accountability Act (HIPAA) of 1996. By accounting for common templates in the design phase, the developer can avoid having to parse data prior to transmitting the data over the network.
Why are we storing the data? Today, it is very common to store data if merely for purposes of recording an interaction, such as a patient contact. However, it is important to understand how the data will be used in the future. Will the data need to be immediately accessible, such as in emergency or critical care areas, or could the data be compiled and batch processed during times of off-peak network load, such as in billing or logistics. Could paper reporting fulfill the immediate need better? If so, should the data on the paper report be entered in a database later? Regarding transcription, it is important to be knowledgeable about the available technology for creating scanned images, portable electronic documents, and the use of optical character recognition in order to properly prepare for the storage of each.
By answering the who, what, where, and why of the database needs assessment, we ultimately answer the question of how to design and implement the database. As an example, in order to design an ambulance run form, we must take into consideration demographics, the history of present illness (or, the reason for the ambulance request), past and pertinent medical history, including, but not limited to: medications, past medical problems and surgeries, and allergies to medications and environment. It is also important to store the assessment, care, and outcome, as well as the disposition of the incident and the destination facility. Additionally, medical standards, such as diagnostic codes, medications, protocols, and algorithms, could be stored in reference tables for preventing redundancy within the data model (Kent, 1983; McGlynn et al., 1988; Sen, 2009, Thede, 2002). Ambulances are mobile; therefore, network access is an important consideration when designing an electronic ambulance patient care reporting database. For this type of database schema, I would recommend using a small, efficient database locally with a mechanism in place to replicate the data to the larger repository when the network is accessible.
Another challenge in creating a database is learning how not to store information. Information is made of of data, but only data should be stored (Collins, 2009). Programming logic can be used to synthesize data into information and, further, into knowledge. Many database designers mistakenly store information, or even knowledge, quickly inflating the size of the database and decreasing its efficiency and normalcy (Kent, 1983; Sen, 2009).
In conclusion, developing an electronic patient care reporting database for a physician practice has some inherent risk if done poorly; however, a knowledgeable member of the office team can highlight the project requirements by performing the needs analysis.
References
Campbell, R. J. (2004). Database design: What HIM professionals need to know. Perspectives in Health Information Management, 1(6), 1-15. Retrieved from http://www.ncbi.nlm.nih.gov/
Collins, K. (2009). Managing information technology. Exploring Business (pp. 122-130). Retrieved from http://www.web-books.com/
Health Insurance Portability and Accountability Act (HIPAA) of 1996, P.L.104-191. (1996).
Kent, W. (1983). A simple guide to five normal forms in relational database theory. Communications of the ACM, 26(2), 120-125. Retrieved from http://www.bkent.net/Doc/ simple5.htm
McGlynn, E. A., Damberg, C. L., Kerr, E. A., & Brook, R. H. (1998). Health information systems: design issues and analytical applications. Retrieved from http://www.rand.org/pubs/monograph_reports/2007/MR967.pdf
Sen, A. (2009, May 7). Facts and fallacies about first normal form. Retrieved from http://www.simple-talk.com/sql/learn-sql-server/facts-and-fallacies-about-first-normal-form/
Thede, L. Q. (2002). Understanding databases. In S. P. Englebardt & R. Nelson, Health care informatics: an interdisciplinary approach (pp. 55-80). St. Louis, MO: Mosby.
