Why do medical devices follow such high standards?

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.

Regulatory Agencies 

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.

History of the FDA (U.S. Food and Drug Administration)

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: 

  • regulatory oversight of therapeutic devices, 
  • ability to block any new drug that did not pass its safety tests before going into the market, 
  • court authority to implement and enforce food, drugs, and medical requirements.

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.

History of EMA (European Medicines Agency)

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.

What does this mean for the future of medical devices? 

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. 

We expect the following possible future scenario within the medical segment: 

  1. The regulators will expect increasing sophistication in preventing attacks based on known vulnerabilities, such as those listed as Common Vulnerabilities and Exposures (CVEs), including methods to update vulnerable devices securely  when new CVEs are discovered. 
  1. An increasing emphasis on security in these devices and intensified testing to make sure devices are secure when released. While this has been required for quite some time, the recent creation of standards such as ANSI/CAN/UL 2900 will be an increasing emphasis in future reviews. 
  1. There will be more regulation in the open-source communities. An example could be emphasizing the best security add-ons available in the OSS market, such as OpenSSL. 

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.

How Consilia can help your product to enter the market.

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.

Next Experiences

Our Experience with Hardware Product Life Cycle

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.

Comparison of V-model and Agile Software Development Methodology

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.