Digital calibration certificates: what the lab gains

Most calibration laboratories still deliver their results the way they did twenty years ago: as a PDF, often with a scanned signature, sent by e-mail. The customer prints it, files it and types the numbers they need into a spreadsheet or a CAQ system. A digital calibration certificate (DCC) replaces that PDF with a structured XML file that software can read directly. The case for it is usually made from the customer's side. This post makes it from the laboratory's side: what a lab gains from issuing DCCs, where the effort really lies, and how to take the first steps with the PTB schema.

What a PDF certificate costs the laboratory #

The PDF seems free. It is the lab's own report, generated anyway. The costs appear later, and they rarely show up in the lab's accounting:

• Queries. A customer cannot find the uncertainty for one measuring point, reads a value from the wrong row or wonders whether "as found" or "as left" is meant. Each question is an e-mail, a look-up and an answer from someone who could be calibrating instead.
• Retyping, on both sides. The customer types your values into their system. If they make a mistake, your certificate is "wrong" until someone compares the two. Inside the lab, data often travels from the measuring software into a Word template by hand as well.
• Re-issues. A typo in a serial number or a customer name means a corrected certificate, a new revision, and the question which of the two is now valid.
• Locked results. Years of measurement data sit in PDFs where nobody can analyse them: not the customer, who wants to see the drift of an instrument, and not the lab, which could use the same history to advise on calibration intervals.

None of these costs is large on its own. Together they are a steady drain on exactly the people whose time the laboratory sells.

Five things a lab gains from issuing DCCs #

1. Fewer queries and no retyping #

A DCC states every value with its unit, its uncertainty and the condition it was measured under, in fields defined by the schema. There is no row to misread and nothing to type off. The customer's software imports the certificate, and the values land next to the instrument they belong to. Most of the e-mails that today begin with "a quick question about certificate number ..." do not get written.

2. Measurement data the customer can reuse, and so can you #

Once results are structured, they can be compared. The customer sees the drift of an instrument across its last five calibrations and can justify the interval with data, which is exactly what an auditor asks for (we covered this in our post on preparing instruments for an audit). The laboratory holds the same history and can offer it as a service: an interval recommendation based on the instrument's own behaviour instead of a rule of thumb. That is a conversation a PDF archive cannot start.

3. Conformity statements that a machine can check #

A statement such as "within the manufacturer's specification" or "conforms to class 1" is the part of the certificate most customers actually act on. In a DCC it is a structured element, linked to the measuring points and the decision rule it was based on, not a sentence in a footer. The customer's system can read it, set the instrument's status accordingly and raise a flag when a result is out of tolerance. For the lab this means fewer misunderstandings about what was and was not assessed.

4. A differentiator in tenders and customer audits #

Framework agreements and tenders increasingly ask how calibration data is delivered. Companies that are building a digital quality record do not want to retype certificates from one supplier while importing them from another. Being able to answer "we deliver DCCs according to the PTB schema, with an embedded PDF and a digital signature" sets a laboratory apart in a market where price and turnaround time are otherwise hard to distinguish. The same holds in the customer's audits: a validated DCC linked to the instrument is the kind of evidence an auditor can check in seconds.

5. One source for PDF and XML #

The gain inside the lab is less visible but just as real. A DCC is generated from the measurement data, and the PDF can be generated from the same data and embedded in the DCC. The report is no longer assembled by hand, numbers are not copied twice, and a corrected certificate is a regenerated file instead of an edited document. Laboratories that take this step usually find that their internal error rate drops before the first customer has even asked for a DCC.

What a DCC is, in short #

The DCC format was developed by the Physikalisch-Technische Bundesanstalt (PTB), Germany's national metrology institute, with partners from industry and accredited laboratories. It is an XML schema with two main parts: administrative data (laboratory, accreditation, customer, item, responsible persons, statements) and measurement results (quantities, reference values, deviations and uncertainties, with units in the machine-readable D-SI notation). Optional parts carry the human-readable PDF and a digital signature. We explain the structure in detail in Reading a digital calibration certificate.

First steps with the PTB schema #

The effort is in the mapping, not in the technology. These steps have worked for laboratories that started from scratch:

1. Get the schema and the examples. PTB publishes the DCC XML schema (XSD), its documentation and example certificates. Read the examples before the schema; they show how the fields are meant to be used.
2. Pick your most frequent certificate type. One instrument class, a few measurands. Map each field of your current report to an element of the schema: the administrative block first, then the results. Note the units as D-SI expressions while you do it.
3. Generate from data, not from the PDF. Connect the export to the measurement data in your calibration software or database. A DCC that is transcribed from the finished PDF inherits every manual step you wanted to remove.
4. Validate on every export. Check each file against the XSD before it leaves the lab. A DCC that does not validate is a support call waiting to happen.
5. Embed the PDF. Generate the human-readable report from the same data and put it into the document element of the DCC. One file, two readers.
6. Decide about the signature. Start without it in the pilot. When the export is stable, add an XML signature, with a qualified certificate if your customers or your accreditation body expect one.
7. Give your customers a reader. Point them to the free DCC Viewer so the first DCC they receive is something they can open, check and export without installing anything.
8. Pilot with one customer. Choose a customer who manages instruments in software and would benefit immediately. Their feedback on the first ten certificates is worth more than any internal review.

What your customers do with the DCC #

A DCC is only as valuable as the software on the receiving end. Customers who manage their instruments in the digical app upload the DCC, have it validated against the official PTB schema, see the laboratory, accreditation and results as structured data, and keep the original file with the instrument's record. Over the REST API, certificates can also be created directly from the lab's system, which turns "send the certificate" into a single call. Every plan includes the full feature set; see the pricing page for details. And for everyone who does not use digical, the DCC Viewer remains free: a laboratory that issues DCCs can hand its customers a reader along with the first file.