In our example, the PATIENT table, which we can see in the following screenshot, contains the demographic and identifying information of our patients–their names, contact information, birthdays, and biological sex. In this example, there are only five observations and 11 columns; in real practice, this table would contain all of the patients affiliated with the healthcare organization. The number of rows in this table might range from hundreds to hundreds of thousands, while the table could potentially include dozens of columns containing detailed demographic information:

In the database, every unique patient is assigned to an identifier (the field labeled as Pid), which in our case is simply numbered 1 - 5. The Pid column allows us to keep track of the patients across different tables. Also, notice that there is one and only one entry for each distinct patient ID.

After identifying the indispensable identifer column, the focus should be on which variables to keep and which to discard. Certainly, age and sex are important demographic predictors of mortality. If race were in this table, that would be another important demographic variable.

Another notable variable in this table is the zip code. Increasingly, socioeconomic data is being used in machine learning analyses. The zip code can potentially be tied to publicly available census data; that data can then be joined to the data in this table on the zip code and could potentially provide information on the average education level, income, and healthcare coverage for each patient's zip code. There are even organizations who sell household-level information; however, with that data comes a great responsibility for privacy protection and data security. For this example, we will omit the zip code to keep our final table simple.

Information we'll leave out from our final table includes names, street addresses, and phone numbers. As long as we have the patient ID, these fields shouldn't have much of a predictive impact on our target variable.