Instrument software, documented to IEC 62304

A regulated instrument is still an instrument. There is a signal chain from the sensor through conditioning to acquisition, an application that controls it and shows the result, and a need to prove the measurement is right. What changes is that every part of that has to be documented to a standard, and the documentation has to hold up when someone outside the company reads it.

We do all three layers: the signal chain and acquisition hardware, the application, and the IEC 62304 lifecycle documentation, written as the work proceeds.

We are delivering a bedside instrument console for a federally funded medical device program now. It is a Python and PySide6 application on Windows. Its signal chain runs from a MEMS pressure sensor through signal conditioning to a LabJack T7, chosen by a formal trade study against 18 hard and 22 soft requirements, and a second LabJack, a T4, feeds synthetic waveforms into the T7 analog input so acquisition is verified against known signals. The IEC 62304 lifecycle documentation set supporting its FDA premarket submission, including a development plan, an architecture description, a third-party dependency risk analysis, and a documentation-level plan, is contracted and in progress.

Behind that is the principal's more than five years on FDA-regulated medical device software before Pebble Logic, described on the About page.

IEC 62304 is the lifecycle standard for medical device software. It does not tell you which language, framework, or tools to use. It tells you which processes have to exist, what each one has to produce, and how much of that depends on how much harm the software could contribute to. FDA recognizes it as a consensus standard.

The starting point is the software safety class. Class A is software that cannot contribute to injury, class B could contribute to a non-serious injury, and class C could contribute to serious injury or death. The class decides how much documentation each process needs, so it is worth getting right before anything else is written.

FDA's guidance on the content of premarket submissions for device software functions sets a documentation level for the submission, Basic or Enhanced, based on the risk the device presents. The level decides how much of the software record goes into the submission.

At either level the submission describes the software, its requirements, its architecture, the risk management behind it, how it was developed and how it is maintained, how it was tested, its version history, and the anomalies that remain unresolved. The Enhanced level asks for more of it, including a software design specification and fuller records of configuration management, maintenance, and testing.

Most of that content is the IEC 62304 record, summarized. A team that has kept the record as it built the software is assembling a submission section. A team that has not is writing the record after the fact, under a deadline, about software that may have changed since.

Which pathway the device takes, and how the submission is put together and argued, is a regulatory decision. The software documentation supports whichever pathway is chosen.

We produce software and lifecycle documentation. We do not prepare or file regulatory submissions, act as your regulatory representative, or perform certification testing. We hold no certification credential in IEC 62304. If your program needs a regulatory consultant or a test lab, you will need one alongside us, and we would rather say so early than late.

Your quality system stays yours. We work inside it as a software supplier, and a quality agreement is signable where it requires one.

Regulated engagements carry a premium over the same scope of unregulated work, and the proposal states it. The lifecycle documentation is real work, not a byproduct, and being a qualified supplier under your quality system carries overhead for each client: quality agreements, supplier questionnaires, and sometimes audits.