What is a System?
INCOSE*, the International Council on Systems Engineering suggests the definition of a System with the phrase:
" system is an arrangement of parts or elements that together exhibit behavior or meaning that the individual constituents do not."
(A system is a set of parts or elements that jointly show behavior or meaning that individual components do not show.)
The System concept is associated with a very broad view of the same: if we imagine, for example, the distribution plants of compressed and vacuum medical (IDGM) for hospitals and hospitals, these are composed of countless parts, interacting with each other, they offer the service for which they were engineered.
A System has a series of features that define it as such, whose fundamental and indispensable aspect is that of the life cycle, which defines the stages (stages) from design, implementation, maintenance and final disposal. To stay on the subject with the example, the legislation EN ISO 7396-1 It is precisely inherent in the distribution plants of medicinal gases, cites some of these aspects concerning the life cycle and the disposal of it.
The definition of the System is also applicable to the parts, or to the elements that constitute the System. In fact, according to the literature, a plant like that of the example can be even considered a System of Systems**, then a set of Systems that interact with each other offer a series of capabilities that would not be able to offer individually.
Systems Engineering - Systems Engineering
The term Systems Engineering dates back to 1940, where it was first used in the Bell Laboratories in the United States. The definition relates explicitly to the need to identify the properties and characteristics of a System in its entirety.
The term spreads primarily in the US military sphere, which in those years is a flourishing ground and contributes to the identification of formal processes, activities and disciplines that will be the basis of what is now Systems Engineering and in fact modern engineering.
Over the years, Systems Engineering and the disciplines that are directly part of it, are adopted largely outside the military framework, particularly in aerospace and automotive, and the application of practices to the development of medical devices and systems is undoubtedly among the most interesting areas having in common with the others mentioned many distinctive features.
The development of medical devices is continuously and rapidly developing, machinery and devices are becoming increasingly complex and integrated in Systems, and this sector can undoubtedly benefit from the experience of Systems Engineering.
There are many common points, for example, to the aerospace sector: having systems composed of countless parts, having to operate in critical environments for safety and in critical operating conditions (e.g. electromagnetism, radiation, difficult environments), human factors, reliability, high costs, special materials. Being in a context where the product can directly impact the safety of a patient obliges medical systems companies to constantly consider regulations and obliges them to apply formal risk management processes that must be excellent.
The development of medical devices is far from simple: due to strict standards and intrinsic complexity of the development of hardware and software, creating devices is a real challenge. In addition, the demonstration of compliance with standards and the evaluation by the Ethical and Clinical Committees in the health field are expensive, both in economic and temporal terms.
These activities and processes related to them are absolutely necessary to avoid legal and quality problems of the product, as well as to avoid sanctions and launch of products themselves on the market late (both for the initial planning desired and respect the competition) as well as, last but not least, to avoid the “brand erosion”, that is the association between product failed, unconformed or even harmful and name of the company.
Only companies that manage to keep up with the right agility can get a greater advantage than the competition.
Standards and Systems Engineering
Systems Engineering, as a set of disciplines, relates directly to ISO 15288 (Systems and software engineering — System life cycle processes), which together with ISO 29148 (Systems and software engineering — Life cycle processes — Requirements engineering) can help companies operating in the field of medical systems development, process tailoring to offer even more competitive and high quality products. In fact, for example, System Engineering applies an eye for the formal processes of Verification and Validation, which respectively ensure that the product functions correctly and is correctly developed according to the specifications.
In the context of Systems Engineering, it is common and fundamental to review the standards that can be imposed (by government agencies and/or the specific commodity sector), in compliance with the [Bleep] stakeholders that will use the product. Quality Assurance processes and related activities are fundamental to identify any shortcomings in design and potential risks as soon as possible in the development of the System and the product, also making it as explicit as possible within all processes and development teams, customer expectations, ensuring greater quality and reducing risks.
In fact, a typical ESF activity is to analyze the needs of stakeholders (stakeholders), transforming these needs into stakeholders requirements. To ensure the proper quality management process, stakeholders need to be correctly expressed and become part of a process where derivative requirements must be measurable, verifiable and traceable at any stage of development and by any actor involved in development.
One of the cornerstones of Systems Engineering is the traceability, i.e. the concept of always and at every stage of development*[B] the relationship between the individual artifacts that are part of the engineering chain (e.g. architectures, design, planning, test plan etc.) towards the origin, i.e. true the stakeholders needs, in order to ensure always on the one hand the satisfaction of the requests of the contracting party and on the other avoid the most possible design.
The processes of development of medical equipment are already evidently very influenced by stringent regulations that oblige companies and work teams to very strict controls, sometimes inflexible and expensive processes: the ISO 15288 aims instead to represent with a vision of together the development of a system and a product, in a completely transparent manner with respect to natural obligations derived from specific commodity categories.
Systems Engineering has given natural christening to the concept of Systems Thinking*******, i.e. the concept of systemic vision and as a whole that is strongly recommended to adopt in the development of complex systems.
The importance of a Quality Management System (QMS)
In order to respond in the correct, rapid and efficient way both to regulatory demands and to the increasing need for collaboration, made even more evident by the dramatic situation of compulsory detachment that we are living, it is increasingly essential to use tools that facilitate the operations sharing and tracking during the entire production chain of engineering.
Quality Management System (QMS) systems are created with the aim of offering these essential capabilities to adopt a risk-based approach, which goes beyond the engineering and development phase, but also can offer the necessary surveillance in the post market as a safety plan.
A QMS system compliant with ISO 13485 is considered valid when it is able to manage all phases of the life cycle of a system, including:
- the management of the requirements;
- risk management;
- planning;
- the management of supplies (outsourcing);
- design;
- software development;
- verification and validation;
- traceability;
- reporting;
- the generation (automatic) of project documentation;
- automatic generation (but changeable by operator) of documentation for certification bodies and/or for ethical committees.
Conclusions
Applying changes of any nature to existing processes is always a very delicate task, first of all because it is essential to maintain the operational continuity of working groups and not to have (negative) impacts on business. In fact, it is unthinkable to block entire work teams in the hope that the improvements applied can be accepted and “digested” without negative impacts.
As well as the introduction of new instruments, in the case of government like QMS, require a lot of attention. Despite most of these systems are quite similar to tools we use daily (thanks to the continuous study by Vendor on the usability and similarities that these can have) it is in any case of changes that require an effort from those who then those tools will go to use them.
These are evidently the reasons that make it unthinkable and unnecessarily risky to implement a “tabula rasa” and impose tools and processes on teams already consolidated.
The correct approach is undoubtedly of an incremental type “agile”, that is,
1. definition of needs and proposition;
2. implementation of the proposition;
3. release and training to work teams.
These three fundamental activities, applicable both to processes and tools, can be repeated over time until the optimal customization is achieved and certainly guarantee acceptance by members of the working teams.
Customization is also indispensable: as well as adopting a new tool always requires a degree of configuration, even the standards that provide processes and activities must be modeled and adapted, always keeping in mind the objectives, which can be summarized with the characteristics such as:
- useful;
- adoptable;
- adaptable;
- compliant;
- and collaborative.
_______________________________________
* https://www.incose.org : International Council on Systems Engineering is a non-profit association, active in the definition and dissemination of practices related to the engineering of systems at international level. INCOSE has about 18000 members including individual members, companies and students.
System of Systems - SoS - https://www.incose.org/products-and-publications/sos-primer
By stakeholder we mean not only end users, but anyone involved in use or even before in the initial conceptualization of a system or product or in the request for creation of a system (e.g. the customer).
Until the end of the life of the system or product, then during the disposal activities.
***** https://thesystemsthinker.com/introduction-to-systems-thinking/ https://thesystemsthinker.com/systems-thinking-what-why-when-where-and-how/
