Inspection Data Management System (IDMS): What It Has to Do, and How to Evaluate One
An inspection data management system is the system of record for fixed-equipment condition. It holds the asset register, the condition monitoring locations, every thickness reading ever taken, the corrosion rates derived from them, and the next inspection date each piece of equipment is due — with the calculation auditable back to the readings.
That last clause is what separates an IDMS from a document store. Anyone can file inspection reports. An IDMS has to reproduce, on demand, how a given piece of equipment arrived at its current interval: which readings were used, which were excluded and why, whether the rate is short-term or long-term, what thickness basis the remaining life was computed against, and who approved it. When an auditor or a regulator asks why a vessel is on a ten-year interval, that chain is the answer. Systems that store reports as attachments cannot produce it, which is why plants running on a shared drive and a spreadsheet usually discover the gap during an audit rather than before one. The second thing an IDMS must do is feed risk-based inspection: API 580 and 581 assessments consume the same corrosion and damage-mechanism data, and re-keying it into a separate RBI tool is where most integrity programmes lose their audit trail.
Source: API 510 Pressure Vessel Inspection Code; API 570 Piping Inspection Code; API 653 Tank Inspection, Repair, Alteration and Reconstruction; API RP 580 and API RP 581 for risk-based inspection; API RP 571 for damage mechanisms; API RP 584 for integrity operating windows; OSHA 29 CFR 1910.119(j) mechanical integrity.
| Capability | What it means in practice | How to test it in an evaluation |
|---|---|---|
| Asset register and hierarchy | Equipment, circuits and components in the relationship the codes assume, not a flat list | Ask to see a piping circuit with its CMLs, then move a component between circuits and watch what happens to history |
| CML and TML registry | Every monitoring location identified, located and re-findable on the next campaign | Ask how a location is physically re-established years later, and what happens when a grid is revised |
| Thickness history | Every reading retained with date, technician, instrument and method | Ask to see a reading that was later excluded, and why the exclusion is recorded |
| Corrosion rate calculation | Short-term and long-term rates computed separately, the more conservative governing | Ask which rate drove a specific interval and have the system show the arithmetic |
| Interval engine | Next inspection date derived per API 510, 570 or 653, not typed in by a planner | Change a thickness reading and confirm the due date moves without manual intervention |
| RBI feed | Damage mechanisms and rates exported to an API 580/581 assessment without re-keying | Ask to see the data path; if the answer is a spreadsheet export, that is the audit gap |
| Recommendation tracking | Deficiencies raised, assigned, aged and closed with evidence | Ask for the current backlog by age and by equipment criticality |
| CMMS integration | Work orders raised in the maintenance system from inspection findings | Ask which direction the integration runs and what happens when the two disagree |
Why the category is called an IDMS and why that matters when you go looking
Integrity groups in US refineries and chemical plants call this software an inspection data management system, or IDMS. Maintenance groups call the adjacent thing a CMMS, and reliability groups may call a third thing an APM platform. The names matter because they describe different systems of record: a CMMS is the system of record for work, an IDMS is the system of record for condition, and conflating them is how plants end up with inspection history trapped inside closed work orders.
The distinction has practical consequences at audit. A work order proves that an inspection was performed. It does not, on its own, establish that the resulting thickness supports the interval the equipment is now running on. That is an IDMS question, and it is asked in terms of data the CMMS was never designed to hold.
If you are evaluating options, search on the category name rather than on a vendor name. The market is small enough that most buyers arrive at the same shortlist, and large enough that the shortlist differs by industry — upstream, downstream, chemicals and power all weight the same capabilities differently.
The spreadsheet question, answered honestly
Many competent integrity programmes run on spreadsheets, and they are not automatically wrong to. A single unit with a few hundred CMLs and one experienced engineer who has held the data for a decade can be perfectly well controlled. The failure mode is not the spreadsheet; it is the concentration of institutional knowledge in one person and the absence of a reproducible calculation trail.
The point at which a spreadsheet stops working is usually identifiable in advance. It is when the number of circuits exceeds what one person can hold, when more than one person edits the workbook, when a turnaround introduces enough new readings that reconciliation takes longer than the inspection did, or when an auditor asks a question the workbook cannot answer without someone reconstructing intent from memory.
A migration is mostly a data-quality exercise rather than a software one. Historic readings arrive with inconsistent location identifiers, missing instrument records and thicknesses recorded against nominal rather than measured references. Any vendor who tells you migration is a straightforward import has not looked at your data.
Where Atlantis fits, and where it does not
Atlantis builds the inspection management layer — asset and circuit register, CML and TML registry, thickness history, corrosion rate and remaining life calculation, interval derivation against API 510, 570 and 653, recommendation tracking and audit-ready records — with the reporting layer and a digital twin that overlays inspection history onto the asset geometry rather than leaving it in tables.
What distinguishes the offer is not a feature. It is that the procedures and the written practice underneath the data are authored and approved by an ASNT Level III, so the calculation basis and the technique that produced the readings are defensible together. Most software vendors in this category cannot review the inspection that generated the number they are storing.
Atlantis is not a PSM auditor and does not sell API 510, 570 or 653 inspector training. Where a programme needs an independent view of whether its data supports its intervals, that is a report-validation and Level III review engagement, separate from the software. Request a demo or a consultation to scope either.
The evaluation mistakes that cost the most
The first is buying on feature count. Every product in this category lists the same capabilities; the difference is whether each one works against your data model, your circuit conventions and your damage mechanisms. That is only visible in a demo run on a sample of your own equipment, which is worth insisting on even when it delays the decision.
The second is treating integration as a late-stage detail. Whether the IDMS pushes to the CMMS or the CMMS owns the asset master determines who resolves conflicts, and that decision is difficult to reverse once both systems hold history. Settle it before signing, not during implementation.
The third is underestimating the ongoing custody of the data. An IDMS is only as good as the discipline that keeps CML definitions current when the process changes. Software does not supply that discipline, and a programme that expected it to will be back to spreadsheets in substance within two turnarounds, whatever the system holds.
How intervals are actually derived, and why the arithmetic has to be visible
Remaining life under API 510 and API 570 is actual thickness minus required thickness, divided by corrosion rate. The system has to hold all three terms and show which value it used for each. Actual thickness must be the governing minimum in the area, not an average across it — an area whose mean is comfortable while its minimum sits at the retirement limit is at the retirement limit, and averaging is one of the most common arithmetic errors found in remaining life calculations.
Corrosion rate should be computed on both a long-term and a short-term basis, with the more conservative governing. The long-term rate runs from original or nominal thickness to the current reading; the short-term runs between the two most recent surveys. When the short-term rate materially exceeds the long-term rate the service has changed, and an interval built on the long-term rate is no longer defensible until someone understands why.
The interval then falls at one half the remaining life, subject to the code cap — ten years for pressure vessel internal inspection under API 510, five years for most piping circuits under API 570. A system that lets a planner type a date over that calculation has quietly become a scheduling tool rather than a system of record.
Circuit definition is the judgement the software inherits
A piping system is not uniform. One system can pass through changes in temperature, phase, velocity and chemistry, each of which changes the corrosion regime, and averaging thickness data across all of it produces a rate that describes none of it. Circuit definition — drawing boundaries where the service genuinely changes — is the engineering judgement everything downstream depends on.
It is also the judgement most often inherited without review. Circuits drawn at commissioning describe the plant as designed. After a revamp, a feed change or a new tie-in, the flow regime moves while the boundaries stay put, and the corrosion rates being trended quietly stop describing the metal.
No software supplies this. What a good system does is make revision cheap and traceable: move a component between circuits and the history should follow it, with the change recorded rather than silently rewriting the past. Ask to see exactly that in a demo, because systems differ enormously in how they handle it.
Injection points, dead legs and the locations a circuit average hides
API 570 singles out locations that corrode faster than the circuit containing them — injection points where a chemical enters a flowing stream, mixing tees, dead legs where stagnant product allows under-deposit attack, and soil-to-air interfaces where moisture and oxygen concentrate at the transition. Each carries its own shorter, separately tracked interval.
The reason is arithmetic. Downstream of an injection quill the local chemistry and turbulence are nothing like the bulk stream, and metal loss concentrates in a short length of pipe. Folded into a circuit average, that loss barely moves the number while the pipe thins toward failure.
A system that models these only as ordinary CMLs on the parent circuit will average them back in. Ask specifically how injection point circuits are represented and whether they carry an independent interval, because this is where the distinction between a real IDMS and a thickness database shows up.
What is an inspection data management system?
Software that acts as the system of record for fixed-equipment condition: the asset and circuit register, condition monitoring locations, complete thickness history, derived corrosion rates and remaining life, and the next inspection date under API 510, 570 or 653 — with the calculation reproducible back to the underlying readings.
How is an IDMS different from a CMMS?
A CMMS is the system of record for work: what was scheduled, assigned and completed. An IDMS is the system of record for condition: what the equipment measures now, how fast it is degrading and when it is next due. A work order proves an inspection happened; it does not establish that the result supports the current interval.
Does an IDMS replace a risk-based inspection tool?
No, it feeds one. API 580 and 581 assessments consume the same damage mechanisms, corrosion rates and equipment data the IDMS already holds. The integration matters more than either system alone, because re-keying that data into a separate RBI tool is where most programmes lose the audit trail between the reading and the interval.
When does a plant actually outgrow spreadsheets for inspection data?
When more than one person edits the workbook, when circuit count exceeds what one engineer can hold, when post-turnaround reconciliation takes longer than the inspection did, or when an auditor asks a question the workbook cannot answer without someone reconstructing intent from memory. Scale alone is not the trigger; reproducibility is.
What should an IDMS demo prove before you commit?
That it runs on a sample of your own equipment. Ask it to show which readings drove a specific interval and display the arithmetic, to move a component between circuits and show what happens to history, and to produce the current recommendation backlog by age and criticality. Capabilities that appear only in slides are not capabilities.
What makes an IDMS migration difficult?
Data quality, not software. Historic readings arrive with inconsistent location identifiers, missing instrument and technician records, and thicknesses recorded against nominal rather than measured references. Reconciling location identity across years of campaigns is usually the longest task, and any vendor calling migration a straightforward import has not examined the data.