Welcome to emtronik.at, the website of
Dipl.-Ing. Michael Kandler
expert of embedded developments, especially in regulated environments
In my many years of experience in medical product development, I have observed that the problems often encountered in product development and project management are rarely rooted in technical implementation. Rather, the issues mostly stem from incomplete planning, overlooked work packages, incomplete specifications, rudimentary system design, lack of integration plans, and verification conducted too late. These factors lead to unforeseen expenses in the later stages of the project due to necessary corrections, bug fixes, and specification changes. Such mishaps are easily avoidable when I bring my experience and expertise to your projects or organization. You will be able to develop and complete your products faster and more securely.
Dipl. Ing. Michael Kandler
CEO & Founder
Embedded Development, Planning, Management, Documentation and Consulting
The elements and stages depicted below in the development process have been primarily selected based on where I typically observe deficits or challenges and for which I can offer appropriate support services.
Disclaimer: The following points do not constitute a complete representation and enumeration of the elements of the development process!
In the development of medical products or safety-critical systems, higher requirements are placed on development quality, and compliance with international standards is expected.
Thus, a quality management system is required, a defined development process is demanded, and the product is developed step by step through the activities defined therein. In defined development phases, planned work packages are elaborated, verified, integrated or constructed into the preceding work packages, and released at the end of the phase in a development review. A central element is that planning and traceability must be followed in all steps. This mindset is often only rudimentarily taught in traditional technical education and is not fully appreciated by a typical developer.
Addressing this deficit and enabling your team accordingly is your benefit.
The product definition, although addressed at the very beginning of product development and still largely theoretical, holds a particularly significant position: From the commercial requirements, the product idea, and the requirements from the system environment (if the product is to be embedded in a system), the basic concept and the fundamental requirements („Customer Requirements“) for the product are created through discourse with technical feasibility studies.
Crucial decisions are made during this process; overly ambitious desires coupled with overly optimistic technical implementation ideas or a lack of feasibility studies lead to disillusionment, especially during project planning, and depending on the willingness of financing, may result in project termination or a redesign of the product.
As a result of a professionally conducted product definition, at least the following should be available for decision-making:
- Feasibility concept and basic technical concept
- „Specification“ or „Customer Requirements“
- Rough estimation of effort
- FTO („Freedom To Operate“) = legal feasibility.
My offer to support you in product definition:
Building upon the product definition, the conceptualization phase is carried out in this step:
A technical concept is created, providing a comprehensive overview of the expected implementation. Furthermore, the technical contents are aligned or „negotiated“ with the functions and features to be realized. With good technical expertise, costs and efforts for development, as well as manufacturing costs per feature/function, can be estimated.
Based on this, the product manager can decide which functions and features to include in the development and which ones are better not to be realized from a cost-benefit perspective.
Clarity and consensus regarding the scope of development and the development outcome are crucial in this step. A consolidated specification document (CRS) and a draft of the requirements specification (technical requirements) are finalized and approved.
My offer for your concept development:
Adherence to a defined and well-planned development process for medical product development is mandated by the MDR and all relevant standards.
Not having a defined process poses a significant risk for product development and for the medical product manufacturer. Conversely, a well-defined development process is the key to efficient and high-quality development.
Consequently, alongside development activities, necessary records and documentation for quality assurance are generated, including verification planning and accompanying investigations, reviews, and tests. Changes in requirements or in the system, as well as other alterations, are addressed and documented in the change management system.
Conducting quality assurance alongside development can largely prevent unpleasant surprises during final verification and prevent costly development loops.
My offer for planning the appropriate development process and outcomes:
For medical products and safety-critical systems, higher demands are placed on requirements management:
In general, good requirements management benefits every product development, as thorough and precise specification of requirements allows for systematic and targeted development of the system.
An incomplete set of requirements inevitably leads to „late requirements.“ These, being unplanned and unforeseen in the system, subsequently cause severe disruptions and delays in the project timeline.
However, in medical products or safety-critical systems, emphasis is not only placed on the completeness of specifications but also on the consistent derivation and relationship of requirements within their hierarchy. And even more importantly, all requirements must be associated with corresponding verifications. This ensures that the product has been systematically verified through a series of tests. Conversely, all verifications and validations must be traceable back to overarching requirements to demonstrate against which specification the tests were conducted and that the defined acceptance criteria were met.
This systematic approach of forward and backward traceability is called „Traceability“ and is required in all audits and inspections.
My offer for the systematic development of all specifications:
Risk management plays a central role in the development of medical products and safety-critical systems. Attention to meticulous risk management is also emphasized in the corresponding regulations, directives, and standards. Risk management is a concurrent process that must run parallel throughout the entire project duration, from definition to approval.
A risk manager typically oversees the process. However, it is essential to involve the entire team, as identifying potential risks requires technical knowledge, system knowledge, expertise in the field, and an understanding of the application area and system environment.
Often, risk management is carried out too sporadically. Both risk management and the risk management file must be kept up to date: if risk assessments are only conducted at the beginning of a project, risks that may arise during development (e.g., during system design) or testing may not be considered, and corresponding measures for risk mitigation may not be incorporated. However, if risk assessments are conducted (or updated) only at the end of the project, risks may be identified much too late in the project timeline, and implementing corresponding countermeasures may be difficult or, in the worst case, impossible.
Special emphasis is placed on further processing the measures derived from risk assessments: appropriate requirements must be derived, included in the specifications, and specifically marked („Traceability“).
Verification and validation must demonstrate that the measures implemented are effective and efficient.
The creation of system architecture is a crucial step in the development process and should by no means be casually overlooked. The statement „The system will come together during development anyway“ is not entirely wrong, but like all other activities and contents, it should be well designed and planned in advance. Without a foundational system architecture, the systematic creation of a product becomes challenging.
We can illustrate this concept with the analogy of building a house: Without a plan, the tradespeople may be able to deliver their parts, but they may struggle with installation (integration) because it hasn’t been defined where and in what sequence the installation should take place.
It’s the system architecture and the subsequent system design that enable project planning with the arrangement of work packages for design, implementation, integration, and verification. The final system validation also relies on the system architecture.
My offer to create an optimal system architecture:
The project planning builds upon the development planning or the development process.
However, project planning is much more detailed, as it involves planning specific work packages and arranging them on the timeline based on their dependencies, planned resource allocation, and set milestones. Concurrently, the deliverables already defined in the „development process“ are also addressed.
My offer to support the planning of your project:
The implementation activities and project management for medical products and product developments that must follow a defined development process do not fundamentally differ from „normal“ product developments. However, care should be taken to adhere to the sequences defined in the development process. Often, there is a temptation to prioritize activities or to postpone milestones or integration steps in case of delays, yet still begin work packages from subsequent project phases. Generally, this is common practice in project management if the project allows it.
In product developments that have to follow a defined development process, such decisions in project management should ensure that unnecessary sequence chains are not broken and activities are not started that necessarily require a completed and approved input that is not yet available AND approved.
Verification and validation are crucial for the approval of medical products and safety-critical systems and for compliance with standards and regulations. Through diligent verification and validation, you can ensure that your products meet the highest quality standards and fulfill the requirements of users and clients.
The verification process should ideally start early and accompany the project until completion. Verification is a concurrent process (similar to processes such as risk management, quality management, or regulatory affairs). Verification (testing) should not, as is often assumed, only take place at the end of the project with the „finished“ product but should also encompass all upstream partial or intermediate results. Validation, at the end of the verification process, completes the product development and forms the basis for product release and approval.
In addition to the (medical) product itself and its components, development documents must also be verified through reviews. For example, when reviewing the system design, it is referred to as a „Design Review“ (FDA – General Principles of Software Validation).
Since fully integrated software cannot be comprehensively tested and there is a risk of hidden errors, standards require a systematic approach to software verification: the smallest units (functions, objects, etc.) – known as „Units“ – must be checked for functionality and error-freeness through code review, coding rule checker, and unit tests before being integrated into the software system. Automated testing systems are particularly suitable for these ongoing tests: it is important to repeat tests already conducted with advancing integration (= „regression testing“), as there is a risk that errors may occur in previously tested software parts due to cross-effects with newly integrated components. Automation can significantly improve efficiency and ensure repeatability.
Comprehensive documentation of all V&V activities and seamless traceability between requirements, tests, and results are crucial for regulatory compliance and transparency; automated systems can also support in this regard.
Lastly, when using quality-assurance tools, the proof of their suitability („tool validation“) must not be overlooked. It must be demonstrated and documented that the tools used are capable of detecting all errors and cannot introduce new errors into the system.
My offer for planning and supporting compliant system validation:
When the development project is nearing approval, all previously mentioned points should be completed, and the results should be finalized. It must be verified whether the development file is complete and logically structured. If there are still gaps, these must be closed before applying for approval from the designated authority to avoid unnecessary trouble and delays. In case of significant deficiencies, a plan should be created to focus and efficiently align activities towards approval.
My offer for systematic documentation and successful approval:
The production of medical products also needs to adhere to a higher quality standard. Production should not be considered downstream and in isolation. The requirements for production must be taken into account and planned during the development stage.
This involves planning, developing, and verifying testing equipment, interfaces, and testing procedures. It is also necessary to demonstrate that the testing equipment is capable of ensuring the required performance data of the product and can guarantee freedom from errors.
For medical devices, the MDR requires the monitoring of products in the market (Post-Market Surveillance). In case of incidents, appropriate corrective and preventive actions (CAPA = Corrective And Preventive Action) must be taken. Both the process for this and the responsible parties for implementing the measures, as well as a maintenance plan for the product, should be established before the product is released.
For a medical device that has been on the market for some time, additional work packages may be necessary in the event of a product change, error correction, or product update, as the product must always comply with current standards, and new standards may demand more than was the case at the time of product approval. For example, new documentation sections may be required and need to be created, tests may need to be repeated, and new tests may need to be conducted (e.g., due to changed EMC standard requirements).
Special emphasis is placed on „Traceability“ (the traceability of verification and validation) today – if this is lacking, it must be rebuilt, which could also uncover further gaps (missing tests, non-specific requirements, etc.) that then need to be addressed.