Editor's Note: This article marks the first of a planned series on data management. The series is expected to cover many aspects of clinical engineering data management, including how to obtain the data, entering the data into a computerized maintenance management system (CMMS), getting the data out of a CMMS (with reports), device and work-order nomenclature standards, best practices as it relates to financial matters, how to effectively use the data (for example, as it relates to benchmarking and statistical data analysis/data mining,) and data integrity. Other possible topics include data management for systems of systems, clinical alarms-related data, mobile tools, and automated device management. If you are interested in contributing to this series, please contact Sean Loughlin at sloughlin@aami.org.

Healthcare technology management (HTM) data are used in making important decisions, such as when to replace a medical system. Such data also help in determining if a product recall affects your inventory and understanding trends in service costs. Making sound decisions hinges on having high-quality data. Data integrity is defined for this series as the data accuracy, consistency, and comprehensiveness over the data's lifetime. Data integrity will be a theme throughout this series.

Making sound decisions hinges on having high-quality data.

Almost all HTM programs use a computerized database to store and retrieve HTM-related data. These databases, often called a computerized maintenance management system (CMMS), often are built specifically for HTM activities. Most are from commercial software vendors, although a relative few clinical engineering departments still use custom-made CMMSs. Figure 1 shows the basic structure for a generic CMMS.

This first article will review HTM and CMMS data basics and introduce some data integrity methods and ideas.

Effective HTM data management starts with an up-to-date medical equipment inventory. The inventory is the foundation for a high-quality medical equipment management program and the core structure that the entire CMMS relies upon. Table 1 shows the basic fields used by all CMMSs to track a medical device equipment inventory. There are many ways to structure these data, but all CMMSs should have the fields shown in Table 1.

Table 1.

Minimum Equipment Inventory Fields

Minimum Equipment Inventory Fields
Minimum Equipment Inventory Fields

There are many other equipment-related fields that can be included such as vendor, purchase order number, system identifier, date item was last physically inventoried, and end-of-support date. Some of the more important additional fields that require tracking for information technology (IT) and alarm-related issues will be discussed in a future article.

Service History

All maintenance and repair activities—whether in-house or through a vendor, from the service request to the in-house technician activities—parts purchased, invoicing, and bill payment must be tracked for Joint Commission and cost-management purposes. By reading the service history, you should be able to tell the equipment's maintenance and repair story, not unlike how an electronic medical record reveals the health history of a patient. Table 2 shows the fields that are typically used to track these service requests and service history activities. Depending on institutional policies, the CMMS also may be used to manage vendor purchase orders and spare parts management. Regardless of whether the CMMS is used to manage vendor repair and parts purchases, it needs to document all parts and labor costs, vendor and in-house, in order to maintain a comprehensive service history.

Table 2.

Service History Management

Service History Management
Service History Management

A variety of additional fields may be included such as: travel time, overtime, work remaining to be completed, other comments, and notes.

Most CMMSs include a maintenance schedule and scheduler. The maintenance schedule indicates for each device if and when routine preventive maintenance (PM) is required and what needs to be done. PM activities may be on a fixed schedule (e.g., PM due every six months in January and July), a floating schedule (e.g., PM is due twice a year in six-month intervals), based on hours of use as determined by a meter on the device (e.g., every 2,000 hours clean the filters, every 4,000 hours replace the battery), or it may follow another scheduling strategy. Table 3 shows typical maintenance schedule data fields.

Table 3.

Scheduled Maintenance Fields

Scheduled Maintenance Fields
Scheduled Maintenance Fields

Nomenclature standardization is important so that like devices are categorized using the same manufacturer and device-type terminology (e.g., a portable battery-powered defibrillator is always called: Defibrillator, Battery Powered). Table 4 lists some typical common table information.

Table 4.

Common Tables

Common Tables
Common Tables

Purchasing and Service Contracts

HTM or clinical engineering departments, their CMMSs and institutions, manage purchase orders and service contracts in a variety of ways often involving other departments. Therefore, no attempt is made here to list a sample of CMMS fields for these features. What is important is that the HTM department, preferably within the CMMS, obtains all of the cost and other relevant service data (e.g., vendor field service reports from service contract activities) so that a comprehensive service history is stored in the CMMS. All costs (e.g., fee-for-service, prepaid) also need to be included in the CMMS.

The above CMMS table and field descriptions are only a summary. Most CMMSs have evolved to be much more comprehensive and contain a variety of additional fields and features not described here. Advanced reporting tools, import and export tools, interfaces and other features will be discussed in a future article.

Tools and techniques for managing data integrity start with the HTM staff taking responsibility, and being held accountable, for their CMMS data.

Data Integrity

Tools and techniques for managing data integrity start with the HTM staff taking responsibility, and being held accountable, for their CMMS data. Most CMMS software has tools to assist the staff in providing real-time, and after-the fact, data integrity and data error checks. However, commercial CMMSs, in their pursuit of flexibility, may not implement or configure systems to make optimal use of these tools.

Depending on the sophistication of the CMMS and its underlying database engine, some basic data integrity tools exist at the database management and application layers. At the database layer, these include key fields and referential integrity. Primary keys describe one field or a combination of fields in one table that is always unique and required. For example, the equipment tag number is often the primary key to the equipment table. From a data integrity standpoint, it is important to always make the equipment tag number a required field. That concept works well for the equipment table's data integrity, but for work-order data integrity, what happens when a customer reports a broken device and does not know the equipment tag number? Therefore, the equipment tag number cannot be a required field in the work-order table. Managing this is an example of the application and configuration flexibility that the CMMS developers need to provide. One application and configuration level technique for managing this example problem is to allow work orders to be opened without an equipment tag number, but require that work orders include an equipment tag number upon closure.

Another data integrity tool at the database level is known as referential integrity, which ensures that the relationships between tables remain consistent. When one table contains a field that is a key to another table (a so-called “foreign” key), the concept of referential integrity means that you may not add a record to the table that contains the foreign key unless there is a corresponding record in the linked, primary table. For example, you cannot add a new manufacturer to the equipment table until you enter that manufacturer into the manufacturer common table.

At the application layer, error checking may include mandatory fields, user-defined default values and application “sanity” error checking. Table 5 shows a short sample of types of common application layer error checks. Other data integrity methods such as “outlier” reports and data audits will be explored further later in this series.

Table 5.

Sample Error Checking

Sample Error Checking
Sample Error Checking
For More Information

To gain a broader understanding of CMMS basics, consider the book Computerized Maintenance Management Systems for Clinical Engineering (2003 edition). The book is available in the AAMI Store at http://my.aami.org/store/.

Of course, modern CMMSs have many more features, including interfaces to real time location or radio frequency identification systems for wireless equipment location tracking, mobile wireless devices for data viewing and entry, and customer database access.

About the Author

Ted Cohen is manager of clinical engineering at UC Davis Medical Center in Sacramento, CA. E-mail: theodore.cohen@ucdmc.ucdavis.edu