One of the most important skills for Healthcare IT is an understanding of healthcare database concepts and structure. It doesn’t matter if you are a Project Manager, Application Analyst, or System Administrator; an understanding of databases in Healthcare will take you a long way in your career.
So with all the different Healthcare IT systems on the market, how can one article provide value? In my career I’ve worked with a medical supply software system, pharmacy systems, three different electronic medical records systems, a home health application, and various other products. They all had their differences, but had many things in common.
For example, just about every system has some kind of “departments” table. In some systems, it may be called locations, or areas- but the idea is the same. With that, I will try to use vendor-neutral descriptions. Let’s dive in.
 |
For our example, let’s say we have one database called ‘HEALTH_PRODUCTION’, with many tables defined within that database. Here are some tables that are likely to exist:
The enterprise table is defined to represent your organization at the highest level. There will have many departments under this entity, and reports sent to Federal regulatory agencies will reference the enterprise. It could also be called “Facility” or “Organization”.
The departments table contains all the departments in your enterprise. There will be clinical and non-clinical locations, and most but not all will have physical locations. Those without physical locations are sometimes called virtual departments, and are just for accounting or administrative purposes. Most will have some kind of cost center code. Here are some examples:
The users table contains all the users in a system. You might guess that all users in a particular system actually log into that system. However, that’s not always the case. An example would be a doctor who does not work for your organization whom you refer patients to. Referrals to this doctor are part of the patients’ official medical record, but that doctor has no direct connection with your organization. Users will have varying levels of security in any given system. Here are some examples of user types:
The patients table will usually be huge, possibly having one row for each patient. It will have the demographic data on each patient, and may or may not have specific clinical information. For this example, let’s assume clinical visits and orders like current meds are not in this table.
The orders table contains orders that get placed for patients, such as:
Orders are almost always authorized and signed by a licensed provider such as a physician, therapist, and in some cases a nurse. In some systems, initial order entry could be done by a non-provider, but the order would be in a ‘pended’ status until signed by the provider.
While the previous paragraph was about the orders that get placed, here we have the items, meds, or procedures themselves that are defined in their own table, waiting to be ordered. Duration, quantity, and timing are not usually hard-coded into this table, but are specified when specific orders are placed.
If clinical information is not in each patient data row, then there will be pointers to other tables. A pointer is just an identifier in a table to provide linking to data in other tables. Notice here we have an order for Glucose Test Strips that has a column called “Ord_Item”…
That happens to be the same value we have in the Items table for column “Item_ID”…
Medications usually have their own table, separate from other things that get ordered. Due to complexity, liability, and regulatory issues, most systems rely on imports from third-party firms that provide a comprehensive formulary of medications. One vendor who provides this data is First Data Bank, and we refer to the process as the “FBD Import”.
These are the events that occur when anything is done on a patient. Examples are:
A system may have a table that stores notes that caregivers write to document a patient encounter. It may have a field that stores a large amount of free text to be displayed in an application, possibly using HTML or other formatting.
This contains industry specified codes and descriptions for every condition, disease, or disorder imaginable. Like the medication formulary, this data is almost always downloaded from an outside data provider. The most popular one is Intelligent Medical Objects (IMO).
Clinical healthcare data can be organized into several different categories:
This doesn’t cover all the possible database concepts in Healthcare IT, but should give you a good starting point. If you want to learn much more about databases in healthcare, check out this course on Udemy called Data Analytics: Intro to SQL using Healthcare Data (SSMS), created by Curtis Norman.
Next Up:
If you are trying to get into Healthcare IT, or any other tech job for that matter; it’s important to develop core technology skills that will carry you through the challenges ahead. An essential core skill is a decent understanding of Excel, .
Read More
