Log in Article Discussion Edit History Go to the site toolbox

New Welcome Package

From HTMcommunityDB.org

Revision as of 21:30, 11 November 2019; Sysop (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)


New Welcome Package for Data Aggregators

(This document was last revised on 8-17-17)

Thank you for volunteering to participate in AAMI's HTM Community Maintenance Database Project. By providing us with summarized data from your organization’s maintenance records you will be contributing to the Maintenance Practices Task Forces effort to create a rational, evidence-based method for efficiently managing planned maintenance (PM) programs for medical equipment.

Before getting started with the actual five step process that you will need to follow to submit your data, let’s be sure you have a good understanding of the project.

Project objectives

The project has four objectives:

1. Develop, and gain community-wide acceptance for, a scientifically sound but simple to understand RCM-based methodology for determining which specific types of medical devices are made safer by periodic planned maintenance -along with a clear explanation of why routine PM fails to improve the safety of the majority of medical devices.
2. Develop guidelines and tools to facilitate a rational optimization of PM programs, including a standardized format for the maintenance documentation required to support the RCM-based analytical methods being proposed.
3. Create a community-wide database to provide a substantial body of quantitative evidence to support this rational optimization.
4. Build up a collection of information on each device’s demonstrated level of PM-related reliability and safety based on the aggregated maintenance data for each specific manufacturer-model version of the different types of device.

Required data structure

If you have not already done so, please start by reading the "Heart of the PM Debate", paying particular attention to Section 15.3 "Why we need to standardize the format of our maintenance reports".

Your data will be combined with data from other organizations and used to fulfill Project objectives #3 and #4. But for your data to synchronize with that from other submissions, it will need to comply with the guidelines spelled out below.

Before getting started, please pay particular attention to the data structure described in Sections 15.3 2) "Failure cause codes for repair calls" and 15.3 3) "Coding PM Findings" in "The Heart of the PM Debate". Your data needs to be submitted in total conformance with this structure. We can only accept data that has been reliably “mapped” to this specific data structure.
If your existing data cannot be reliably mapped to this data structure, please take steps to adopt this particular structure within your organization and begin collecting so that you can begin collecting for future submissions.
If you are not able or willing to adopt this particular data structure, the Task Force will not be able to utilize your data. If that is the case, please let us know. We may be able to use your help with another part of the project.

Before diving into the details of the data structure, it will probably be helpful to see the kind of summarized data we are looking for. Please refer to Table 5.3HE Critical care ventilators (illustrative hypothetical example). Within this table, the hyperlink in the R1C1 cell takes you to a Detailed Proof table for one generic model of Critical Care Ventilator maintained at 6 month intervals (C.VEN/BA-M1/06). This table shows the actual format of the summary data we are hoping you can provide.

Below are the five steps we recommend you follow in order to gather together your data in the requested summary form for submission.

At this point the Task Force is only asking for data on the “Top 20” device types in Table 4. In the future we plan to expand the collection to other device types. After you’ve submitted summary data on the Top 20 device types that we’ve accepted, we’d be more than happy to get additional data from you on other device types.

The five step process for becoming a new data aggregator

Step 1. Approvals.

Before making any commitment to share summaries of your organization’s maintenance data, we strongly suggest that you make your plans known to the appropriate managers (and your own team) to seek their buy-in and approval.

To prepare your request, we recommend that you:

  • Gather information on how much effort your group currently expends on planned maintenance (PM) and equipment safety checks.
  • Be prepared to discuss the impact of the changes implemented by CMS and The Joint Commission to require following manufacturer’s recommendations for PM. Depending on your audience, consider including the text of Sections 15.1 and 15.2 from the "Heart of the PM Debate".
  • Calculate the effort your group will need to expend in order to provide your maintenance data to the project (Steps 2 through 5 below).
  • Be prepared to explain the potential payback (assuming the Task Force is successful in achieving Project objective #1).
  • Get “buy-in” from the front line members of your team, since they will be the ones providing the effort required to actually generate the data. Do this, preferably, before approaching managers outside the team.
  • When dealing with upper management, emphasize that all of the data submitted from your organization will only be summary data, totally devoid of any patient information. The identity of your organization will only appear as a code in part of the file name. The Task Force will aggregate all of the data from the participating organizations. Only de-identified aggregate data summaries will be made public by the Task Force.

Step 2. Adopting the "MPTF Standardization Guidelines" for data coding.

As stated above, the data you submit needs to be in complete conformance with the data structure described in Section 15.3 2) "Failure Cause Codes for Repair Calls" and Section 15.3 3) "Coding PM Findings" in "The Heart of the PM Debate".

Selling the project to the staff may be a major hurdle if collecting data in this format represents a big change. In first adopting this data structure, please monitor for compliance to make sure that the quality of the detailed data is good before providing the summary data to the Task Force.

While recognizing that the following additional data elements will always be works-in-progress, please convert your data to comply wherever possible, and notify us where this is not possible:

  • The Task Force’s standardized names for the various device types. These are listed alphabetically in column 1 of Table 1. Utilize column 2 (ECRI UMDNS® names) and column 3 (other commonly used names) to help in translating your data to the Task Force's standardized nomenclature in column 1.
  • Column 4 of Table 1 contains links to some generic PM procedures that can be used by your organization to help gather the needed PM data. While it is NOT specifically required that you use these generic PM procedures, they may be useful. If your organization has additional generic PM procedures that have been validated against at least one manufacturer/model combination (please provide a list of verified manfr./model combinations), we would appreciate you submitting these generic procedures to the Task Force.
  • The Task Force's standardized names for manufacturers and model names or numbers. These can be found in Table 13.
  • Coding repair calls. Organizations supplying data must use some type of coding for repair calls that allows for a separate count of the failures that are attributable to inadequate PM (such as the MR1 code described in Section 1.6 of HTM ComDoc 1.) Since the definition of the MR1 code is crucial to our entire effort, it is repeated here. Everyone in your organization who is coding work orders must understand this definition and when to use it.
  • Category MR1; PM-preventable failure. A device failure that could have been prevented by more timely restoration or replacement of a manufacturer-designated non-durable part. E.g. a battery failure, a clogged filter, or build up of dust. Failures due to trapped cables should not be coded this way.
  • This is OPTIONAL, but recommended: Because of its value in helping to maximize equipment-related patient safety, we also recommend a coding arrangement based on the three basic causes of total failure described in HTM ComDoc 1. - namely,
  • IRFs or inherent reliability-related failures,
  • MRFs maintenance-related failures, and
  • PRFs or process-related failures.

Adopting the full 15-category coding method described in HTM ComDoc 1. and HTM ComDoc 8. is recommended because of its value in identifying potential non-maintenance-related corrective actions that will further improve the levels of equipment-related patient safety.

Step 3. Using the manufacturer’s recommended PM procedures and PM intervals.

Until such time as the facility opts for using an Alternative Equipment Management (AEM) program, the facility is required by the current CMS regulations to use the manufacturer’s recommended PM procedures and PM intervals.

Even if choosing to take the AEM option the Task Force requests that, for the immediate future, you continue using the manufacturer’s procedures and intervals, for at least the “Top 20” device types in Table 4. We make this request in order to generate a sufficient quantity of baseline data on PM-related reliability before introducing another variable in the form of a variety of different PM procedures.

Step 4. Exploring the possibility of mapping existing records to the new format.

Depending on past practices at the facility, it is possible that some of the facility’s existing maintenance records can be translated into the new format adopted by the Task Force. For this to be acceptable you will have to be in a position to provide assurances that the PM procedures used to do the PM work included all of the device restoration tasks and performance/ safety verification tasks included in the relevant manufacturer’s PM procedure for each device. Then it will be necessary to convert (map) all of the relevant maintenance findings from the existing records to the new MPTF format.

Step 5. Organizing the data into batches for submission to the Task Force.

The format of the final Summary Proof Tables in the database can be seen in Table 5.3HE - which uses critical care ventilators as an illustrative hypothetical example. The format of the Detailed Proof Tables that feed the Summary Proof Tables can be seen by clicking on the link C.VEN/BA-M1/06, which is in the lower part of the first cell (R1-C1) in the table.

Separate the data into individual batches by device type,by manufacturer, by model, then by PM interval. For each individual batch create the following string of data in an Excel table (one row for each Type/Manufacturer/Model/PM interval combination):

1) Organization Name (Note: first 3 columns in this list not shown in Table DEF/PC-12/06 for brevity)
2) Facility within Organization (maybe same as organization name)
3) Dates covered by the data
4) Device type (MPTF terminology - see http://htmcommunitydb.org/wiki/index.php?title=Table_13)
5) Manufacturer (MPTF terminology - see http://htmcommunitydb.org/wiki/index.php?title=Table_13)
6) Model (MPTF terminology - see http://htmcommunitydb.org/wiki/index.php?title=Table_13)
7) PM interval (months)
8) Number of devices for which data was collected (N)
9) Length of period over which the data was collected (Y months)
10) Number of times one of these devices failed and the failure was classified as an MR1 failure (M)
11) Number of times one of these devices failed a PM and the failure was classified as a PM Code 9 failure (W)
12) Number of times one of these devices failed a PM and the failure was classified as a PM Code F failure (S)

Submit the complete Excel table with a cover email to Alan Lipshultz, CCE, PE, CSP, CPPS - Director of the Task Force - at Alan@HTC.pro Include in the email the following accountability statement along with the name and title of the individual to contact if any follow up is needed.

  • Accountability. We vouch for the authenticity of the maintenance data included in this report and have complied with the “MPTF Standardization Guidelines for data coding” specified by the HTMC Maintenance Practices Task Force (MPTF).

In order to facilitate potential research in the future the Task Force asks that, if possible, you retain whatever documentation you have that provides as much detail as you have on the nature of each of the documented (MR 1)device failures and the documented PM Code 9 and PM Code F failures.

Attachment 1. The AAMI Community Database Project .

More details on the background to the project can be found at: http://htmcommunitydb.org/wiki/index.php?title=HTM_Community_Database_Project

Site Toolbox:

Personal tools
Disclaimers - About HTMcommunityDB.org