Medical tools, AI and liability: why clinical expertise doesn't replace software engineering

AI and digital tools now hold a central place in medical practice. This shift is sometimes accompanied by very assertive statements from certain physicians on the design, evaluation or reliability of software solutions.

The debate is healthy. But it also reveals growing confusion between medical expertise and technological expertise — a confusion that is far from trivial, as it directly engages medical, legal and regulatory liability.

Being a physician does not make you a software developer, just as being a developer does not make you a physician. In healthcare, this distinction is not theoretical: it determines patient safety and the protection of practitioners.

Medical expertise is essential… but it is not sufficient

The physician is at the heart of the care system.

They master:

• clinical reasoning,
• diagnostic pitfalls,
• the variability of practices,
• the requirements of the medical report.

Their role is fundamental in defining the uses, needs and limitations of a tool. But designing, securing and maintaining medical software is a profession in its own right, which calls on specific skills:

• software architecture,
• IT security,
• health data management,
• regulatory compliance,
• validation, testing and traceability.

When these dimensions are underestimated, the risk does not lie with the tool itself, but with the medical act that depends on it.

A medical tool directly engages the practitioner's liability

One point is still too often misunderstood: whatever tool is used, the physician remains responsible for the report.

This means that:

• any error resulting from a software malfunction,
• any inconsistency produced by a poorly controlled tool,
• any loss or corruption of data,

can have direct consequences for:

• patient care,
• the practitioner's civil and criminal liability,
• the credibility of the facility.

Why medical software development cannot be improvised

Developing a tool used in a clinical context is not just about "getting an algorithm to work". It requires a chain of responsibilities and guarantees.

Identified, competent development teams

Reliable medical software relies on:

• professional developers,
• software architects,
• security and compliance specialists,
• testing, versioning and maintenance processes.

These are professions, with standards, methods and obligations.

A clear regulatory and contractual framework

A responsible software vendor must be able to document:

• the respective responsibilities (vendor / user),
• the functional limitations of the tool,
• the terms for updates and support,
• the validation processes.

Without this framework, the risk is implicitly transferred to the physician using the tool.

Hosting compliant with health data requirements (HDS)

Medical data is sensitive data. Processing it requires:

• HDS-certified hosting,
• guarantees of confidentiality, traceability and availability,
• strict control of data flows and access.

A tool that does not comply with this framework exposes its users to major legal risks, regardless of its functional quality.

Nomenclature, validation, traceability: prerequisites, not options

A serious clinical tool must rely on:

• clear nomenclatures,
• consistent report structures,
• explicit validation mechanisms,
• complete traceability of actions and changes.

These elements are not a matter of user convenience. They are essential to:

• ensure the report is readable,
• secure exchanges between professionals,
• enable audits,
• meet medico-legal requirements.

The reality of a structured medical software vendor

At Doctreen, the reliability of the platform rests on a clearly identified multidisciplinary organisation, combining technical, medical and application expertise.

The technology is developed by a team of twenty people:

• software developers and artificial intelligence engineers, responsible for the architecture, security, maintenance and continuous development of the solution,
• lead radiologists, involved in defining uses, validating clinical pathways and ensuring the medical consistency of the tools offered.

On top of this comes an essential, often underestimated link: application engineers.

Application engineers who come from clinical practice

At Doctreen, field support is provided by a team of application engineers who come directly from radiography and radiology. This dual clinical expertise enables a detailed understanding of real-world uses, day-to-day constraints and the safety issues involved in using digital tools in medical practice, and ensures a constant link between technology and the field.

This human interface is essential to make the real-world use of a clinical tool safe.

Responsible innovation vs technological tinkering

It is legitimate for a physician to take an interest in technology, to test it, to question it. But responsible innovation in healthcare relies on collaboration, not on the illusion of self-sufficiency.

The most reliable tools are those that result from:

• close dialogue between physicians and engineers,
• development carried out by identified and structured teams,
• a regulatory framework that is fully embraced,
• clearly defined responsibility.

Conversely, solutions developed outside this framework may seem agile in the short term, but they leave the practitioners who use them lastingly exposed.

Conclusion: in healthcare, credibility comes through structure

Modern medicine needs tools that are high-performing, intelligent and suited to the realities of the field.

But above all, it needs tools that are:

• developed by competent and identified teams,
• hosted in compliant environments,
• validated, traceable and stood behind by responsible companies.

Responsibility for the medical report is too important to rest on unstructured or non-approved tools. Turning to organised, transparent and compliant companies is not a luxury: it is a safety condition for patients and physicians alike.