The history and anticipated impact of the required standards on the medical electronics engineering.
The medical field is as exciting as it is rapidly interchanging. Devices of all types are getting more complex, interconnected, and specialized. But the more sophisticated the devices are, the more attention they need from governmental regulators.
Some of the regulatory agencies are CFIA (Canada), EMA (EU), and FDA (USA). They are the ones who decide what products can be sold on the market and which cannot.
To understand why these regulations are needed, you must know a little about their history.
For example, some of the first forms of the FDA were created in the 18th century, but their current form was first introduced in 1927 when they started to regulate food and drug labeling. Later in 1935, there was a scandal with the drug "Elixir of Sulfanilamide," which contained a poisonous ingredient that killed more than 100 people, most of whom were children.
After this fiasco, the FDA got a lot more power thanks toThe United States Congress, which passed the Federal Food, Drug, and Cosmetic Act, which gave the FDA the following:
Later in the 1970s, all the new medical devices had to follow quality control procedures and register the device with the FDA. Based on the device "safety tier," it even had to get pre-market approval by the FDA.
EMA also affects the market, but its history is not so broad since it was founded by the EU in 1995. It was supposed to merge the medical agency of each state to save approval costs every company had to get. Other than that, it is decentralized. EMA functions similarly to the FDA, but the EMA passes the verification to the member states instead of one big organization.
While using software in the medical segment, the developer may face open-source software-related issues. The customer often prefers an open-source software SDK (Software Development Kit) to save money. However, the certification authorities have trouble with this approach as the open-source software is usually not certified according to medical safety standards.
In addition to the software itself, it is required to set up safe processes when using the data – mainly to prevent data leaks.
There will definitely be more improvements and changes, but these 3 points are driving the change right now and will be relevant in the foreseeable future.
Thanks to this knowledge of the regulation history and reasoning and many years of experience, we can prepare future-proof software, fit it to medical software development standards or verify whether your current software is suitable for entering the market.
For the product development for huge customers or corporations, where we participate as a contributor, we follow the customer's processes. For the demonstrator and prototype development, we follow this flow.
For software development, we have experience with various development practices. In the last years, we have mostly focused on two different software development processes: a V-model-based and Agile-based process; for Agile, we have worked both in Scrum and Kanban models.