Visit Website →
← Back to blog

Map QPId Between QIF and DMIS to Avoid Data Loss for Quality Engineers

September 28, 2026
Map QPId Between QIF and DMIS to Avoid Data Loss for Quality Engineers

QIF is the XML based framework that governs quality data across its lifecycle, from design intent through results and statistics. DMIS is the execution language that tells a CMM how to move, probe, and record. Most metrology workflows need both: DMIS to run the machine, QIF to structure, validate, and share what the machine found. The practical question is not which one to pick, but where each belongs in your process.

TL;DR:

  • QIF is ideal for structuring and sharing measurement data across the full quality lifecycle, while DMIS focuses on controlling measurement equipment during execution.
  • Ensuring QPId or UUID persistence throughout DMIS execution is crucial for accurately matching results back to plan elements.
  • Adopting QIF gradually by starting with Result and Plan schemas simplifies integration, especially when controllers support DMIS 5.3 natively.
  • Vendor support for QIF export, such as Hexagon's PC-DMIS 2024.2, indicates growing industry adoption and facilitates traceability.
  • Using platforms like QA-Report can streamline data import, reporting, and validation without extensive custom pipeline development.
QA-Report
Streamline Your Inspection Reporting
QA-Report imports CMM data and creates audit-ready inspection reports with dimensional results, GD&T validation, and statistical summaries.
Explore QA-Report

Table of Contents

Comparing scope, format, and role in the workflow

DMIS and QIF solve different problems, and confusing them is where most integration projects stall. DMIS, standardized as ISO 22093, is a neutral programming language for communicating with dimensional measurement equipment: it defines features, tolerances, and the instructions a CMM controller executes. QIF, standardized as ISO 23952, is an XML information model that covers the full quality data lifecycle rather than a single machine event.

  • Scope: DMIS programs one measurement run; QIF structures data across planning, execution, and analysis.
  • Format: DMIS uses a text based program syntax validated against controller behavior; QIF uses modular XML schemas validated against a formal information model.
  • Primary users: DMIS lives with CMM programmers and controllers; QIF lives with PLM systems, inspection reporting platforms, and quality databases.
  • Decision rule: if the task is moving a probe, write DMIS; if the task is storing, sharing, or analyzing results, use QIF.

The Digital Metrology Standards Consortium frames this directly: DMIS handles equipment control, while QIF supports the end to end digital metrology chain, including plans, results, and statistics.

Technical differences: data models, schemas, and identifiers

QIF's architecture is deliberately modular. Application area schemas cover Plans, Results, Product and Model-Based Definition, and Statistics, and each can be implemented independently. That modularity means a team can validate incoming QIF Results data against a schema without needing the full Product or MBD layer, which reduces the overhead of adopting the standard piecemeal. It also gives quality systems a consistent, machine-checkable structure instead of a loosely formatted export file.

DMIS programs, by contrast, are built from constructs like features, operations, and sensor definitions, expressed as sequential instructions for a controller. Because DMIS predates many modern reporting needs, vendors have historically layered proprietary extensions on top of the base language to handle sensor metadata or advanced motion, which is where portability between CMM brands gets harder.

The bridge between the two is the persistent identifier. ANSI/DMIS 5.3 added QPId and UUID support specifically so that features and characteristics in a DMIS program can carry a durable ID into execution and back out into a QIF result. Without that identifier, matching a DMIS-executed characteristic to its corresponding QIF element after the fact is guesswork based on names and ordering.

QPId mapping from DMIS features to QIF results

Even with QPIds in place, semantic gaps remain. Feature-type definitions do not always line up one to one between the two models, sensor metadata granularity varies by vendor, and execution sequencing in DMIS does not always translate cleanly into QIF's more descriptive result structure. These gaps are usually small enough to manage but large enough to require actual validation, not assumption.

Interoperability and mapping: practical DMIS to QIF patterns

A typical round trip looks like this: a QIFPlans document defines the characteristics to be measured. A DMIS program is generated or written to execute that plan, the CMM runs it and produces native DMIS results, and those results are converted into a QIFResults document for storage and analysis. NIST's demonstration work has shown this exact pattern, using QPIds to match execution results back to the originating QIF plan elements.

  1. Confirm the QPId or UUID assigned in the QIF plan survives untouched through DMIS execution.
  2. Check that Feature and Characteristic counts match between the DMIS results and the converted QIFResults file.
  3. Compare statistical summaries, mean, range, and tolerance flags, between the two representations to confirm parity.
  4. Flag any DMIS vendor extensions that have no direct QIF equivalent before they cause silent data loss.

The most common mapping failures come from PMI semantics that do not map directly, vendor-specific DMIS extensions with no QIF counterpart, and sensor metadata that DMIS captures in more or less detail than QIF expects. None of these are fatal, but all three need an explicit check rather than a hope that the converter handled them.

Pro Tip: Run your first round-trip test on a part with a small, well-understood feature set. It's far easier to spot a broken mapping in ten characteristics than to find it buried in three hundred.

Implementation guidance and migration strategy

Teams moving toward QIF rarely need to adopt every application area on day one, and trying to do so is the fastest way to stall a project. Scope the first phase around Results and Plans, since those two schemas cover the bulk of day-to-day inspection reporting without requiring a full Model-Based Definition rollout.

  • Inventory your CMM controllers and confirm which support DMIS 5.3 natively, and identify a mapping tool or vendor service for the ones that do not.
  • Define a persistent ID policy before writing any mapping code: decide how QPIds get assigned, how they are stored, and who owns that convention.
  • Build a small library of sample datasets that represent your typical feature types, tolerances, and sensor configurations.
  • Run round-trip tests against that sample library, automate the comparison of feature counts and statistical values, and only widen scope once those tests pass consistently.

This staged approach keeps the DMIS layer intact for machine control while QIF absorbs the reporting and traceability burden, which is exactly the division of labor both standards were designed for.

Tooling and ecosystem signals worth tracking

Vendor support is the clearest sign of where QIF adoption actually stands. Hexagon's release notes for PC-DMIS 2024.2 document QIF export that preserves Feature and Characteristic IDs across multi-execution reports, which is a concrete implementation of the traceability model DMIS 5.3 enabled.

  • DMIS remains the dominant interface for real-time machine control and for legacy CMMs that predate QIF entirely.
  • QIF is gaining ground wherever results need to travel: PLM systems, statistical process control tools, and inspection reporting platforms.
  • Reporting platforms like QA-Report sit downstream of both, ingesting structured measurement data regardless of which standard produced it.

Quick integration checklist for metrology projects

Before your first integration sprint, settle these four points so the work does not stall on undefined scope.

  1. Pick your application areas: start with QIF Results and Plans before touching MBD or Statistics.
  2. Confirm DMIS 5.3 support on your controllers, or line up a mapping tool for the ones running older versions.
  3. Set QPId and UUID rules and build a small sample dataset to test against.
  4. Define pass criteria: feature and characteristic match rates, plus statistical parity, for every round trip test.

How QA-Report approaches structured inspection data

QA-Report ingests CMM output and structured inspection data to build audit-ready First Article Inspection and dimensional reports without manual re-entry. When results arrive in a well-defined format like QIF, downstream traceability and statistical summaries hold together more reliably than they do from ad hoc exports, because the data already carries the structure a reporting system needs. Teams evaluating a CMM data import workflow can start with a small sample dataset to see how cleanly it maps.

— Michael Chen

A practical path if you would rather not build the pipeline yourself

QA-Report

Building a custom DMIS to QIF pipeline takes real engineering time, and not every quality team has a spare sprint to spend on schema mapping and round trip validation. QA-Report offers a shorter path: import CMM data directly, whether it originated as a DMIS execution result or a QIF file, and generate audit-ready First Article Inspection, dimensional, and GD&T reports without writing conversion code. The measurement wizard links ballooned drawing dimensions to measured results and flags out-of-tolerance deviations automatically, so the traceability work your QPId policy sets up actually pays off in the report your customer sees.

  • Import CMM results and let the platform handle the ballooning and tolerance matching.
  • Generate statistical summaries and PDF reports that satisfy ISO 9001, AS9100, and PPAP requirements.
  • Manage production data alongside inspection results through the built-in MES layer.
PlanPriceBest for
Freeno costTesting a first dataset before committing
Basicmonthly subscriptionSmall teams running routine inspection reports
PROmonthly subscriptionTeams needing full MES and reporting features

Start with the Free plan and run a sample DMIS or QIF export through the CMM inspection software to see how it maps before deciding on a paid tier.

Standards and reference documents

For engineers who want to verify any of the above against the source, these are the primary references.

  • NIST Technical Note on QIF: architecture overview and interoperability demonstrations using QPIds.
  • DMSC: About DMIS and DMIS download and notes: scope, versioning, and QPId/UUID details for DMIS 5.3.
  • ISO 23952:2020: the formal QIF standard and schema partitioning.
  • ISO 22093:2011: the formal DMIS standard for equipment communication.
  • PC-DMIS 2024.2 release notes: a working example of vendor QIF export support.

Readers building a broader Industry 4.0 data strategy around these standards may also find useful context in this guide to connected manufacturing processes.

Sources

FAQ

Is QIF still used today?

Yes, QIF continues to see active development and vendor adoption, with the Digital Metrology Standards Consortium maintaining the standard and CMM software vendors adding export support. It is used mainly for structuring quality results, plans, and statistics rather than for machine execution.

What is the purpose of a DMIS portal?

A DMIS portal or reference site provides access to the DMIS specification, downloads, and implementation notes for CMM programmers and controller vendors. The DMSC's DMIS page is the primary source for the current 5.3 version and its persistent ID additions.

What does PC-DMIS stand for?

PC-DMIS is a commercial CMM programming and measurement software product from Hexagon, built around the DMIS execution language. Its recent releases, including version 2024.2, add the ability to export results in QIF format.

What is a QIF file used for?

A QIF file stores structured quality data such as measurement plans, results, or statistical summaries in a validated XML format. It is used to move that data between CMM systems, PLM tools, and inspection reporting platforms without losing traceability to the original feature or characteristic.

Which is better, QIF or DMIS?

Neither replaces the other because they solve different problems: DMIS programs and runs the CMM, while QIF structures and shares what the CMM measured. Most mature metrology workflows use DMIS for execution and QIF for the traceable data exchange layer around it.