Medical device GUI application for laser system control

About the project

Our client is a specialised medical engineering company developing advanced hardware systems, including high-intensity laser devices used in aesthetic and medical contexts. Their focus is on building compliant, market-ready devices aligned with European regulatory expectations.

Following a successful earlier collaboration, we were invited to support the development of a medical device GUI application for a new laser system. The application was designed to act as a device control software layer, commissioned by an end client responsible for distribution across Europe.

What did our client need?

At this stage, the product could not be reliably validated.

The hardware components were in place, but there was no stable way to:

• control device parameters,

• verify system behaviour,

• ensure consistent communication with embedded system components.

The assumption was that an Android-based interface running on an industrial tablet could act as the control layer.

However, this introduced a critical uncertainty:

whether a medical device GUI application could reliably communicate with a real-time microcontroller in an acceptable time regime.

This was a key aspect to verify when adopting an Android-based architecture, particularly to support system design decisions and reduce the need for custom hardware certification efforts.

Without resolving this, the risk was significant:

• the device would remain untestable,

• behaviour would be unpredictable,

• safety assumptions could not be verified,

• further development would rely on unconfirmed hypotheses.

The core issue was not the interface itself, but the absence of a controllable and verifiable system.

How did we approach it?

Product workshop and PoC definition

We began with a joint workshop involving both software and hardware stakeholders to define:

• system architecture assumptions,

• communication model between the application and the MCU,

• scope of the proof of concept.

This phase aligned all parties around a single objective:

validate that control via a medical device GUI application and device control software is feasible.

Communication layer design

To address the core uncertainty, a dedicated communication layer was introduced.

We defined:

• RS-485-based communication between the tablet and the device,

• a lightweight custom protocol inspired by Modbus RTU,

• mechanisms for command confirmation and error handling.

This enabled stable communication between the application and the device, making system behaviour predictable, testable, and suitable for further validation.

The application evolved from an interface into:

• a device control layer,

• a source of truth for operational parameters,

• a feedback mechanism for system integrity.

GUI application as a control system

The Android application was designed as a medical device GUI application and control interface for the embedded system, not a standard mobile product.

Its responsibilities included:

• setting and validating operational parameters,

• synchronising state with hardware components,

• detecting inconsistencies and reporting them to the user.

This enabled full integration between software, firmware, and hardware layers.

Regulatory and risk alignment

Devices used for aesthetic procedures are not always perceived as medical products. However, under MDR Annex XVI, certain categories of non-medical devices are explicitly brought under medical device regulation.

This extends to equipment emitting high-intensity electromagnetic radiation, including laser systems used for skin treatments such as hair removal.

In this case, the software was classified according to MDR and IEC 62304 requirements, resulting in:

• MDR Class IIa alignment (as a device covered by Annex XVI),

• IEC 62304 Class B categorisation, due to the potential for non-serious injury.

From the outset, the system was therefore approached as safety-relevant software, not a standard interface.

We supported:

• early-stage classification and regulatory interpretation,

• risk analysis based on ISO 14971 principles,

• identification of hazards and definition of risk control measures,

• creation of the Software Requirements Specification (SRS).

This approach ensured that the proof of concept was not only technically verified, but also aligned with regulatory expectations.

As a result, the client avoided a common pitfall: building a technically working system that would later require significant redesign to meet compliance requirements.

Communication and delivery

All activities were coordinated through:

• JIRA and Confluence for traceability,

• Git-based version control,

• structured communication across teams.

This enabled efficient collaboration between hardware and software teams.

Results

Before:

• no reliable way to control or validate the device,

• uncertainty around Android-based control feasibility,

• disconnected system components,

• no structured regulatory foundation.

After:

• PoC of a medical device GUI application controlling the laser system in real conditions, designed as a solid foundation for further system development rather than a disposable prototype,

• stable, reliable communication with the microcontroller,

• integrated system combining hardware, firmware, and embedded control software,

• initial documentation supporting MDR pathway.

Most importantly:

the product moved from an unverified concept to a controllable and testable system.

This allowed the client to validate key technical assumptions early, test the complete device configuration in real conditions, and move forward with further development based on confirmed system behaviour rather than uncertainty.

What did we deliver?

The client gained a validated foundation for product and regulatory decisions:

• a proof of concept confirming that a medical device GUI application can reliably control the system,

• a communication layer enabling predictable interaction between the application and the embedded system,

• an integrated environment connecting all system components,

• initial risk and regulatory documentation aligned with MDR expectations.

This reduced uncertainty at a critical stage and supported further product development.