Hardware verification provides evidence that a production representative sample of your medical device meets the issued hardware requirements. Unlike software verification, which requires verification activities throughout the development, formal verification of hardware is performed entirely at the end of the design process, although much of the preparation must occur earlier in the project.
Your hardware requirements are typically generated from three sources; the product requirements, risk management and design-specific standard’s requirements.
Hardware requirements derived from product requirements are predominantly functional. To define the requirement, we have to ask ourselves: “what does the hardware sub-system need to do, or contribute, in order to fulfil each product requirement?”
In some cases, a hardware requirement will fully cover a product requirement, but in other cases it may only be one of several elements needed. For example, a requirement to control temperature may involve the need for software, system and mechanical requirements, as well as hardware.
The risk management process, typically a design Failure Mode and Effects Analysis (FMEA), may identify additional hardware requirements as risk reduction measures. For example, an independent overtemperature cut-out may be required as a risk mitigation for a temperature controller failure.
International standards such as IEC 61010-1 and IEC 61010-2-101 are written by industry experts and, whilst they may seem like just a necessary hurdle to marketing a product, they usually contribute to a more robust and safer design output. To minimise the risk of non-compliance when the final design is tested to these standards, it’s prudent to thoroughly review the standards in relation to the specific design and produce design-specific standards requirements.
The hardware requirements should, as far as possible, be design independent, focusing on what’s required rather than how to implement it. They should be succinct, necessary, unambiguous, singular and verifiable.
Top tip: When writing a requirement, think about how it will be verified! This may prompt you to re-word some of the requirements to enable this.
Determining your hardware requirements can be a challenging prospect, however speaking to experts like Team Consulting can help to streamline the process. Once you have a reasonable draft of your hardware requirements, it’s time to start thinking about traceability, to link each product requirement, risk management output requirement and standards’ requirements to the appropriate hardware requirement. The traceability can be implemented with a manually created ‘Trace Matrix’, or we can use a dedicated requirements tracking database such as Helix.
The Trace Matrix will not only trace hardware requirements, but will also link to the SRS (Software Requirements Specification), risk analysis and other documents as appropriate for the design. Subsequently, traceability will be added for your verification tests and finally the design verification results documents.
The last step before starting to write verification tests is to produce a verification plan that will describe the approach and structure of the verification documentation, including the hardware verification protocol.
The hardware verification protocol may include the detailed test methods or may reference separate test method documents. Everything may be included all in one protocol or there may be one protocol per verification test. What’s appropriate for your project is likely to be based on your existing procedures (if applicable), project complexity and maximising flexibility whilst minimising the number of documents. Whatever the structure, it needs to be documented in the verification plan.
Each hardware requirement will be tested by one or more verification tests, but one verification test can also cover several hardware requirements. Remember the trace matrix, that’s where we keep track of it all!
When writing each verification test, to provide the required objective evidence (that the design meets the hardware requirements) various methods may be employed. The default method is empirical testing, but depending on the nature of the requirement, tests could include inspection of manufacturer’s data, component certifications, calculations and third-party test lab reports. In the case of requirements derived from standards, the verification test is usually just a requirement to reference to the test laboratory’s certification.
Each test should include sufficient information for a competent test technician or engineer to perform the test, listing any requirements for specific equipment or operating conditions. It should include the requirement to record their name, date, test reference, device ID, equipment and calibration details, and an acceptance criteria (based on the requirement).
Top tip: Ensure that all aspects of a requirement are fully tested. Watch out for requirements with the words “or” plus “and”, or with ranges of operation that need to be tested at their limits.
The method may include a pro-forma for the results. This can be helpful to ensure all the required information and reports of testing performed are recorded in a consistent and logical manner.
Once the verification tests have been drafted, they should be “dry-run” on the current design (even though not final). Firstly, this will help resolve issues with the test method itself, but it will also help check that all the required test equipment is available and may provide early detection of failures before you’ve committed to a final production design, which can save both time and money!
For formal hardware verification testing the following pre-requisites must be observed:
When the above are satisfied, you’re ready to start hardware verification.
During verification, keep all original results data and ensure it can be attributed to a specific person and instance of performing a test, together with its full record and equipment used. This should all be stipulated in the test method or protocol.
Top tip: Keep all your results in a single sub-directory (or otherwise uniquely associated). If you need to re-run all or part of the hardware verification, create a new sub-directory to store the new results and data.
When the results are complete, they should first be reviewed for completeness, together with the appropriateness and integrity of any supporting documentation. Then a verification report is generated, indicating the overall result, references to the results and all supporting documents and any deviations (planned or unplanned) from the test method or protocol with a justification.
Verifying that your hardware works as intended can be a difficult process, however is a necessary step to ensuring you have a functioning and effective device. By working with experts such as Team Consulting, you can make sure this process is streamlined to help save time, money and effort during your development.
Looking for industry insights? Click below to get our opinions and thoughts into the world of medical devices and healthcare.
