In the first article of this series – Customized medical electronics: how to create a good assignment – we looked at how we work with the client to define what kind of device they need to develop, why, and what the technical solution options are.
Once we agree on the brief and the preliminary costing, the second phase of the project comes. In this phase, the work is already on our side – we will design and build the first prototype and then the final prototype and prepare the device for certification.
The first prototype: we are catching bugs
Once we have clarity on the technology, we can start working on the first prototype. We’ll draw the schematics, the circuit boards, the mechanical design and manufacture everything.
But what is the first prototype? We build the first prototype to be as close as possible to the final product, but at the same time, at this stage, we expect that errors may still occur: minor design or circuit errors, as well as real uncertainties in the specification, deviations between theoretical and real behaviour, or mechanical details that are not apparent from the 3D design.
The first prototype is also important for the client. After weeks of development, he finally holds his device in his hand for the first time and is confident that the project is moving in the right direction.
In the 1st prototype, we mainly address the risk parts
The first prototype serves primarily to early detection of technical risk areas. So we will focus on what may cause major changes or jeopardize the schedule:
- stability and accuracy of measurement, image quality, quality of therapy – the functional basis of the device,
- analog signals and sensitive parts,
- interaction, interference and EMC behaviour,
- safety parameters (leakage currents, insulation, cooling),
- functionality of key user inputs and outputs.
Of course, customer satisfaction with function and design is also important: at this stage it is still relatively easy to make additional changes. At the same time, for the client, the first prototype is the moment when they see the real device for the first time – they can physically test it and verify that the project is heading in the right direction.
And vice versa: we don’t deal with risk-free things yet
For the first prototype. deliberately we do not focus on areas that do not have technical risk – they do not affect the functioning of the device and can be safely refined later.
Typically, it is:
- user interface (graphics, layout, colours),
- application workflow and convenience features,
- non-critical communication or service elements,
- details of appearance, ergonomics or final mechanics.
So within the software, we focus only on what is necessary to test the hardware – for example, to verify that the sensors are giving meaningful data, that we can process the camera image, that the buttons, display or peripherals are responsive. We don’t program the final UI or make a complete application. Full-fledged software is developed only for the final prototype, when we know that the hardware is stable and makes sense.
Errors allowed
The first prototype exists precisely to find the bugs: to show how the device will behave in practice as soon as possible, and to allow us to quickly modify the design before we go ahead with the final version. When the design comes back to the developers at this stage, the solution is a matter of a few days (modification on the PCB, software change, 3D printing of the part…), weeks at most, while later modifications would mean a significant extension of the project.
It is also important from a business point of view. With the first prototype, the client can already approach investors or show the device at a trade fair.
Final prototype – tuning operational details
The final prototype is a version of the device that already closely matches the future product. It has stable electronics, a tight mechanical design, functional software and behaves exactly according to the specification.
At this stage, it is not only the client who tries out the device, but we also try to involve technicians who will take care of servicing or installing the device. It is they who can detect details during the test run that may not be apparent in a laboratory environment but may cause complications in real life – for example, a cable is harder to reach somewhere or the controls are not completely ergonomic.
As soon as these comments are resolved, the documentation is frozen. This means that the schematics, BOMs, production data and mechanics get final versions. The project enters a phase where nothing changes unless there is a really compelling reason to do so. Because any change would mean interfering with testing procedures, certification documentation, production fixtures and the overall budget.
Quality prototype = smoother certification
Certification of medical devices is a separate chapter and will be covered in the next article. However, it is already the case that when testing, it pays to send devices to the lab that are as close to the production version as possible, but at the same time start continuous testing as early as possible so that the tests are a formality and not a risk.
In the next installment of the series, we’ll look at how to prepare for certification and what can be done to ensure the exam goes smoothly.
And if you are working on your own project and want to check that your technical solution is feasible – contact us. We will be happy to go through the next steps with you.
