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.
What is an inspection data management system (IDMS)?
An inspection data management system, or IDMS, is the place where inspection results and the evidence behind them are stored as structured, searchable records instead of loose files. It holds the reports, the readings, the photos, the technician certificates and the calibration records, linked to each other and to the job, so anyone reviewing the data later can see what was found, how it was found and whether the finding can be trusted.
Most inspection data in North America still lives in a mix of PDFs on a shared drive, Excel workbooks, email attachments and paper travellers in a filing cabinet. That works until someone needs to answer a question across many jobs: every PAUT report on a given client's welds this year, every report signed by a technician whose cert has since been revoked, or every job where a specific UT instrument was used before it failed calibration. A folder structure cannot answer those questions. A structured IDMS can.
This section explains what an IDMS should hold, how inspection data should be structured, what retention and audit trails look like, and how the Atlantis ERP solution and Atlantis Digital Twins store and present inspection data for NDT and inspection companies.
IDMS vs inspection management software vs a document folder
An IDMS is about the data; inspection management software is about the work. In a good setup, they are the same system, because the data is captured while the work is being managed.
| Approach | What it stores | What it cannot tell you |
|---|---|---|
| Shared drive or document folder | Final PDFs and spreadsheets | Which instrument, cert or procedure revision sits behind each result, without opening every file |
| Stand-alone reporting tool | Report data and templates | Whether the technician was certified or the instrument calibrated on the day |
| Inspection data management inside the Atlantis ERP | Structured report data, photos, signatures, certificates, calibration records, procedures, linked to the job | Engineering conclusions about the asset, which remain with the owner's integrity team |
The point of that last column is honesty about scope: an IDMS makes the data reliable and findable. It does not replace the engineer who decides what the data means for the asset.
Inspection data management: how the data should be structured
Good inspection data management starts with deciding what is a field and what is an attachment. Anything you will ever filter, sort or report on should be a field. Anything that is evidence for a human reader, such as a scanned certificate or a site photo, can be an attachment, but it should be attached to the right record.
| Data type | What to capture as structured data | Where it lives in Atlantis |
|---|---|---|
| Report header | Method, report number, client, site, work order, request, WPS, contract, drawing numbers, procedure and standard references | NDT Reports |
| Method data | UT probe calibration table; RT source, technique, IQI type and placement; MT technique and particles; PT method and developer; PAUT focal laws; MFL scan mode; UT thickness readings by direction | NDT Reports, per method |
| Findings | Weld or job lines with defect type and orientation; overall result | NDT Reports |
| Photos and signatures | Captured in the field against the report | Offline field app, synced to the report |
| People | Scheme, level, method, dates, OJT and training hours, vision tests | Certificates |
| Equipment | Serial, type, firmware, condition, calibration results and due dates | Asset Management |
| Procedures | Document number, revision, method, scope, standard, acceptance criteria | Procedures |
Reports as structured records, not just PDFs
The core of any IDMS is the inspection report, and the key design choice is that the report is a record first and a PDF second. In the Atlantis ERP there are 17 report types: UT, RT, MT, PT, VT, ECT, IRIS, PAUT, MFL, TOFD, PWHT, PMI, hardness, UT thickness, ferrite, holiday/coating and computed radiography. Each has its own numbering sequence, so a report number tells you the method at a glance and numbering gaps are easy to spot.
Each type holds the fields that method actually needs. A UT report is not a generic form with a comments box; it carries the probe calibration table. An RT report records source, technique, IQI type and placement. A PAUT report records focal laws. UT thickness readings are held by direction, and weld and job lines hold defect type and orientation. The overall result is one of three explicit values: acceptable, not acceptable, or acceptable with remarks, which makes it possible to filter for every rejectable finding on a project.
The PDF is then generated from that record on your versioned company template, in Excel, Word, PDF or HTML, with logo, header and footer. If a client requires their own Excel sheet, fields are mapped to cells and the sheet fills automatically. Because the template is versioned, you can tell which layout a historical report was issued on.
Readings, photos and field attachments
Field data is where inspection data management usually breaks down, because it is captured in the worst conditions: no signal, gloves on, time pressure. If capture is awkward, data ends up on paper and gets retyped later, and every retype is a chance for a transposed reading.
The Atlantis field app is an installable web app that works without signal. Drafts and photos are stored locally on the device and synced when coverage returns. The technician picks the method, captures photos, signs on screen and previews the PDF before submitting. Through the REST API for field devices, the app knows which jobs are assigned to the technician and which equipment has been issued to them, so readings are recorded against the right job and instrument from the start.
Photos are stored against the report rather than in a separate camera roll. In marine mode, inspection photos are laid out two to a row in the output PDF, alongside a vessel cover page and photo and the inspection location and dates. For instrument output files or scans your process needs to keep, the attachment handling is configured during implementation so they land on the correct report.
Certificates and calibration records linked to the data
An inspection result is only as credible as the person and the instrument that produced it. An IDMS should therefore link each result to the qualification and calibration evidence, not store them in separate silos.
In the Atlantis ERP, technician certifications record scheme (SNT-TC-1A, CP-189, ISO 9712, PCN, CSWIP or other), level, method, certifying body, issue, expiry and renewal dates, OJT hours, training hours, exam results and attachments. Status is computed automatically as active, expiring soon, expired or revoked. Vision tests record near vision (Jaeger J1/J2), far vision, colour perception and contrast with examiner, clinic, certificate file and expiry. Examination sheets hold general, specific and practical scores.
Instrument calibration records hold provider, certificate number, standard, range, uncertainty, accredited-lab flag, result (pass, fail or conditional) and next due date, and the calibration certificate register keeps the PDF with the lab's accreditation number and a valid, expiring or expired status. Because instruments are tracked by serial and issued to technicians through an approved issue and return workflow, you can connect a report to the serial that was on site. For marine reports, the output PDF merges the class certificate, the inspector's Level II certificate and the calibration certificate into one file.
Retention and audit trails
Retention and audit trails answer two questions: how long do we keep inspection data, and can we show that nobody changed it after sign-off? The first depends on you; the second depends on the system.
Retention periods are driven by your client contracts, the construction or inspection code the work was done to, your quality management system and, in some sectors, regulators. Because those differ from job to job, retention rules are configured during implementation rather than hard-coded, and records are kept in the system rather than on individual laptops.
For audit trails, the Atlantis ERP records the path each item took:
- Reports move through draft, in progress, review, approved and sent, with inspector, reviewer and approver signatures, and a third-party or authorized inspector name and signature where required.
- Procedures move through draft, submitted, reviewed, approved and published; approved revisions are locked, rejections carry a reason, and a snapshot of every revision is kept.
- Equipment issue and return runs through supervisor and manager approval with condition recorded both ways; inbound and outbound movements and the maintenance log are kept against the serial.
- Dispatch records who was assigned, where and when, through planned, dispatched, in field, submitted and closed.
- Timesheets are approved and flag technicians whose certificate was not valid.
If you need to understand how your existing records would map into this structure, send us a sample of your current reports and registers.
How the Atlantis ERP stores inspection data
In the Atlantis ERP, inspection data is stored around the job. A project carries client PO, contract, methods, codes, scope and acceptance criteria. Project tasks carry method, technician, component, result, indication and defect counts, and procedure and WPS references. The team assignment carries site coordinates, dates, technicians and equipment serials. Reports sit against the job with their method data, photos and signatures.
Around the job sit the reference registers: certificates for people, calibration and maintenance for equipment, the procedure register, and company certifications such as ISO accreditations with alert days. Dashboards summarise the live state: equipment calibration due or overdue, certificates expiring or expired, and issued equipment overdue for return.
Because the commercial apps are in the same system, a report can be traced to the quote and invoice for the job, which helps when a client disputes whether an item was inspected or billed. The system is affordable, accessible and fully customizable, and is configured for your methods, templates and registers during implementation.
How Atlantis Digital Twins presents inspection data
Stored data is only useful if people can read it. For owner-operators and asset managers, tables of readings across hundreds of components are hard to interpret. Atlantis Digital Twins presents inspection data on a 3D model of the asset: damage and indication mapping shows where findings sit on the equipment, and thickness and remaining-life trends show how readings have moved between inspections.
The Digital Twin Reporting Software ties inspection reports to that 3D view, so a reviewer can open the report from the location on the model rather than hunting through a folder. This is useful at refineries, petrochemical plants, tank terminals and power stations, where the same equipment is inspected across several turnarounds and the story is in the trend.
The boundary matters. The Digital Twin visualises the data and the trends; it does not make integrity decisions. Owner-operators' integrity engineers carry out their own assessments of damage, remaining life and next inspection dates using the methodologies and tools they have chosen. The Atlantis ERP does not calculate inspection intervals, and it does not hold a thickness monitoring location database; it records the inspection reports and readings that feed the owner's own process.
Getting inspection data in and out: open REST API
An IDMS that locks data in is a liability. The Atlantis ERP has an open REST API and integrates with SAP, Maximo, NetSuite, QuickBooks or any system that accepts API connections, with the scope agreed per implementation.
For contractors, typical flows are receiving work orders from a client's maintenance system so the job and report carry the client's reference, and returning approved report files or report status when a job closes. For owner-operators, the flow is often the reverse: pulling approved contractor reports into their own asset records. On the field side, the API already handles jobs assigned to a technician, equipment issued to them, report submission and sync.
Exports for audits or client handover, such as report registers, certificate registers and calibration lists, are configured during implementation to match the formats your clients and auditors ask for.
Migrating from shared drives and spreadsheets
Most companies moving to an inspection data management system start with years of history in folders. A practical migration does not try to convert every old PDF into structured data. It loads the live registers first, which are current technicians and certifications, current instruments with serials and calibration due dates, and the current procedure register, and then starts new reports in the structured format.
Historical reports can be attached to the relevant client and job records so they are findable, while new work builds a clean structured history from day one. Report templates are rebuilt so the output looks like what your clients already accept, which avoids a round of client re-approval of your report format. For small NDT companies this is usually a short project; larger contractors with many templates and integrations take longer, and we scope it up front.
To plan a migration for your own records, talk to us about what you have today.
Frequently asked questions
What does IDMS stand for?
IDMS stands for inspection data management system: a system that stores inspection reports, readings, photos, certificates and calibration records as linked, searchable records rather than loose files.
What data should an inspection data management system hold?
At minimum: structured report data by method, findings and results, photos and signatures, procedure and standard references, technician certifications and vision tests, and instrument calibration records, all linked to the job.
How does the Atlantis ERP keep an audit trail?
Reports and procedures move through defined workflows with named, signed reviewers and approvers. Approved procedure revisions are locked with snapshots kept, and equipment issue and return is approved and logged with condition.
Does the system calculate remaining life or inspection intervals?
No. Atlantis Digital Twins visualises thickness and remaining-life trends from inspection data, but interval and integrity decisions are made by the owner-operator's own engineers and tools. The ERP does not calculate inspection intervals.
Can we keep our existing report formats?
Yes. Versioned company templates in Excel, Word, PDF or HTML are supported, and Excel templates fill automatically from mapped fields.
Can inspection data be sent to SAP or Maximo?
Yes, through the open REST API, which integrates with SAP, Maximo, NetSuite, QuickBooks or any system that accepts API connections, scoped per implementation.
How is an IDMS from Atlantis priced?
Quote on request, depending on the apps, templates and integrations you need. Request a quote and demo.