Standards and engineering practice.
What we design toward, what we do on a typical project, and how we approach engineering work where standards matter.
What we design toward.
If your product has to satisfy a particular standard, the engineering needs to account for it from the architecture onward, not as a compliance exercise at the end.
Medical device software lifecycle
Software development, verification, maintenance and documentation structured around the lifecycle requirements for medical device software.
Medical device quality management
Engineering work aligned with the quality system and documentation practices required for medical device development.
General quality management
Defined processes, records and handover practices that fit within established quality management systems.
Functional safety
Failure behaviour, safety functions and fault handling considered at the architecture level where system failure can have physical consequences.
Medical device usability engineering
Operator interfaces designed around how the device is actually used, supporting the usability engineering activities the manufacturer carries out, including changes arising from formative evaluation.
The manufacturer remains responsible for classification, conformity assessment and market approval. We support the engineering and documentation needed for that process but do not replace your auditor, notified body or regulatory advisers.
What happens on every project.
The process scales with the project, but the fundamentals remain the same.
Architecture first
System structure, interfaces, constraints and intended failure behaviour are defined before implementation.
Code review
Changes are reviewed for correctness, failure behaviour, resource use and maintainability before they become part of the product.
Hardware bring up
Power, clocks, resets and interfaces are checked systematically before higher level software is trusted.
Test and validation
Requirements are translated into tests and evaluated against the conditions the product is expected to operate in.
Documented releases
What changed, what was tested, what remains outstanding and how to reproduce the build are recorded.
Handover
Source code, documentation, build instructions, test results and the knowledge needed to continue development are delivered with the product.
The process is proportionate to the work. A feasibility study does not need the same level of process as a regulated medical device. The depth of engineering practice is agreed with you based on the product, its risks and where it needs to go.
This describes how we normally work so you can judge it before engaging us. It is not a specification or warranty. Your signed agreement takes precedence over anything here.