Security
Even before the Health Insurance Portability and Accountability Act (HIPAA) was signed in 1996 the confidentiality of patient data had a high priority. Patient records were private and policies covering patient data restricted access to them to specific groups of people. But with technological advances such as The Internet, and public wireless network hardware being pushed in many areas this has become an even more sensitive issue. It is for these reasons that I regard Security to be second, only to reliability, in priority when considering the database for an application.
Most Flat File and ISAM databases rely on the Operating System of the File Server when it comes to Security. This does not allow a great deal of control when it comes to data. Most Operating Systems have very limited security features when it comes to data files. Most of the time an Operating System will restrict access to a datafile to allow the user to read, write, or execute a specific file. With authorization restricted to those three choices there really isn’t much an administrator has control over with the exception of either allowing or denying a user access to the database.
Most Client Server applications have some form of specialized security within the server software that allows for much more control over the authorization aspect of information security. Authentication is also usually more flexible. Allowing a larger range of authentication techniques than the Operating System alone usually provides.
Most of the healthcare applications I have designed in my career use a 4-Tier architecture. The Client is the first tier, it is known as the “front end” all that the user sees and interacts with is in this tier of the application. The second tier is the code and software used by the Web Servers. This tier is responsible for taking the data from the 3rd tier, then deciding how it should be displayed, then relaying that to the 1st tier. The 3rd tier is called the “middleware” . This is where the data which comes from the 4th tier is “crunched”. Any sorting or processing that needs to be done to the data before it is presented to them usually happens here. The 4th layer is the actual database where the raw data is stored and eventually retrieved. If we were to look at this system as if it were the human body, the user would be the brain, for without the user, an application is merely automation. In this analogy the first tier would be the rest of the nervous system. The second tier would be represented by the individual parts of the body that interact directly with the nervous system, eyes, skin, tounge, nose, ears. The third teir could be represented by the circulatory, endocrine, digestive, and respiratory systems performing vital functions to keep the body functioning normally. The 4th tier could then be represented by the organs and tissue of the body the true “heart” of the system figuratively and, in this case, litterally. And in keeping with this analogy, security can be thought of as the Immune system protecting the interests of the body.
There are aspects of security at every level of this model. On the first tier we have the physical access to the computer executing the client application. Next we have the authentication which we do at the 2nd tier, authenticating users through our active directory domain servers. Next we have a Security Model application, that I designed, built into tier 3, which allows us to administer all our in-house applications from one site. On our Client-Server databases there is yet another security layer which we administer internally.
While a model like this is very versatile and much more secure than a simple Operating System security implementation, it is much more complex to both implement and maintain, and will usually cost more than less secure alternatives. With security being such a high consideration though, our cost/benefit analysis usually justifies the more secure solutions.
