The Service Documentation Is Part of the Device: A Quality Inspector's Take on Hologic Horizon Service Manual and Hologic Selenia Dimensions Error Codes

Look, I don't care if a service manual runs to 800 pages. I care whether it gives a stressed technician a clear path. I say that as a quality compliance manager who reviews service documentation for a living. In our Q1 2024 quality audit, I reviewed more than 300 technical documents — service manuals, operator guides, error code databases, and test protocols. I reject more deliverables for documentation gaps than for specification failures. The hardware can be brilliant, but the people responsible for keeping that hardware alive are stuck with what the manual says when it fails.

Here's my position: the service documentation is part of the device. The Hologic Horizon service manual and the Hologic Selenia Dimensions error codes deserve the same review attention as the imaging chain itself. The same standard should apply to any fluoroscopy system, any anesthesia machine, and any spinal cord stimulator.

That statement gets pushback. I get it. Let me explain why I hold it.

Documentation is the first line of maintenance

The assumption among many procurement teams is that a service manual is simply a record of what the machine does. The reality is the opposite: the manual determines how quickly the machine gets back online after something goes wrong. Nothing about that is theoretical. In my audits, I often start with the troubleshooting section, because that is where a product reveals how much thought went into the person who will fix it.

What I mean is that downtime is not usually caused by the first failure. It is caused by the time spent interpreting the symptom, finding the right reference, and deciding whether the fault is safe to clear. A manual that does not support that decision is not documentation in any useful sense. Put another way, it is a liability in a binder.

I care less about page count than decision logic. A good manual says: if condition X appears, check Y, verify Z, and then either replace the component or escalate. It gives you a branch, not a wall of text. That is the standard I use when I open the Hologic Horizon service manual. It is not the shortest manual I have read, but it usually tells me what to check before asking for support. That trait matters more than any single specification on the datasheet.

Error codes are a design artifact

Error code documentation is the clearest window into an engineering culture. The Hologic Selenia Dimensions error codes are a good case. When I audit error code lists, I look for three things: specificity, severity, and next action. A code that says calibration failed is incomplete. A code that says calibration failed, check the calibration phantom, verify detector temperature, and retry is usable. The difference is not cosmetic. It determines whether a technician can make a decision on site.

The most frustrating part of reviewing error code databases is how often the same error code has different meanings across software versions. You'd think revision control would be strict, but it is often messy. In 2024, I rejected about 14% of first documentation deliveries because at least one error code was unexplained or ambiguous. That is not a trivial issue. If a technician cannot tell whether the problem is in the tube, the detector, or the power supply, the next step is guesswork. Under ISO 13485, controlled documentation matters exactly here: if the error code table does not match the software behavior, the quality record is wrong.

The surprise wasn't the hardware failure in those cases. It was how much time we lost to the documentation. No error code should end at contact support without giving a starting point. That is true for a Hologic Selenia Dimensions unit, a fluoroscopy system, or any other imaging device.

The same test applies beyond imaging

It is easy to focus on Hologic because mammography and bone densitometry systems are complex. But the same logic applies to other categories I review. A fluoroscopy system can have excellent image quality, but if the service manual does not explain how to reset the X-ray exposure chain after an unexpected stop, the room stays dark while the team waits for a phone call. An anesthesia machine may pass every preventive maintenance check, but the operator's manual should describe what to do before oxygen supply failure occurs, not simply after. A spinal cord stimulator is even more software dependent; when the patient's programmer displays a system check failure, the manual needs to tell the clinician whether the patient is safe to continue therapy or needs to come in.

I should add that I have also seen third-party service manuals that outperform the original equipment manuals. In those cases, the issue isn't engineering value; it's willingness to invest in the service experience. Good service documentation is a choice.

This is an evolution, not a fad

I understand why service documentation has been treated as an afterthought. For decades, the manual was just a printed companion to the device. In 2020, a PDF version felt progressive. In 2025, we expect revision control, searchable error code tables, and documentation that follows the way a stressed biomedical technician actually works. That is not about aesthetics. It is about the difference between a service visit that takes one hour and one that takes three.

What was best practice in 2020 may not apply in 2025. Devices are more connected, software updates happen more often, and error codes change with each release. A static manual that is not tied to the current software version is a safety issue, not a convenience issue. The fundamentals haven't changed: documentation must be accurate, available, and actionable. But the execution has to transform.

In one internal review, we replaced a twenty-page troubleshooting chapter with a decision tree that covered the same faults. The first call resolution rate improved by roughly a third. The documentation was not a supporting document in that project. It was the product.

The objection I keep hearing

The strongest objection is that service manuals are written for trained professionals, not for newcomers. I understand that argument. Technicians should know basic anatomy of the equipment before they touch it. But even a trained professional needs an accurate map. If the error code says one thing and the manual points somewhere else, training makes it worse, because the tech trusts the manual and wastes time.

To be fair, documentation cannot rescue a poorly engineered product. If the imaging chain is unstable, 200 pages of troubleshooting won't make it stable. But that is not the question. The question is: between two clinically equivalent devices, which one will have lower total cost of ownership? The answer is almost always the one with clearer service information. Good documentation is not expensive compared with the cost of downtime.

That is why I read error code documentation before approving a vendor. If a company cannot explain its own error codes in a clear, consistent way, I start to ask what else is unclear.

Conclusion: documentation is a clinical requirement

So here is my conclusion. I don't think a service manual is an accessory. I don't accept the phrase it's just a manual. The Hologic Horizon service manual and the Hologic Selenia Dimensions error codes are part of how those systems stay available for patients. The same criteria apply when I look at a fluoroscopy system, an anesthesia machine, or a spinal cord stimulator.

IEC 60601-1 treats accompanying documents as a formal requirement for medical electrical equipment. That standard is not about grammar. It is about giving people what they need to operate and maintain a device safely. Under that framework, a manual isn't support. It is part of the device. Approve it accordingly.