How can a cooperation with soventec run for a traditional company? A project example

We would like to show you an example of how soventec can support a traditional company in product realisation in the medical technology sector.

In our daily business, certain structural tendencies become apparent when we work with a start-up, a traditional company or a global corporation. This is a little simplified and certainly does not do justice to every company. It is only meant to illustrate where the strengths and weaknesses of the different types of companies can lie. Looking at the above diagram, the strengths move from "top left" to "top right", from the flexibility and innovative power of a start-up to the stability and process establishment of a global corporation with a simultaneous "larger area" and thus more wide-ranging competence, but also sometimes with less flexibility and innovative power.

The following project example shows our cooperation with a medium-sized company, without mentioning names or internals. We would like to show you how we as soventec can be a building block on your way to the product.

Product realisation of a monitoring system for a traditional industrial company that has been successful on the market for many years.

The Situation:

A manufacturer of medical storage elements who had been active on the market for many years wanted to revise his product and at the same time make it "smarter" in order to gain a market advantage over his competitors. The established product was there. soventec helped with the conceptual design of the system via a workshop and "specifications". An electronics development service provider was selected. soventec was to implement PC monitoring software with an interface to the embedded components of the new product to be developed. At the same time, the necessary regulatory documentation was to be prepared for the development process in order to be able to approve the development into a medical product.

The Collaboration:

Phase 1: Contract and confidentiality

In the first phase, it was important to create trust between the future contractual partners. After all, this project was to be developed together over a period of 12 months. At the same time, strategic cooperation was not ruled out. For this, the "chemistry" between management and developers had to be right. Both parties had to take a certain leap of faith. A confidentiality agreement and a development contract were concluded as the first documents.

Phase 2: Know How Transfer

In the second phase of the cooperation, the aim was to gain a deeper understanding of the technology and the methods behind it. In initial meetings, basic structures and interfaces to the tasks to be handled by soventec were worked out. In another direction, soventec presented and explained the basic regulatory development process and the mandatory phases. At the same time, a recurring "weekly" was agreed in which both parties exchanged information on the development status and presented partial results. This instrument has proven to be very effective in many projects because misunderstandings and questions can be clarified quickly without one party developing too far in the wrong direction. The weekly meetings take between 15 minutes and an hour, depending on the content to be discussed, which is time very well spent.

Phase 3: Risk analysis, architecture and design

In phase 3, soventec established documents and project-specific processes that are prior to the actual technical development, but are required by regulation. With the initial risk analysis, which has the safety of the user or patient at its core but also goes beyond that, the ongoing process of risk management was started. Technical documents on software architecture, usability and interface design were developed. This phase is rounded off with the project specification, from which the packages to be processed are derived. All documents are created in a planned process with revision documentation and release mechanisms. soventec uses established software systems for this purpose, among others, with which the processes are also managed for later agile development. This phase is finalised and coordinated with technical reviews, in which the entire development team discusses the design and architecture documents and approvals are given by the team and the customer.

Phase 4: Agile implementation with constant customer exchange and preliminary versions

The project specification results in the tasks to be completed, which are divided into subtasks. For the development in a project of this kind, we use SCRUM in a version adapted to the company. At the beginning of a sprint (development period of approx. 15 days), the team shares the tasks that need to be done and thus add the most value to the progress of the project. After the sprint and in short daily meetings ("dailies"), the completed tasks are reviewed and evaluated in order to optimise further steps and eliminate "hurdles".

The internal development steps go through a peer review workflow. The sub-workflow steps are documented with software solutions such as Atlassian JIRA.

At a higher level, there is a constant exchange via the weekly. Here, development progress is discussed and questions are clarified. Usability evaluations by the customer or test persons are also included here ("formative evaluation").

New development steps that have not yet been taken into account may also arise during the development process and be added to the pipeline. Depending on the project, but relatively generally valid, phase 4 is the longest phase in terms of time.

Phase 5: Verification and validation

Towards the end of the project, more and more release candidates of the system to be implemented emerge. Once the development steps to be implemented have been individually verified internally, the integrative system verification takes place. In another internal technical review, the team evaluates whether and with what quality the inputs from the architecture and specification have been implemented.

Quality assurance checks whether the functionality has been implemented as specified using test protocols that were already defined in the specification phase. This is also done on the basis of the dual control principle. At the same time, the usability of the system is verified.

In the specific example, the customer's equipment was made available for verification at soventec so that the system could be effectively tested.

Phase 6: Project completion

"Software is never finished", they say. That's true! Nevertheless, a development project must come to an end. Verification is the proof that what was specified has been implemented. After testing by the customer and handover, the project is finished. Activities that go beyond this, such as updates and services, are also defined in the corresponding IEC 62304 standard and are agreed separately.

Conclusion

About one year after the development of the concept, a marketable product with the possibility of medical approval has been created. In addition to the actual software development of various components and the software documentation, about 300 pages of regulatory documentation from various standards had to be created. The customer can now go through the approval process and enter the market!

Many SMEs are well established in the market, have products that sell sustainably. Often, despite all the success, innovation is somewhat neglected, which is necessary to remain established in the future. Technical cycles are becoming shorter and shorter. This increases the pressure to innovate. By bringing together expertise, good results can be achieved quickly in order to map the documentation effort, especially in the medical technology sector.

Through our experience, we can implement this effectively for you as a partner and are also available as a strategic partner for the maintenance of the product. At the same time, we also see how important good chemistry and good communication between customers and soventec is for the success of a development project.

Especially with our many years of software development experience with simultaneous regulatory medical technology know-how, we can become an important building block in the implementation of your idea into a product and together create the high requirements of the MDR.

Together we should prevent a good idea from being stopped on its way to becoming a product by seemingly insurmountable hurdles.

Coming together is the beginning, staying together is progress, working together is success . — Henry Ford