Spreadsheets vs Databases: 20 Differences Healthcare Organizations Should Know About

Almost all healthcare and life sciences organizations use a combination of databases and spreadsheets to manage their data.

Spreadsheet software is incredibly versatile. For beginners, spreadsheets are easy to create, set up, and start adding data to. On-the-fly mathematical calculations are simple. For experts, spreadsheets support a wide range of advanced functions.

However, for addressing certain transactional, data-intensive business requirements, spreadsheets are no substitute for a database.

Here are some applications in which we’ve seen the capabilities of spreadsheets get stretched beyond their limits:

• HIE member management
• Terminology mapping
• Aftercare contact centers
• Physician referral tracking
• Customer service for medical devices

When a spreadsheet is pushed past its natural limits, at best, it becomes unwieldy for users to manage. At worst, data integrity is compromised, and data is lost.

 

There is also a middle ground between databases and spreadsheets that includes software such as AirTable and Google Tables. Both of these have more of a spreadsheet look and feel than that of a database front-end.

So, let’s get to the comparison: below are 20 differences between a spreadsheet and a database. Since we work mainly with healthcare and life sciences organizations, many of our examples will be specific to those industries.

1. Software costs

Spreadsheet software is usually bundled with other office software, which means that the costs net out to $10 – $20 per user per year. Once someone has a spreadsheet user license, there is no incremental cost for each spreadsheet that they create.

An in-house or cloud-hosted database such as Oracle, or Microsoft SQL Server requires either a license purchase or a subscription. The basic cost of Microsoft SQL Server without a frontend user interface is about $1,000 for the server license and about $200 per user (CAL).

Cloud-based EHR and cloud-based healthcare CRM both require an ongoing per-user subscription payment. The cost can be over $200 per user per month, it cost includes a front-end user interface plus a backend database.

Cloud-based platforms also have regular automatic releases that benefit all subscribers, from enterprise clients down to small businesses.

2. Setup time

Spreadsheets are quick and easy to set up. To create a new spreadsheet, all a user needs to do is to make a selection such as File > New from a menu. Most users add new columns to a spreadsheet on the fly with little to no pre-planning.

While a database application like Salesforce Health Cloud has an out-of-the-box “starter” configuration, proper planning needs to go into configuring and customizing the database to meet business needs. In almost all cases, only an administrator has the power to alter the structure of a database—users cannot add tables or fields.

3. The user experience

The user interface for a spreadsheet is mainly a grid of rows and columns. A spreadsheet “record” is often a row that requires scrolling off to the right to see all the data cells for that record.

While database applications have the ability to view data in lists, users spend a lot of their time working with individual records that have header fields and related information organized in sections on a layout.

4. Clutter vs focus

While spreadsheets have filtering capability, the default mode for a spreadsheet is to display all data values all the time. In database terms, it’s a raw data view.

Databases like Salesforce Health Cloud let a user easily switch among saved list view filters.

For example, the default list view for someone who does physician outreach could be “My Physician Relationships” rather than all contacts in the database.

5. Flat file vs relational

Spreadsheets are “flat” representations of data. Data is sorted alphabetically and appears as a table of rows. Data can be accessed by scrolling down the list or using search functions to find specific information within a spreadsheet.

Spreadsheets aren’t designed for setting up strict relationships among different tables, but databases are for exactly this. In a database, it’s easy to set up parent/child, parent/child/grandchild, etc. table relationships. Examples include:

• Clinic/Physician/Email Communication
• HIE Member/Connection Member
• Patient/Clinical Encounter
• Patient/Clinical Order/Lab
• Patient/Clinical Order/Imaging

This is an important difference — the ability to view, manage, and report on these types of hierarchical relationships adds a lot of business value.

6. Activity management

An important function of a database for human interaction is the ability to log time and date stamped conversations, observations, and emails. The ability to schedule follow-up emails and calls is also important.

These “activities” (a follow-up activity is shown in the above image) are an important relational aspect of software such as Health Cloud.

A spreadsheet allows for creating a row that contains contact information. However, because of the flat nature of a spreadsheet, a user can’t schedule monthly calls to a specific contact and have those appear in a calendar view or task list, for example.

7. Table structure

In a database table, columns are attributes (First Name, Last Name, DOB, Gender), and rows are records (Patients). This basic structure cannot be altered.

In a spreadsheet, a column is often an attribute and a row is often a record. However, there’s nothing to stop a spreadsheet user from creating a transposed version of the column/row convention.

8. Levels of user permissions

A shared Google Sheet has only three levels of user permission—viewer, commenter, and editor. The same is true with Excel Online co-authoring.

When an Excel desktop spreadsheet is passed around from user to user, anyone who has a copy is an editor of their copy.

On the other hand, a database like Health Cloud can have granular levels of user access applied to it. A clinician and a non-clinician can have two very different views of the same patient record. A clinician can enter text into an “Encounter Notes” field, for example, but a non-clinician can only view those notes.

Salesforce’s “Who Sees What” YouTube playlist explains the layers of permissions in detail.

9. Compliance

A spreadsheet that is shared across multiple organizations may not be secure enough to store Protected Health Information. It does therefore not adhere to HIPAA security standards.

Salesforce contributes to keeping ePHI secure in the Salesforce Covered Services by implementing a wide variety of security safeguards.

10. Enforcement of data types

Databases like Salesforce Health Cloud use data types to make sure that data in a particular field is consistent across records. If a Birthdate field has a type of “date,” that means nothing but a date can be entered in that field.

In a spreadsheet, it’s not possible to define a data type per se. However, a date validation rule can be applied to an entire column of values, for example:

11. Data validation

A database application like Health Cloud extends data validation beyond an Excel-type rule for an individual cell. Validation rules can compare values in two or more fields and enforce data entry standards based on multiple criteria.

12. Searching for information

Spreadsheets have a Find menu option that allows for searching for a text string within individual cells. If “First Name” and “Last Name” are in different cells, a search using the full name does not work.

Full name searches are standard in a database application like Health Cloud. Databases also allow for complex querying that can retrieve specific records from large amounts of data.

13. Recovering deleted records

If someone with editor permissions on a shared spreadsheet deletes a row, it is possible to recover that missing row by combing through version history. However, the only restore option other than copy/paste is to restore an entire previous version of the spreadsheet. But the version that has the missing row may be from many iterations ago, with many other changes having occurred since.

In a CRM database like Salesforce, it’s possible to restore a single deleted record (that was deleted up to 30 days earlier) into the current “version” of the database.

14. Recovering accidentally modified data

If a value in a single spreadsheet cell is accidentally changed, version history is also the only practical recovery method.

Salesforce Health Cloud allows an administrator to set certain fields to have History Tracking. All changes to those fields show the old value, the new value, when the change was made, and who made the change.

15. Record identifiers

The identifiers for records in a database like Salesforce are called primary keys. These keys give every record a permanent, unique identifier—regardless of sort order.

In a spreadsheet, rows are numbered sequentially. As soon as a new row is inserted above an existing row, the existing row gets a new numeric value.

16. Integration with other systems

Integration among systems relies upon the predictable location of data fields to function properly. Underneath each database, field is an API value that integration software can use to keep track of where to read information from and where to write information to.

Because a spreadsheet has a fluid structure, integration software may “lose track” of what information is located where.

17. Scalability

A spreadsheet has a much lower data volume limit than a database has. They are not designed for data storage. When a spreadsheet has tens of thousands of rows, it will start to slow down.

Databases can scale to millions of records and hundreds of thousands of daily transactions without any performance degradation.

When you consider that SNOMED CT alone has over 350,000 concepts, that suggests a database application is more efficient for terminology mapping than a spreadsheet.

Google Sheets Limitations

At one time, Google Sheets had a limitation of 400,000 cells, with a maximum of 256 columns per sheet. This limitation has been lifted and now Google allows up to 10 million cells or 18,278 columns. However, spreadsheet performance reportedly begins to drag when there are millions of cells.

Microsoft Excel Limitations

Microsoft Excel has a limit of 256 columns per sheet. There is a limit of 65,536 rows.

18. Reporting and dashboards

The reporting function in spreadsheets mainly involves creating pivot tables and charts.

Database reporting engines have capabilities that go beyond spreadsheets, such as multi-level filtering and bucketing. Dashboards allow for data visualization from multiple reports on a single screen. This provides a broader view of important information.

Reporting is an area in which a database and a spreadsheet can be complementary.

For example, with sufficient permissions, a user can query the data from a Health Cloud report within a spreadsheet. An example is the Google Sheets add-on called Data Connector for Salesforce.

19. Data import and export

With a couple of clicks, a spreadsheet user can make an exact copy of a spreadsheet file, which can present a security risk.

Databases like Health Cloud allow an administrator to restrict data import and/or data export by table and by user.

20. Audit Trails

In a database, any user who adds a new record has a permanent attribute as the creator of that record. The last person to edit a record is identified as having modified the record.

Certain fields can be set as History Fields. When a field value is changed, the prior value and new value are logged along with the user who made the change.

Spreadsheets do not allow for having this type of audit information at the record or cell level.

Conclusion

While spreadsheets are useful for many tasks, they fall short of a database for a number of business requirements and use cases. Are spreadsheets slowing you down? We can help you take your data to the next level. Contact us to find out how.